Ontology Documentation (Topbraid report)

Ontology Documentation (W3C style)

Ontology files (OWL – turtle)

Loading Law & Regulations

Abstract

The article introduces legislative Use Cases and the legal foundation for Semantic Compliance®. We import the text of US laws and regulations into the Financial Regulation Ontology (FinRegOnt). First we take the less complex source, Code of Federal Regulations (CFR) end-to-end from extract, transformation and load into the ontology. Finally we load the United State Code (USC).

Motivation

Financial Regulations are the Business Requirements for compliance. In conventional compliance efforts, Financial Institutions still map the requirements to implementing data structures and rules using MS-Excel. Having the requirements and mapping within the ontologies facilitates concurrent maintenance, versioning and end to end reporting.

Static Reference Data

The Federal Reserve Bank (FED) is the primary regulator for US Banks. The Securities & Exchange Commission (SEC) regulates Investment Funds. US Congress makes the law. We show how LKIF and FRO model these agents, their relationships and actions.

Semantic Data Integration

The article explains conceptual, logical and physical Data Integration model in a semantic environment. We use the TopBraid ontology tool set, but other ontology platforms and RDF data stores can substitute.

XML Sources

The Government Publishing Office (GPO) provides XML versions of the Code of Federal Regulations (CFR). FRO imports CFR Title 12 Banking and 17 Investment Adviser Act. The Office of the Law Revision Council (OLRC) codified the law and publishes in XML format. FRO imports USC Title 12 and 15.

Ontology Model

This chapter dives deeper into Estrella LKIF modules Action and Medium. We explain where reference and XML source data instantiate classes and properties. FRO extensions to the reference ontology implement a Legal Document structure of defined classes and primitives for CFR and USC

FRO ties Legal Rules to the text of the law

The Ontology Knowledge layer makes the coding logic transparent to give Proof and Trust.
We want the law and regulations within the ontology and directly link them to their implementation. The diagram Figure 2 shows a Legal Rule, Investor Adviser Act Section §80b-2a 11, the SEC definition of Investment Advisers.

Figure 2: Legal rule connected to the USC paragraph

Semantic ETL and reverse engineering of Forms is not specific to investment funds. Any USC/CFR can be imported into the class structure. The example in this article and chapters 1 and 2 of the tutorial pertain to Funds and the SEC. But the ontology has USC/CFR Banks & Banking. Try out the steps with Title 12 Banks and Banking.

Legislative context of USC and CFR

The use case diagram in Figure 3 depicts the legislative processes and government actors that FRO is interested in.

Figure 3: Use cases in the US legislative context.

Codification and Publication produce the official version of laws and regulation.

US Congress enacts the Law. The original bills passed are input for Rulemaking and Codification. FRO doesn’t hold the bills, but rather revised and codified positive version.

Office of the Law Revision Council codifies the law has an XML available for download.

The financial regulators, SEC, FED and others are authors of Code of Federal Regulations.

Government Publishing Office make the Code of Federal Regulations available in XML.

The tutorial chapter 2 explains in details how FRO classes capture government actors and processes.

Data sources for laws and regulations

FRO sources XML for the United States Code from OLRC and the Code of Federal Regulations XML from GPO.

United States Congress enacted the Investor Adviser Act in 1940 to monitor and regulate the activities of Investment Advisers. The act placed mutual funds, closed-end funds, unit investment trusts, and exchange-traded funds under SEC regulation and supervision. The 2010 Dodd Frank Act (DOF), Title IV required most Hedge and Private Equity Funds to register with the SEC.

The Office of the Law Revision Counsel (OLRC) of the US House of Representatives codifies and publishes the United States Code. As Positive Law the OLRC provides the latest version of the act including all changes and amendments.The OLRC website has the current laws available for download on their website.
FRO uses the OLRC XML Title 12 and 15 as a data source.

The Security and Exchange Commission implements the law. The SEC revises the Code of Federal Regulation with detailed instructions, forms, and procedures. The SEC hands over the new CFR to GPO for publication. The SEC supervises Investment Companies and Advisers. Note: For Banking the Federal Reserve is the main regulator. We cover the SEC in this tutorial, but the integration is the same.

Data sources can have various formats: Ontology files, XML, Spreadsheets, RDF Databases, any data source with JDBC connectivity. We use TopBraid Maestro1 to import XML, but the Protégé and RDF Database environment also provide imports. RDF Staging and Target Ontology can be OWL files or graphs in a RDF Database. The Ontology Extract imports the Data Source and stores it in a “dumb” RDF Staging representation.

The Ontology Transformation operates completely in the Semantic environment. The transformation logic is encoded in SPARQL rules. We use TopBraid SPIN2, but Protégé and RDF Database environments also support SPARQL based rules. RDF Staging is critical to the architecture and should not be bypassed. We do not want to encode business logic in the Extract process. We want uniform staging classes and utilize semantic transformation not matter what the data source is.

Semantic integration Logical Model

The logical integration model in Figure 5 shows a business rather than a technology view of the data integrations.

At the end, we want to access law and regulations in the Financial Regulation Ontology though:

From a logical perspective we start out with the required CFR/USC Titles and Chapters, irrespective of their data sources and formats. There are two transformation steps from source to staging and then into target ontology:

1. Extract of the required laws and regulation from their source into an RDF/OWL representation.

Conclusion

We showed the reason for having the text of laws and regulations broken down to paragraphs and available within the ontology. The legislative context is static data with instances for regulators and government agencies. Laws and regulations are publicly available in machine readable formats. We design a target ontology with the required granular level of paragraph. The Logical Semantic Integration Model identifies source, staging and target.

This model and approach is critical for Semantic Compliance.
There are different integration requirements, such as importing regulatory Forms or the Institution’s financial data.
They will come in various source formats: XML, XBRL, RDBMS, and proprietary flat flies.
But we will always put them into a dumb staging first and then do an OWL to OWL semantic transformation. We do not want encode business semantics in the source format specific load process.