Ontology Representation:

Case Study ReSpecTh

An ontology is a machine readable representation of knowledge. In this case study, a data specification, that was originally generated by hand and is in text form, will be translated into an ontology representation.

The purpose of a data specification, such as the ReSpecTh specification used in this study, is to give an ‘exact’ description of the format of a data structure. A specification can be used, for example, to build the data structure, to interpret the data structure or to (by hand) validate a data structure. Such a specification is only human interpretable and cannot lead to automation of building, interpreting or validating the data structure.

An ontology, in particular how it is implemented in this case study, can be viewed as a machine readable specification of objects and classes of objects and their relationship.In contrast to a specification in text form, an ontology is indeed machine interpretable and can thus be used to automate procedures that would normally be done by hand.

However, if all the information contained in the specification can be translated into RDF form, meaning an ontology, then all the tasks that could previously done only by humans could, in principle, be automated.

In this case study, the classes of ontology objects correspond to the elements of the ReSpecTh specification of the XML data format of the ReSpecTh database. The relationships describe the children of elements and their attributes.

The goal of this case study is to represent all the information and relationships in the hand-generated specification as an ontology. This includes the additional (informal) specifications that are found in the descriptions of the elements.

There are several advantages of using an ontology representation of the specification. The first is that the hand written specification is made more rigorously formal. The second is that it is not a passive descriptive specification but an active specification where questions can be asked about the specification. The ontology specification can be actively used to verify, generate and automatically interpret data formats which use the specification. The specification gives additional machine interpreted semantics and meta data to the specification.

Translation Process examples and explanations

specification translation: general overview

In the following, a general overview of how the elements of the specification were translated to an ontology.

The ReSpecTh specification of the XML data format is basically a description of the individual elements making up the data format. Below is a diagram (found in the documentation) of the structure of an ReSpecTh element.

Click on the red dots to see how each of the individual parts of the elements were translated.

General Structure of the ontology classes

The root elements, ‘experiment’, ‘kdetermination’ and ‘xmllfile’ have corresponding ontology classes, ‘Experiment’, ‘KDetermination’ and ‘XMLInfo’ under ‘Root Element’. The children that appear in these elements have corresponding ontology classes under ‘RespecthChildOfRootElement’. Some of these elements, for example ‘Ignition Type’ (the ontology class for ‘ignitionType’) are divided into subclasses. Though they may represent one ReSpecTh element, due to their implicit properties (for example explanations in the description). Other elements appear as children which are not used in the root elements. These are found under ‘RespecthChildNonRootElement’.

Within the element definition, Attributes can be assigned. Each of the possible attributes are also assigned to ontology classes.

An addition set of ontology objects are subclass objects of ‘RespecthClassification’. When a attribute or element has a set of distinct values, then it is assigned to an ontology element. The subclasses of this element are the possible values. For example, the attribute ‘type’ in the ‘ignitionType’ element has 7 distinct values. This root nodes of the classes under ‘RespecthValidIgnitionTypes’ correspond to these 7 values. The label of these ontology objects is the value and the comment is the explanation given for the value

Elements

The ontology equivalent to ‘Elements’ is an ontology class. There is one ontology class for each element in ReSpecTh.

The classes are arranged in classes and subclasses. For example, in the diagram under RespecthClasses, there are several subclasses. The root elements are shown under ‘Root Element’, where the subclasses are the three types of root elements, Experiment, KDetermination and XMLInfo.

Under ‘RespecthChildElement’ can be found the hierarchy of child elements used in the specification.

Element description and identifiers

Associated with every ontology class describing an ReSpecTh element is a set of Annotations.

This is set of meta data associated with each element. Three annotations found for all element classes are:

identifier This is the name of the element used in the XML format to indicate this element.
rdfs:comment This is the verbatim description text found in the element
rdfs:label This is a label or title related to the element (used for example in a GUI).

All the text in the description is always given. This is keeping with the philosophy that 100% of the ReSpecTh specification is found in the ontology description, i.e. no information is lost or forgotten. However, sometimes the description gives some added information about relationships and restrictions of the element. These are, as best as possible, translated to ontological relationships. This is explained in detail elsewhere.

children

A ReSpecTh element can have one or more children. As described earlier, each element has a corresponding ontology class. This means that each child of an element has a corresponding ontology class. The element with the children point to the corresponding child class through a subclass of the connector ‘has member’. In the language of RDF, this corresponds to

‘Experiment’ ‘hasMandatoryMember’ ‘Data Group’

The SPARQL query to, for example, find all the mandatory member of the ‘experiment’ ontology class shown is:

SELECT ?p ?member
WHERE { 
respecth:RespecthExperiment rdfs:subClassOf ?restriction .
?restriction owl:onProperty ?p .
?restriction owl:onClass ?member
}

M/O/N/F state

For each element and attribute, the mandatory/optional/non-handled/forbidden state (M/O/N/F) state is given. In the ontology each of the states is represented by a subclass of the ‘hasMember’ (for children) and ‘hasProperty’ (for attributes).

Child of

In stating the relationship ‘has mandatory member’ where one element is the child of another. The ‘Child of’ relationship is implicit, meaning it is following the link of ‘Children’ backwards. Thus the relationship:

‘Experiment’ ‘has mandatory member’ ‘Data Group’

specifies both that ‘Experiment’ has a child element ‘Data Group’, but also the ‘Data Group’ is a child of ‘Experiment’.

Attributes

An element can have a set of attributes. Each attribute corresponds to ontology class under ‘RespecthElementAttributes’

The attributes of an element are noted by the predicate ‘has property’. In the language of RDF this corresponds to:

‘Species Link’ ‘has property’ ‘CAS’

To isolate the mandatory or optional properties of the ‘speciesLink’ element the following SPARQL command could be used:

SELECT ?p ?ans
WHERE { 
respecth:RespecthSpeciesLink rdfs:subClassOf ?restriction .
?restriction owl:onProperty ?p .
?restriction owl:onClass ?ans .
FILTER(?p = respecth:hasMandatoryProperty || ?p = respecth:hasOptionalProperty)
}

text content

The ‘Text Content’ is specified in the annotations by a ‘dcformat’ label. This label specifies which type of text is expected. This is pointed to by an ontology class that is a subclass of ‘RespecthTextFormatClassification’. In the ‘fileDOI’ example shown, the text type is ‘file DOI’. Specifying the type of text opens up the possibility for automatic validation of the text that is found in the XML file.