There are multiple serialisations available to store OWL2 ontologies. While the language structure is specified in Abstract Syntax, a more human-friendly serialisation is Manchester Syntax. As both are serialisations of OWL2, they should be equipotent. However, some features are known to be inexpressible in Manchester Syntax. Most commonly known is the lack of expressing general concept inclusions in Manchester Syntax. This paper analyses the Manchester Syntax grammar and identifies a total of 19 inexpressible features and eight minor errors in the current Manchester Syntax grammar. Furthermore, changes to the Manchester Syntax grammar are proposed to make it equipotent to Abstract Syntax. The proposed changes are implemented in the OWL API1.
For example, consider the following:
SubClassOf ( ObjectIntersectionOf( :a :b ) :c ) This expression cannot be expressed in Manchester Syntax directly as the class frame only allows a named class and no complex class expression.
like style. The previous example would be written as
:a and :b SubClassOf :c
This serialisation, however, is not valid Manchester Syntax and trying to save ontologies containing such axioms in Manchester Syntax results in those axioms being dropped.
The W3C note for OWL2 Manchester Syntax contains an algorithm to translate Manchester
Syntax to Abstract Syntax. This translation is achieved by first converting every frame to
multiple simple frames with the same subject. Therefore, previously grouped axioms relating to
the same entity exist as single axioms. Now each frame expresses a single axiom which can be
transformed using a transformation function . is given by a table recursively
defining the transformation for each possible input. −1 is, therefore, the inverse of the function
working as a reverse lookup in . The translation is depicted in Figure 1. [
It is stated to run the algorithm in reverse to convert an ontology from Abstract Syntax to Manchester Syntax. However, the steps provided in the algorithm - especially the transformation function - are written from a Manchester Syntax point of view, making an injective function from Manchester Syntax to Abstract Syntax. cannot be bijective as at least general concept inclusions are known to be not supported in Manchester Syntax.
The existing transformation table does not map axioms directly but uses a meta-language describing how a given ontology in Manchester Syntax can be transformed to Abstract Syntax. Keeping this style, for each rule in the Abstract Syntax grammar containing terminal elements, there must be an entry in such that () = . Therefore, each non-terminal element in is replaced by ().
Manchester Syntax, although is not bijective. To find missing features in Manchester
Syntax to Manchester Syntax. It is defined by a transformation table . Using the whole
grammar [
EquivalentTo: :b . At the end, = { | ∄ : () = −1() = } contains all inexpressible features of Manchester Syntax.
In total, there are 27 features found not expressible in Manchester Syntax when strictly following the existing grammar and transformation function. Those include spelling mistakes such as “FunctionalObjectProperty” instead of “ObjectFunctionalProperty” and other minor errors in such as annotations being required in classFrame rule. Excluding such errors, 19 features are left that are truly inexpressible. Table 1 lists the 19 features not supported in Manchester Syntax.
The lack of expressivity of Manchester Syntax can be remedied a bit using conservative extensions. Namely, an ontology in Abstract Syntax can be extended conservatively, and then this conservative extension (which is even purely definitional) can be mapped to a an equivalent ontology in Manchester Syntax. This is possible if the Abstract Syntax ontology does not use the identified missing “DataSomeValuesFrom”, “DataAllValuesFrom”, or “Declarations” features and works as follows:
A general concept inclusion { ⊑ } can be written as { ≡ , ⊑ } with being a new atomic concept, a complex concept and a complex or atomic concept.
In the same manner, a complex role inclusions { ⊑ } can be written as { ≡ , ⊑ } and any other missing feature involving complex object property expressions e.g. {SymmetricObjectProperty()} as { ≡ , SymmetricObjectProperty()} with being an atomic role, a complex role, and a complex or atomic role.
However, working with such conservative extensions often is inconvenient, because the ontology will be cluttered with additional (often rather artificial) extra concepts and roles. Therefore, we will extend Manchester Syntax in a way that directly supports all Abstract Syntax features.
Having identified inexpressible features of OWL2 Manchester Syntax, the following proposes changes and additions to the existing Manchester Syntax grammar and translation table . It adds support for all missing features. All changes are analysed for backwards compatibility.
The proposed grammars utilise the meta-rules described in [3, Section 2]. Additionally, minor errors (like spelling mistakes) are corrected implicitly.
DataSomeValuesFrom and DataAllValuesFrom Although practically not usable, as data ranges with arity greater than one are currently not expressible in Abstract Syntax either[4, Section 7], adding the capability to Manchester Syntax removes the need to remember and adjust this once expressing data ranges with arity greater than one is possible. This feature can be added by allowing tuples of class expressions and single class expressions in the rule for restriction. The tuples must be surrounded by parenthesis to ensure the grammar stays unambiguous. Consequently, the following entries and rules must be added to and the grammar, respectively.
Manchester Syntax
Abstract Syntax (1, ..., ) some (1, ..., ) only
DataSomeValuesFrom( (1) ... () ())
DataAllValuesFrom( (1) ... () ()) restriction ::= ...
| ’(’ dataPropertyExpressionList ’)’ ’some’ dataPrimary | ’(’ dataPropertyExpressionList ’)’ ’only’ dataPrimary Annotations in declarations Allowing declarations to be annotated can be achieved in multiple ways. One way is to change the semantics of an Annotations: frame section inside a frame. According to , this is currently mapped to an AnnotationAssertion axiom in Abstract Syntax with the frames subject as annotation subject. Instead, this annotation could be added to the Declaration axiom.
A second approach is to allow the Annotations: section - annotations non-terminal in the Manchester Syntax grammar - in front of the IRI of a frame’s subject. In contrast to the first proposal, this change keeps backward compatibility as annotations are optional. Consequently, the following entries and rules must be changed in and the grammar, respectively.
Frame AnnotationProperty: annotations IRI . . .
Class: annotations IRI . . .
DataProperty: annotations IRI . . .
Datatype: annotations IRI . . .
Individual: annotations IRI . . .
ObjectProperty: annotations IRI . . .
Declaration Declaration ( () AnnotationProperty ( IRI ) ) Class ( () Class ( IRI ) ) Declaration ( () DataProperty ( IRI ) ) Declaration ( () Datatype ( IRI ) ) Declaration ( () NamedIndividual ( IRI ) ) Declaration ( () ObjectProperty ( IRI ) ) datatypeFrame ::= ’Datatype:’ [ annotations ] Datatype ... dataPropertyFrame ::= ’DataProperty:’ [ annotations ] ← ˒ dataPropertyIRI ... annotationPropertyFrame ::= ’AnnotationProperty:’ ← ˒ [ annotations ] annotationPropertyIRI ... individualFrame ::= ’Individual:’ [ annotations ] individual ... Features with object property expressions as subject Many features inexpressible in Manchester Syntax have object property expressions as a subject. In Manchester Syntax, however, the subject of a frame can only be an IRI, thus an object property. Changing the subject from IRI to object property expression adds support for the following axioms to be used with object property expressions: • SubObjectPropertyOf • ObjectInverseOf • ObjectPropertyDomain • ObjectPropertyRange • InverseObjectProperties • FunctionalObjectProperty • InverseFunctionalObjectProperty Nevertheless, simply changing the ObjectProperty: frames subject would also allow statements describing AnnotationAssertion axioms. However, AnnotationAssertion axioms can only have an IRI as the subject. Hence, the grammar must ensure such cases are not possible. Apart from the AnnotationAssertion axiom, all derivations of the objectPropertyFrame non-terminal produce valid axioms with the proposed changes. However, complex object property expressions cannot be declared. Hence, no additional entry in the declarations table is added. In addition to the changes in “Annotations in declarations”, leading annotations are not allowed if a complex object property expression is used. Consequently, the following entries and rules must be added to or changed in and the grammar, respectively. The following table only contains the translation for ObjectPropertyDomain. All other axioms mentioned above are translated similarly. Note that the non-terminal OPE is only introduced for better readability.
Manchester Syntax ObjectProperty: Domain: description Abstract Syntax ObjectPropertyDomain( T(annotations) () T(description)) OPE ::= objectPropertyExpression simpleObjectPropertySection ::= complexObjectPropertySection | ’Annotations:’ annotationAnnotatedList complexObjectPropertySection ::=
’Domain:’ descriptionAnnotatedList | ’Range:’ descriptionAnnotatedList | ’Characteristics:’ ← ˒
objectPropertyCharacteristicAnnotatedList | ’SubPropertyOf:’ ← ˒
objectPropertyExpressionAnnotatedList | ’EquivalentTo:’ ← ˒
objectPropertyExpressionAnnotatedList | ’DisjointWith:’ ← ˒
objectPropertyExpressionAnnotatedList | ’InverseOf:’ ← ˒
objectPropertyExpressionAnnotatedList | ’SubPropertyChain:’ ← ˒
annotations OPE ’o’ OPE { ’o’ OPE } objectPropertyFrame ::= ’ObjectProperty:’ [ annotations ] IRI ← ˒
{ simpleObjectPropertySection } | ’ObjectProperty:’ OPE { complexObjectPropertySection } General concept inclusions and HasKey A naive approach extends the misc frame to include GCIs and HasKey axioms. It already contains all axioms not fitting to any other frame. General concept inclusions containing complex class expressions instead of a simple class IRI could be considered as such. Similarly, the HasKey axiom can be added there too. However, this approach introduces two new keywords breaking backwards-compatibility.
A much more natural way is to extend the class frame. Currently, it is possible to express a SubClassOf axiom only with a simple IRI as a subclass. Changing this IRI to description a complex class expression - allows expressing general concept inclusions. Furthermore, this change also allows expressing HasKey axioms with complex class expressions. Additionally, an IRI being a valid class expression ensures the backwards compatibility of this change.
Similar to changing the object property frames subject, changing the class frames
subject might lead to invalid axioms. In addition, the DisjointWith section must also be
excluded. It is mapped to the DisjointUnionOf axiom in Abstract Syntax. Similar to the
AnnotationAssertion axiom, the DisjointUnionOf axiom allows only a class and not a
complex class expression [
Manchester Syntax Class: SubClassOf: Class: 1 EquivalentTo: 2 Class: 1 DisjointWith: 2 . . . Class: HasKey: Abstract Syntax SubClassOf( () () ()) EquivalentClasses( () (1) (2)) DisjointClasses( () (1) . . . ()) HasKey( () () ()) simpleClassSection ::= complexClassSection | ’Annotations:’ annotationAnnotatedList | ’DisjointUnionOf:’ [ annotations ] description2List complexClassSection ::= ’SubClassOf:’ descriptionAnnotatedList | ’EquivalentTo:’ descriptionAnnotatedList | ’DisjointWith:’ descriptionAnnotatedList | ’HasKey:’ [ annotations ] ( objectPropertyExpression | dataPropertyExpression ) { objectPropertyExpression | dataPropertyExpression } classFrame ::=
’Class:’ [ annotations ] IRI { simpleClassSection } | ’Class:’ description { complexClassSection }
We implemented the presented extensions in the reference implementation OWL API in the pull requests 10502 for version 5 and 11043 for version 4. They are available in the OWL API version 5.5.0 and waiting to be merged for version 4.
During the implementation, it turned out, that the OWL API already supports object property expressions as frame subjects: Their implementation follows the proposed changes of section 4. Furthermore, and as mentioned, the OWL API does not support DataSomeValueFrom and DataAllValuesFrom for data ranges with an arity greater than one. Therefore, changes in the underlying data types are required. This is a major change with no current practical use. Hence, these two features are not implemented in the OWL API. 2https://github.com/owlcs/owlapi/pull/1050 3https://github.com/owlcs/owlapi/pull/1104
A translation from OWL2 Abstract Syntax to OWL2 Manchester Syntax was constructed yielding 19 inexpressible features (27 including minor errors in ) in Manchester Syntax. A change of the existing grammar and translation table is proposed for each such inexpressible feature. With these changes, all constructs expressible in OWL2 DL are expressible in Manchester Syntax, marking both syntaxes equipotent. A collection of axioms in Figure 2 highlight the features and show what constructs can now be expressed in Manchester Syntax.
The proposed changes have been implemented in the OWL API and are available from version 5.5.0 and once merged will be available in the next version 4 release. With these changes, the more human-readable Manchester Syntax can be used for serious ontology development without drawbacks. While many developers use tools such as Protégé independent of the serialisation, these features are still essential: For example, manually resolving conflicts or tracking changes when developing with a version control system such as git is much simpler in Manchester Syntax than in Abstract Syntax or XML.