Proposal for a new ontology and N3 format for RDF + OWL + rules projects

© J.M. Vanel - 2010-03-10 - under Creative Commons Licence - $Id: project_ontology.html 2137 2011-02-23 12:31:04Z jmvanel $

Summary

Proposal for a new N3 format for RDF + OWL + rules projects

The context

For the EulerGUI Integrated Development Environment we define a general notion of project for an ontology plus rules URI's.

Indeed it is for a particular tool, but it is a strength to have a specific project which demonstrates the concept of ontology plus rules URI's.

Also we seek the broadest applicability, and to reuse as much vocabulary as possible, particularly OWL .

The current situation

Having an XMLEncoder file was convenient at first, but it means that the implementation Java classes are in the project persistance file, which is very unflexible! Also, the setters are called when too little is known, namely in our case the base URL of the project.

And of course, since we strongly believe that N3 is the exchange format that will enable universal data exchange, we must have an N3 project file!

Here is a sample of the current input file:

<java version="1.6.0_15" class="java.beans.XMLDecoder"> 
 <object class="eulergui.project.Project"> 
  <void property="n3Query"> 
   <object class="eulergui.project.N3Source"> 
    <void property="URI"> 
     <string>./maven-pom.n3</string> 
    </void> 
   </object> 
  </void> 
  <void property="sources"> 
   <void method="put"> 
    <string>
     http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml
    </string> 
    <object class="eulergui.inputs.N3SourceFromXML_Gloze"> 
     <void property="URI"> 
      <string>
       http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml
      </string>
     </void> 
     <void property="otherFile"> 
      <string>
       http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml
      </string> 
     </void> 
    </object> 
   </void>
   <void method="put"> 
    <string>./plants.n3</string>
    <object class="eulergui.inputs.N3Source">
     <void property="URI">
      <string>./plants.n3</string>
     </void>
    </object>
   </void> 
  </void> 
 </object> 
</java>

Example

This example corresponds to the old XML format example above.

The official version is on Subversion: newproject.n3p.n3

@prefix : <http://eulergui.sf.net/ontology/project.owl.n3#>.
@prefix owl:  <http://www.w3.org/2002/07/owl#> .

<> a owl:Ontology .
# the main N3 query
<> :hasN3Query <plants-q.n3> .
               <plants-q.n3> :isMainQuery true .
# Import of a XML document
<> :hasRDFImport
   <http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml>.
   <http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml>
     :hasFormat <http://www.w3.org/XML/1998/namespace> .
# plain OWL Import of a RDF document; being an N3 document
# it can also contain rules and formulas
<> owl:imports <plants.n3> .
               <plants.n3> :isActivated false . # true by default

<> owl:imports <subproject.n3p.n3> . # recommanded suffix .n3p.n3
<> :subproject <subproject.n3p.n3> .
<> :postProcessing <project-post.n3p.n3> . # there can be only one postProcessing

The EulerGUI "Project" ontology

Like Protégé 4, we reuse the OWL Ontology as a wider Project object. This means that the owl:imports property is used to specify N3 sources containing OWL or rules, and traditional OWL sources.

Note that, AFAIK, Protégé silently converts into OWL an RDF Schema. Currently in EulerGUI this is not implicit.

Another difference is that in EulerGUI, currently, all ontology, data and rules are in imported documents, whereas in Protégé (that is, OWL) ontology, data and rules can be in the main document or in imported documents, and so on recursively.

In Protégé rules (necessarily SWRL) are embedded in an ontology (probably also in imported ontologies ?); in EulerGUI rules (necessarily N3 logic for now) are embedded in an N3 source.

This N3 will be copied to http://eulergui.sf.net/ontology/project.owl.n3, and also commited to ../src/main/resources/eulergui/gui/controller/project.owl.n3 for use by the application.

The core EulerGUI "Project" ontology

The official version is on Subversion: project.owl.n3

TODO : update wrt to Example <<<<<<<<<<

@prefix : <http://eulergui.sf.net/ontology/project.owl.n3#>.
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

:URLSource a owl:Class
    ; rdfs:comment """just an auxiliary class for a data source that has
                      either a dereferenciable URL or a relative URL."""
 .

:RDFImport rdfs:subClassOf :URLSource
     ; a owl:Class
     ; rdfs:label "RDF Import"
     ; rdfs:comment """RDF import means that a non RDF source like plain XML, XMI, etc
                       is converted in a well defined way into an RDF/N3 document."""
 .

:hasRDFImport a owl:ObjectProperty
     ; rdfs:domain owl:Ontology
     ; rdfs:range :RDFImport
     ; rdfs:label "has RDF Import"
     ; rdfs:comment """In addition to its regular content, an owl:Ontology
                       has RDF Imports that aware applications add to the regular
                       content."""
 .

:hasURL a owl:DatatypeProperty
     ; rdfs:domain :URLSource
     ; rdfs:range xsd:anyURI
     ; rdfs:label "has an (absolute) URI"
     ; rdfs:comment "a dereferenciable URI for the RDF import"
 .
:hasRelativeURL a owl:DatatypeProperty
     ; rdfs:domain :URLSource
     ; rdfs:range xsd:string
     ; rdfs:label "has a relative URI"
     ; rdfs:comment """a relative URI for the RDF import, relative to the base URI of
                       the importing Ontology.
                       An RDFImport has either a relative URI, or an (absolute) URI,
                       but not both."""
 .

:isActivated a owl:DatatypeProperty
     ; rdfs:domain :RDFImport
     ; rdfs:range xsd:boolean
     ; rdfs:label "is this RDF source activated during inferencing?"
     ; rdfs:comment """It is convenient to have data sources belonging to
                       the project just as reference or trial."""
 .

:hasN3Query a owl:ObjectProperty
     ; rdfs:domain owl:Ontology
     ; rdfs:range :URLSource
     ; rdfs:label "has an (absolute) URI"
     ; rdfs:comment "a dereferenciable URI for the RDF import"
 .


In addition to the above core EulerGUI "Project" ontology, we are considering two designs for expressing the format of imported documents (plain XML, XMI, etc) :

  1. use inheritance (rdfs:subclassOf) from the base class :RDFImport , leading to classes like RDFImportFromXML, RDFImportFromXMI, RDFImportFromXSD, RDFImportFromSPARQL
  2. use an enumerated property :hasFormat with domain :RDFImport, and with values coming from their XML namespace or specification URL , like <http://www.w3.org/XML/1998/namespace> for plain XML .

    Possibly there could be a further hint for polymorphic formats like XML and XMI, but EulerGUI is able to "pre-parse" an XML document to know the XML Schema associated to the root, and for XMI it relies on the extension .uml or .xmi, .mof, etc .

We choose design 2, but we are open to arguments ...

:hasFormat a owl:ObjectProperty
    ; rdfs:domain :URLSource
    ; rdfs:range  [
        owl:oneOf (
            <http://www.w3.org/1999/02/22-rdf-syntax-ns#> # RDF/XML (possibly OWL)
            <http://www.w3.org/TeamSubmission/turtle/> # Turtle (no formulas and rules)
            <http://www.w3.org/TeamSubmission/n3/> # N3 (possibly formulas and rules)
            <http://www.w3.org/TR/owl2-xml-serialization/> # OWL/XML
            # plain XML, non RDF/XML nor OWL/XML nor XMI
            <http://www.w3.org/XML/1998/namespace>
            <http://schema.omg.org/spec/XMI> # XMI (UML, eCore, MOF, etc)
        ) ]
    ; rdfs:comment """In most cases, by looking at the HTTP Content-type,
                      and/or the extension, or even the beginning of document,
                      the application is able to guess the file format,
                      so this property is facultative."""
 .

Implementation

Advantages Inconvenients Comments
use JenaBean does read and write possibly not flexible; introduces yet another dependency
use the EulerGUI Java instantiator reuses EulerGUI technology; very flexible; possibly apply validation rules does only the N3 ==> Java objects conversion;

for the reverse need to populate an RDF database through observer Design Pattern, but we plan to do that anyway (called the "conscience" of the application)

Insert Java application objects in the KB a variant of the preceding; simplifies further, as Java objects are directly instantiated, queried and updated to investigate: can the Java objects ==>N3 conversion be further simplified ?

We'll do that; migration path below to be updated

Insert Java application objects in the KB along with business objects

I think to add in the new WM (ApplicationKB) Java objects directly, without passing through a stage of instantiation . See "Insert Java application objects in the KB along with business objects" : N3 - Java mapping .

Rules for the instantiating Java application objects after reading EulerGUI project

Here is a sample of the N3 rules creating the Java objects for the EulerGUI Project from the RDF graph; they are used when an EulerGUI Project is opened from the new N3 format. We apply the N3 logic design pattern "annotate the existing objects".

RDFImport resources are mapped to objects of type Java class N3Source.

The official version is on Subversion: project-java-rules.n3 .

@prefix java: <http://java.sun.com/class#> .
@prefix javam: <http://java.sun.com/method#> .

{ ?ONTO a owl:Ontology .
} => {
  ?ONTO a java:eulergui_project_Project .
  ?ONTO java:url ?ONTO .
}.

{ ?ONTO a owl:Ontology .
  ?ONTO :hasRDFImport ?IMPORT.
  ?IMPORT :hasFormat <http://www.w3.org/XML/1998/namespace> .
  ?IMPORT :hasURL ?URL .
} => {
  ?IMPORT a java:eulergui_project_N3SourceFromPlainXML .
  ?ONTO javam:addN3Source ?URL .
}.

{ ?ONTO a owl:Ontology .
  ?ONTO :hasN3Query ?Q .
  ?IMPORT :hasURL ?URL . 
} => {
  ?Q a java:eulergui_project_N3Source .
  ?ONTO javam:addN3Source ?URL .
}.
# TODO N3 searches, isActivated; other formats .....

Migration path from XML projects to projects in N3

TODO : update , related to "Insert Java application objects in the KB"

The steps will keep the application working:

  1. add one RDF database for the application, or per N3 Project (a Drools Working Memory)
  2. populate the RDF database by the observer Design Pattern on the Project class (for runtime events)
  3. populate the RDF database after reading the old XML project ( in Project.prepare() )

    these 3 steps already allow the rule engine to do usesul thing upon events like adding an N3 source ...

  4. when closing the application, write the RDF database on an N3 file with extension .n3p.n3 (use the Jena pretty printer like in the second yellow button)
  5. read a new N3 Project file with extension .n3p.n3 : use the above rule set, plus the Java Instantiator
  6. the last step is independant of the new format:

    populate on demand (recursively) the Project class with OWL imports : either add some Java callback, or do it with a rule that will look into the OWL imports, using the builtin log:parsedAsN3 (see CwmBuiltins ; this builtin lacks today in the Drools N3 engine )

At one point or another, we must somehow merge the classes N3Source and Project. Indeed an N3Source can contain owl:imports triples, which must be interpreted as sub-projects in the EulerGUI sense. In the other direction, a Project will soon be saved as OWL in N3 format.

One way to merge the classes N3Source and Project is to add a new interface, IN3Source .

As a side benefit, we can now use unlimited properties about the project itself, like Dublin Core, or simply :

<> rdf:label "name of the project".

to be displayed in the GUI.