Legal-RDF Ontology

From LexmlWiki

(Redirected from Legal-RDF Ontologies)
Community Topics
Licensing (http://creativecommons.org/licenses/by-nc-sa/2.5/)
Legal-RDF Models


This WIKI presents a general purpose ontology that may be used for legal instruments or other types of documents. The ontology is organized into models in a manner that most facilitates its review -- each Legal-RDF resource and class and property definition is associated with a model. The namespace prefix found in typical XML representions for this ontology is lgl:, for example <lgl:Instrument>.

Legal-RDF (http://www.legal-RDF.org) publishes each of its classes as a WIKI so that YOU can help develop and refine them both functionally and technically. For example, if you have requirements that you'd like incorporated by Legal-RDF, all you have to do is this: (a) find the right topic-page, and 'discuss' the topic -- the community will respond or (b) start a new model and provide descriptions of the classes within the model.

From Version 1 to Version 2

Right now, we're preparing to upload the terms defined at Legal-RDF (http://www.legal-RDF.org) as WIKI pages so, at this moment, the WIKIs are incomplete. Until then, visit Legal-RDF (http://www.legal-RDF.org) and its companion site Legal-XHTML (http://www.legal-XHTML.org) for more information about what is being moved over.

Several substantive changes to the ontology are happening as it moves into LEXML from the first version published at Legal-RDF. First, I am implementing an "aspect-oriented" design where the properties of things are packaged as "facets" or "capabilities". For instance in version 1, Title is viewed to be a property of the class CoreResource, the class at the base of the Legal-RDF hierarchy. In version 2, Title is instead a property of the class NamableThing, which is now a superclass of the CoreResource class. In other words, the properties of things are associated now with classes that represent the capabilities and states that are appropriate to those things. Because I think aspect-oriented programming model is now best-practice among application software methodologies, the ontology should best align with the (information) requirements of that model.

Second, for several reasons the naming conventions underlying the ontology are being adjusted. In version 1, the convention for property names boils down to a simple-minded concatenation of the names of the property's domain and range properties. For instance, the title of a document would be a property that was named DocumentTitle, reflecting its domain (Document) and range (Title) -- this is similar to the UBL, the UN's e-commerce language. But because Title is the range of the DocumentTitle property, then Title needed to be defined as a class (despite that Dublin Core defines Title as a property). Further, the grammatical predicate-verb design of the ontology, with predicates like <has>, <willHave>, and <had>, also suggested that Title be defined as a class to validate the XML construct <Document><has><Title eng='a title'/></>, which corresponds with the scripting construct, Document.Title.eng = 'a title'. Using Occam's razor, with my ultimate goal being C# script validation featuring integration of the RDF/A definition for annotation of XHTML legal documents, suggests that a simple scripting construct like Document.Title.eng = 'a title' should have an XML/RDF implementation.

The problem I've tried to solve is that <Document><Title eng='a title'/>, which is the very most direct mapping of Document.Title.eng, is invalid RDF if the attribute (eng) is being associated with a property (Title) -- attributes are only associated with classes in RDF. This meant that <Document><Title eng='a title'/>, to be valid, is an example of a statement with an "anonymous predicate", something acknowledged in the earliest RDF guidelines. The first version of the ontology therefore made Title a class, DocumentTitle a property definition for disambiguating the Document.Title scripting construct, and has/had/etc as RDF predicates to eliminate "anonymous predicates"...

In version 2 of the ontology, I'd like to more closely follow Dublin Core -- which defines Title to be a property not a class. That means that "Document.Title.eng=a title" could be converted to this valid RDF:

<Document>
  <Title>
    <rdf:Literal eng='a title'/>
  </Title>
</Document>

A more complicated example converts Document.Creator.Name.eng='JMcClure' into

<Document rdf:ID='R12345'>
  <Creator>
    <rdf:Description rdf:ID='R54321'>
      <Name><rdf:Literal eng='JMcClure'/></Name>
    </rdf:Description>
  </Creator>
</Document>

The has/had/etc predicates are introduced as a lgl:verb property of a Statement, extending the RDF.

<Statement rdf:ID='Statement01'>
  <rdf:subject rdf:resource='R12345'/>
  <lgl:verb rdf:resource='has'/>
  <rdf:predicate rdf:resource='Creator'/>
  <rdf:object rdf:resource='R54321'/>
</Statement>

which could then be serialized to XML in a manner identical to how RDF now allows node identifiers on a predicate element such as <Creator> (the rdf:node attribute implements so-called "rdf quads" you may have heard about).

<Document rdf:ID='R12345'>
  <Creator lgl:verb='has' rdf:node='Statement01'>
    <rdf:Description rdf:ID='R54321'>
      <Name lgl:verb='has'><rdf:Literal eng='JMcClure'/></Name>
    </rdf:Description>
  </Creator>
</Document>

which can be equivalently stated as

<Document rdf:ID='R12345'>
  <Creator lgl:verb='has' rdf:resource='R54321' 
           rdf:node='Statement01'/>
</Document>
<rdf:Description rdf:ID='R54321'>
  <Name lgl:verb='has'><rdf:Literal eng='JMcClure'/></Name>
</rdf:Description>

Or it can be serialized to XML using <has> as the predicate element:

<Document rdf:ID='R12345'>
  <has lgl:predicate='Creator' rdf:node='Statement01'>
    <rdf:Description rdf:ID='R54321'>
       <has lgl:predicate='Name'><rdf:Literal eng='JMcClure'/></has>
    </rdf:Description>
  </has>
</Document>

which can be equivalently stated as

<Document rdf:ID='R12345'>
  <has lgl:predicate='Creator' rdf:resource='R54321' 
       rdf:node='Statement01'/>
</Document>
<rdf:Description rdf:ID='R54321'>
  <has lgl:predicate='Name'><rdf:Literal eng='JMcClure'/></has>
</rdf:Description>

The upshot of all this is that the naming convention is being changed. Rather than defining single-word nouns as the names of classes, single-word nouns are becoming the names of properties; properties such as DocumentTitle are being eliminated since they are unneeded. Title now becomes the name of a property, while practically all classes are named using at a minimum, two-word nouns. For instance, the noun Class is now the name of a property, while the nounpair ClassNode is the name of the class that is the range for the Class property.

The third difference between the two versions of the ontology is a new foundation based on decomposition of the Directed Acyclic Graph (DAG). DAGs are a semantic pillar of the RDF and I am very proud to be the first to literally entwine concepts in network databases (models and nodes) with RDF's statements and contexts.

&lt!-- Script Examples -->
MyModel = new DAGModel;
MyModel.Node.1 = new DAGNode;
MyModel.Node.2 = new LiteralNode;
MyModel.Node.2.eng = "my title';
MyModel.Arc.1 = new StatementNode;
MyModel.Arc.1.Model = MyModel;
MyModel.Arc.1.Subject = MyModel.Node.1;
MyModel.Arc.1.Object = MyModel.Node.2;
MyModel.Arc.1.Verb = Ontology('has');
MyModel.Arc.1.Predicate = Ontology('Title');
MyModel.Arc.1.Name.eng = "has.Title.1.eng";

I needed to do this in order to substantiate the DAGs that I developed in other contexts which name its arcs differently than seen on DAGs published by the W3 -- I put dotted-names (such as "has.Title.1.eng") onto arcs, simultaneously referencing both a predicate-verb (has) and predicate-noun (Title) while also indicating both the position (.1.) of the arc within some collection and the language (eng).

Anyway, I am pursuing these tasks with great enthusiasm; I want to integrate what I've learned over the summer about UML, DAGs, aspect-oriented programming, state-transition diagrams, RDF quads, context, and so on into the ontology -- making a much stronger product.

</div>