Navigation

Introduction Differences source
Lite Syntax Lite Mapping Lite Triples
DL Syntax DL Mapping DL Triples

Differences from Published Syntax

Fundamental Differences

This section lists differences between this revised syntax and the published syntax that are non-optional. i.e. without these differences it is not possible to present triple tables like the ones given.

Equivalent Classes etc.

In the published abstract syntax the most problematic mapping rules are those for:

The problem with these is that they potentially generate a number of blank nodes with very specific (and non-tree like) structures between them. It is highly awkward to articulate these structures.

In place of these, a new construct is added to the abstract syntax (classComparison) which can be used to reflect the same relationships. Since each classComparison is syntactically part of a class or description definition and takes exactly one argument, the mapping rules then map it to a single triple.

Some syntactic category for annotation properties

The published syntax treats urirefs that are not used as classIDs, propertyIDs etc, as possible annotation properties.

This revised syntax explicitly categorizes such urirefs. The choice of category I made was for simpleObjectPropID and simpleDataPropID. This allows the annotation properties to have a weak participation in the subProperty hierarchy. Since the latest proposed semantics for annotations do not permit that, I will post a further version of this syntax which instead uses a single category annotationPropID.

Simplified restriction abstract syntax

The published abstract syntax permits multiple restrictions to be made on a single property in a single expression. The mapping rule for this is complex. Removing this feature of the abstract syntax does not reduce the expressive power of the abstract syntax but simplifies both the mapping rules and the expression of OWL Lite in triples.

Aesthetic TradeOffs

Some of the differences could have been avoided but at the cost of making the description of the triples form more complicated. The first of these could be perceived as an uglification of the abstract syntax.

Allowing Descriptions as Directives

In the published syntax, blank nodes corresponding to descriptions must be the object of some triple. To avoid having this constraint, and also to accomodate the changes made by dropping EquivalentClasses and DisjointClasses, the revised syntax permits both descriptions and restrictions as top-level axioms.

The intended semantics of these constructs is essentially the same as the intended semantics in the published syntax for an EquivalentClasses with one element. i.e. Any urirefs used must be of classIDs or propertyIDs as appropriate.

Reduced number of optional typing rules

In the published mapping rules, there are some rdf:type triples that are optional, which if omitted result in a generated node with no type triples. These rules are made compulsory, since it is difficult to articulate which such triples are optional other than by using the mapping rules.

Adding a class for DataRange

It would be possible to follow the main themes of the proposed revision and still have dataranges as untyped blank nodes. However, it is clearer in the triple form if every node must have a type.

owl:ObjectProperty sometimes optional

This change makes the mapping rules more complicated, in particular requiring a note outside the mapping rule formalism.

rdf:type owl:ObjectProperty is redundant on nodes which are explicitly typed as owl:InverseFunctionalProperty, owl:SymmetricProperty or owl:TransitiveProperty.

owl:Ontology must be explicit for objects of owl:imports, owl:priorVersion ...

Since the published syntax does not support owl:priorVersion, this is also a bugfix. However, it would have been possible to explicitly permit the omission of the owl:Ontology triple on the object of such properties.

RDF Compatibility

builtin names

The main change, which is partly a bugfix, partly a clarification and partly a change, is to have an explicit table of builtin urirefs in place of the overly strong "the abstract syntax form does not mention any of the URI references from the RDF, RDFS, or OWL namespaces that are given special meaning in RDF, RDFS, or OWL except owl:Thing and owl:Nothing. " in the published document.

This is a bugfix in as much as OWL properties and classes that are currently excluded from the published document are explicitly allowed (these include owl:DeprecatedClass, owl:priorVersion etc.).

This is a clarification in that the constraint is expressed with the abstract syntax rather than with the mapping rules.

This is a change in that harmless RDF(S) vocabulary is permitted, unless explicitly forbidden.

A further change is to explicitly have the infinite set of properties rdf:_NNN builtin as owl:ObjectProperty's. Consider a user wishing to combine the RDF container vocabulary with OWL Lite. They can fairly easily declare, for example, rdf:Bag as an owl:Class, but are faced with a more difficult problem with the unbounded set of properties. This changes fixes that problem.

terminals aligned with RDF Concepts

The terminals of the abstract syntax ( uriref , lexicalForm and language) are explicitly aligned with their corresponding concepts in RDF Concepts. This is motivated by our character model requirement.

xml:lang and rdf:XMLLiteral supported

No more needs to be said.

annotation properties

This version of the revised syntax has annotation properties as simpleObjectPropIDs and simpleDataPropIDs. This means that such properties can be declared, have a restricted participation in the subProperty lattice, and can themselves be annotated. These are all features found in RDFS user-defined annotations (such as the Dublin Core annotations). None of these features are available for annotation properties in the published abstract syntax. To access some of these features from the published documents an RDF schema that is not imported could be used. (However, to align with the proposed semantics for annotations, at least the participation in the subProperty lattice will need to be removed).

Additional Features

I have added two expressivity features to the syntax; these may be mistakes if the semantics is not straightforward.

Named DataRanges

The published syntax only permits the reuse of dataranges by copy and paste. e.g. in the ugly test case, if a further property was defined with the same rdfs:range, it would be necessary to repeat the whole construction for the datarange.

Instead I suggest permitting named dataranges, and dataRangeID's. This has the beneficial side-effect of permitting rdfs:Literal back into the grammar as a dataRangeID.

Possible semantic problems include what to do with a dataRange that is defined twice (I assume that this is consistent iff the two definitions list the same set of values), or what to do with a datarange that is not defined (I assume this can be treated as rdfs:Literal).

Individual Comparisons with Unnamed Individuals

The published syntax only permits the use of owl:sameIndividualAs or owl:differentFrom between two individualIDs. Partly because that seems confusing at the RDF/XML level, the revised syntax permits the subject or object or both to be an unnamed individual (shown as a blank node).

This may be seen as posing semantic problems if there is real difficulty in equating two blank nodes. (However, this seems no different from a functional property used to equate two blank nodes).

Bugfixes

owl:DeprecatedClass

Added, presumably semantically an annotation.

owl:DeprecatedProperty

Added, presumably semantically an annotation.

owl:priorVersion etc.

These properties are not just normal annotations since they cannot apply to classes. Hence they motivate a new syntactic category metaProperyID; which I understand to have been limited to the ones we defined (i.e. no user defined metaProperties are permitted).

These metaProperties relate ontologyIDs with ontologyIDs. The object of the metaproperty must be declared as an owl:Ontology.

Presumably semantically these are annotations.

Transitive Property Side Condition

The side condition on transitive properties is incorrectly expressed in the published documents "Individual-valued properties that are transitive, or that have transitive sub-properties" which is vacuously true.

The intended condition is expressed by using distinct syntactic categories for:

The revised approach also clarifies how this side condition interacts with inverseOf.

Imports

The published WD does not permit three level imports, or an imported ontology to have the

<owl:Ontology rdf:about="">

header declaration.

This is fixed by:

Equivalent Properties

The published syntax permits an equivalent properties statement with a single property in it. Hence:

EquivalentProperties( datavaluedPropertyID )
entails
DatatypeProperty( datavaluedPropertyID )

But the corresponding entailement does not hold after the operation of the mapping rules.

The fix is to require at least two properties in an EquivalentProperties axiom.

owl:Thing on individuals

This is a very minor point, the mapping rules in the published document do not force the use of owl:Thing on individuals with no other type. This constraint is expressed in text. The revised mapping rules express the same intent as a set of rules.