| Introduction | Differences | source |
| Lite Syntax | Lite Mapping | Lite Triples |
| DL Syntax | DL Mapping | DL Triples |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No more needs to be said.
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).
I have added two expressivity features to the syntax; these may be mistakes if the semantics is not straightforward.
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).
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).
Added, presumably semantically an annotation.
Added, presumably semantically an annotation.
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.
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.
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:
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.
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.