Ontology  Library Correspondence

An OWL ontology uses URIs to name classes, datatypes, properties, and individuals. Each of these named units will have one or more corresponding elements in the .Net library generated from that ontology.  This document describes both lexical and semantic aspects of this correspondence.

Although this document contains some examples, its description of the correspondence is primarily generic.  For many readers, it will help to observe the precise details in a complete example.  The library source code, camera.cs, and the ontology, camera.owl, from which it was produced, may be found in camera.zip. An alternative to looking at the actual source code is to view the classes, interfaces, and method prototypes of the assembly containing the library through the Microsoft Visual Studio object browser. This assembly, camera.dll, is also contained in the archive.

Lexical Correspondence

A URI contains an XML namespace and a local name, each of which is a string. Each named entity in an ontology is mapped by the ontology compiler into one or more named entities in a .Net assembly.  The identity of the .Net entities is determined by mappings From XML namespaces to .Net namespaces, and from XML local names to .Net names.  The default mapping defined by the algorithms below should provide acceptable .Net names in almost all circumstances, but can be overridden if needed by explicit annotations supplied to the compiler.

Namespace Mapping

An XML namespace string xns is mapped to a legal .Net namespace string by the following sequential algorithm:
  1. The XML schema (all leading characters of xns through the first ":") and immediately following "/"s are discarded.
  2. Whitespace characters are removed.
  3. Each "/" is replaced with a "."
  4. Any sequence of two or more consecutive "." characters is replaced by a single "."
  5. If the final character is a ".", it is discarded.
  6. Any character that is not a letter or a decimal digit is replaces with a "_"
  7. If the charcater immediately following any "." is a decimal digit, then a "_" is inserted between the "." and the digit.

Namespace Mapping Examples

XML namespace = http://www.xfront.com/owl/ontologies/camera/
.Net namespace = www.xfront.com.owl.ontologies.camera

XML namespace = http://www.w3.org/TR/2003/PR-owl-guide-2003  12   09/wine
.Net namespace = www.w3.org.TR._2003.PR_owl_guide_20031209.wine

Local Name Mapping

The local name of a named entity in an ontology is mapped to a base name for the .Net entity or entities that correspond to it by the following sequential algorithm:

  1. Whitespace characters are removed.
  2. If the first character following a removed whitespace character is a letter, the letter is capitalized.
  3. Any character that is not a letter or a decimal digit is replaced with a "_".
  4. If the first character is a decimal digit, a "_" is inserted before the first character.

Note that any label attribute value(s) assigned to a named entity in an ontology are ignored in determining the base name for the corresponding .Net entities.

Local Name Mapping Examples

XML Local Name = 1st infantry
.Net Base Name = _1stInfantry

XML Local Name = M&M
.Net Base Name = M_M

Semantic Correspondence

The semantic correspondence between named entities in an ontology and named entities in the generated .Net assembly are presented for each of the four categories of OWL named entity. Only .Net entitities that are exposed to clients of the generated assembly will be discussed.  The semantic elements and correspondences described here are those that will exist in the absence of any compiler annotations.

Class Correspondence

For each named class Co in an ontology, the generated assembly will contain both a .Net class Cn and a .Net interface In.  Both will reside in the .Net namespace that is the image of Co's namespace. The name of C will be local name image of Co's local name.  The name of In will be identical to the name of Cn with an "I" prefixed to it.  For example:

Co = http://www.xfront.com/owl/ontologies/camera#Lens
Cn = www.xfront.com.owl.ontologies.camera.Lens
In = www.xfront.com.owl.ontologies.camera.ILens

The .Net class will inherit the class Teknowledge.ontologyCompiler.Runtime.Thing, a class implemented in the Runtime assembly. The .Net class Cn corresponding to an OWL class Co will implement the interface In. The interface In will inherit the interfaces corresponding to any direct superclasses of Co. If Co has no superclasses other than owl:Thing, then In will inherit the interface Teknowledge.ontologyCompiler.Runtime.IThing. 

The combined effect of this inheritance scheme is that each .Net class will implement  all the the interfaces corresponding to superclasses of Co. Client applications will generally use the interface types, In, as the static types for fields, variables, parameters, and return types.

The .Net class Cn will have two constructors.  One requires a single parameter, a Model (discussed below),  the second requires two parameters, a Model and a string.  The string is stored as the uri of the newly created instance (discussed below). The first constructor is said to create anonymous instances of Cn.  Each instance of Cn is considered to belong to the model supplied to the constructor.  The model to which an instance belongs if fixed for its lifetime.

The compiler will understand that one ontology class Cosup is a superclass of a second ontology class Cosub if an explicit rdfs:subClassOf triple relates the two classes in the ontology.  The compiler relies on certain reasoning capabilities of HPs Jena 2 Java class library to uncover other entailed subclass relationships among ontology classes.  This reasoner is not complete; for some ontologies, subclass relationships that are implicit in the ontology semantics will not be discovered and as a result will not be reflected in the interface inheritance of the generated assembly.

>>Model and Thing Classes<<

The assembly corresponding to a compiled ontology will have a .Net class named "Model".  This class will be defined in the .Net namespace that is the image of the XML namespace to which the ontology being compiled belongs.  The Model class will inherit from the class Teknowledge.ontologyCompiler.Runtime.BaseModel, found in the common Runtime assembly.

For each named ontology class Co in the compiled ontology, the .Net model class will provide a property for enumerating instances of that class belonging to a model instance. If the base name of the .Net class corresponding to Co is  c, then the property for enumerating instances of the class will be named  I+plural(c) and  the value it returns  will belong to a class whose name value whose I+plural(c)+_Enumerable. For example, if the ontology contains a class named "Camera", the model class will have a property named "ICameras" returning a value of type "ICameras_Enumerable".  The latter class implements the standard .Net interface IEnumerable. The objects enumerated by the result include objects whose .Net class is any class that implements In.  For example, iterating through the model.ICameras might produce instances whose class is Camera as well as instances whose class is DigitalCamera.

The algorithm for pluralizing a name consists of a few trivial, English-specific, morphology heuristics.

The interface Teknowledge.ontologyCompiler.Runtime.IThing is defined by the runtime assembly, as is a class Teknowledge.ontologyCompiler.Runtime.Thing which implements that interface.  The .Net class generated for an ontology class always has Thing as a base class.

IThing provides a method named Delete. This method clears all references to other objects, including the IThing's model, from the fields of the IThing, and removes all references to the IThing from the model and from any maintained inverse property indices.  Applications should not use an instance after applying the Delete method.  Unless the client application has retained its own live references to the deleted IThing, it will be garbage collectible following deletion.

IThing has several public, read-only, properties. The property named Model returns the BaseModel instance to which the IThing instance belongs -- the BaseModel supplied to the constructor. The properties named URIs, labels, comments, and seeAlsos each return a .Net StringList instance. The constructors leave all these lists empty, with the exception of the two-argument class constructor mentioned above, which places a single value in the URIs list.  Although the properties themselves are read-only, the list returned as the value of each property can be manipulated with all the StringList methods.

Datatype Correspondence

The compiler maps a subset of the predefined XML Schema datatypes to native .Net value types. This correspondence is depicted in the following table:

XML datatype

 .Net type

































Although String is technically a reference type in the .Net framework, string instances are immutable.  As a result, String behaves like a value type and is a suitable mapping for the XML string type.

For each of the .Net datatypes in the table, a "list" class is provided in the Runtime assembly. These classes all reside in the Teknowledge.ontologyCompiler.Runtime namespace

All XML datatypes not listed in the table above are currently mapped to the .Net type String.

Property Correspondence

The object and datatype properties in an ontology are mapped to read-only, parameter-free,  .Net properties.  In OWL, object and datatype properties have names (URIs) of their own, just like classes.  In .Net, however, properties are "subordinate" to classes, having only simple names without namespaces.

Suppose Po is an ontology property and the most specific known domains of Po are {Co1 ... Coj}.  The .Net interface Ini, produced for Coi (1 i j) will have a property whose name is plural of the base name image of Coi's local name.  For example, if the ontology property http://www.xfront.com/owl/ontologies/camera#cost  has a single most specific domain -- http://www.xfront.com/owl/ontologies/camera#PurchasableItem -- then the .Net interface www.xfront.com.owl.ontologies.camera.IPurchasableItem will have a property named costs.

The value returned by the property will be the .Net list type for the effective .Net range of the property. Suppose the most specific known ranges of an object property Po are {Co1 ... Cok}. The most general named class Cr that is subsumed by each of the Coi is computed.   Cr is the effective ontology range of Po, and  the .Net interface produced for Cr is the effective .Net range of Po.  In the case k>1, Cr may be a subclass of the actual intersection of the Coi

In the case of a datatype property Do, suppose the most specific known ranges are {To1 ... Tok}.  If k=1, then To1 is the effective ontology range of Do, and the .Net type corresponding to To1 is the effective ontology range of Do. If k  1, then xsd:string is the effective ontology range of Do and System.String is the effective .Net range of Do.


Individual Correspondence

Retention of ontology URIs

Treatment of Imports