Identify and extend the LKIF target
The US Legal Framework Classes defined the SEC as a LKIF Executive Body and Financial Regulation as an outcome of its Rulemaking. The financial Regulation class is the ontology target for our Staging Class instances.
Financial Regulation is a form of regulation or supervision that subjects financial institutions to certain requirements, restrictions, and guidelines, aiming to maintain the financial system’s integrity. This may be handled by either a government or non-government organization. Financial regulation has also influenced the structure of banking sectors by decreasing borrowing costs and increasing the variety of financial products available.
CodeFederalRegulations is a collection class for CFR sections and paragraphs. This class differentiates CFR from other regulations. For example, the European Alternative Investment Fund Managers Directive will be a sibling to this class.
CFR documents are organized in sections. A CFR_Section contains a group or container tag for search and retrieval purposes.
CFR_Paragraph is the atomic piece of text in the CFR document. It is not divided any further.
The LKIF contains a property that specifies that some Thing is contained (spatially) within some other Thing. A CFR section contains paragraphs.
Modeling CFR Section and Paragraph
The Mapping Diagram shows the staging section and related classes, the prefix “fo-fr-CFR.” The target “fo-fr-sec-iaa:CFR_Section” ontology class has data properties of the information relevant to Finance. We do not need to remodel all of CFR. The lineage to the original staging records remains available.
Note that there is no object property connecting SECTION with the related classes. The “contains” semantic is only in the XML data – not the schema. The target ontology will create class restrictions to enforce semantic integrity.
LKIF object property “lkif-expr:bears” connects the Section to the SEC Rulemaking.
LKIF object property “lkif-mereo:contains” ties the Section to its paragraphs.
All target classes get an “sp:sourceInstance” object property. The source instance holds the URI of the original CFR record, providing end-to-end lineage and query capability.
- XML imports into Staging tend to be over-normalized. The ontologist denormalizes into optimal OWL classes.
- Relational Database imports into Staging are often denormalized—tables with a hundred columns not in 3rd, 2nd, or even 1st Normal Form. The ontologist normalizes adding semantics to the OWL class structure.
Mapping CFR paragraph to LKIF target
“fo-fr-cfr:P” is the class generated for paragraphs in the XML. “fo-fr-cfr:E” is for enumerations. These are small text fragments wherever the CFR document contains a list.
We also have “sxml:Node” for the actual text.
The target CFR_Paragraph transforms text and enumeration text to data properties.
LKIF object property “lkif-expr:bears” connects the Section to the SEC Rulemaking.
LKIF object property “lkif-mereo:contained_in” is the inverse property of “contained” and point to the section.
The rectangular box “change namespace” denotes a direct class-level mapping: For every instance of “P” create an instance of CFR_Paragraph and change the URI namespace from “fo-fr-cfr” to “fo-fr-iaa-rule”.
The connector from “composite:index” to “fo-fr-sec-iaa-rule:hasCompositeIndex” is a direct data property level mapping.
Mapping Rules in SPARQL
The CONSTRUCT is the equivalent of the INSERT
in a relational database. We use SPARQL CONSTRUCT statements to load the data into our
target classes.
“The CONSTRUCT query form returns an RDF
graph. The graph is built based on a template which is used to generate RDF
triples based on the results of matching the graph pattern of the query.” (W3C SPARQL Query Language for RDF)
The example creates triples (an RDF graph) for the hasParagraphText property. We have two variables:
- ?targetInstance of our destination CFR_Paragraph
- ?text The actual text that we to construct for the CFR_Paragraph
instance.
CONSTRUCT {
?targetInstance fo-fr-sec-iaa-rule:hasParagraphText ?text .
}
WHERE {
?this composite:child ?text_node .
?text_node a sxml:TextNode .
?text_node sxml:text ?text .
BIND (fo-fr-cfr-spin-sec:convertCFRtoTargetInstance(?this) AS ?targetInstance) .
}
?this is a
special variable that refers to the current instance of this class that is
being evaluated by the inference rule.
For every instance of our source “fo-fr-cfr:P” we navigate to “sxml:TextNote” and
assign the “sxml:text” property to our ?text variable.
The BIND keyword assigns the value of an
expression to a variable. In this case, we call a function to convert the URI
of ?this to the target URI.
SPIN – SPARQL Inferencing Notation
Having Topbraid Composer as the ontology editor, we use Topbraid SPIN
to define our mapping rules.
SPIN is a W3C Member Submission that has become the de facto industry standard for representing SPARQL rules and constraints on Semantic Web models. It also provides meta-modeling capabilities allowing users to define their SPARQL functions and query templates. Finally, SPIN includes a ready-to-use library of common functions.
SPINMap is a SPARQL-based language to represent
mappings between RDF/OWL ontologies. These mappings can be used to transform
instances of source classes into instances of target classes.
(TopQuadrant, SPINMap ontology mapping)
SPIN Map – class mapping
We used the Diagram editor to connect a CFR source class to the Financial Regulation Ontology target class. This invokes the Create Mapping Context dialog. The SPIN Map engine creates a new instance of the target for every source instance. The target functions determine the URI’s appearance. For the CFR_Paragraph we simply want the engine to replace the namespace prefix with fo-fr-se-iaa-rule.
The preview list shows how the generated URIs will look like.
The Class Form for for-fr-cfr:P shows the SPINMap rules behind the class and data property mapping of the mapping diagram.
Like a database trigger, the inference engine will fire the mapping rule for every instance of the source class.
