Warning:
This wiki has been archived and is now read-only.

Structure and Syntax comments Rinke Hoekstra

From OWL
Jump to: navigation, search
Initial Disclaimer
This document is a reflection of my initial comments on the Structural Specification & Functional-Style Syntax

Structural Specification & Functional-Style Syntax

Some general remarks
To the casual reader it is unclear whether this document describes the data structure of OWL 1.1 ontologies, or the file structure... it seems to describe both?
The UML diagrams do not really work for me, but it is hard to think of an alternative

2. Basic Definitions

  • The description of standard BNF notation is unclear:
Nonterminal symbols are written in bold (e.g., owlClassURI), terminal symbols are written in single quotes 
(e.g. 'ObjectPropertyRange', zero or more instances of a symbol is denoted with curly braces (e.g., { description }), 
alternative productions are denoted with the vertical bar (e.g., fact | declaration), and zero or one instances 
of a symbol are denoted with square brackets (e.g., [ description ]).

What is the difference in interpretation between curly and square braces? Both denote "zero or more instances of a symbol".

  • Also, a closing bracket is missing after "ObjectPropertyRange".

2.1 Associations and Object Equivalence

  • The phrasing of the definition of structural equivalence is (superficially) circular if this notion captures 'sameness' between objects:
If o1 and o2 are atomic values, such as strings, integers, or URI, they are structurally equivalent if they are the same.

and for complex objects, it is unclear what the 'corresponding' associations or members of o1 and o2 are.

  • The examples in this section already use the functional-style syntax which itself is being defined by this document: perhaps we should opt to use standard BNF notation instead (to avoid confusion)

2.2 URIs, Namespaces and Integers

  • Not clear why the use of 'URI' is needed to stay compatible with OWL 1.0: Use IRI instead of URI throughout documentation, perhaps add a non-official document explaining the difference between URI and IRI.
  • Also, it is not entirely clear whether the definition 'URI := Full-IRI | Abbreviated-IRI' is compatible with the URI standard, and whether this might raise any backwards-compatibility issues with OWL 1.0 (which only supports URI's, to my knowledge)
  • Typo:
OWL 1.0 uses Uniform Resource Locators (URIs) to identify objects

should be

OWL 1.0 uses Uniform Resource Identifiers (URIs) to identify objects
  • Option is to use CURIEs (cf. Bijan Parsia's remark in [1]) instead of QNames for abbreviated IRIs (am not sure how this will work out with respect to common namespace usage, and e.g. the use of URNs)

3. Ontologies

  • General remark: the document is a bit unclear about the distinction between those things part of the specification (i.e. terminology, definitions etc.) and the rather more practical (expected) use of the specification. For example, the start of this section contains a rather practical remark concerning duplicate axioms:
OWL 1.1 ontology files are, however, not expected to enforce this and can simply eliminate duplicates

Perhaps we should keep such practical, implementation-related issues separate from the structural specification itself as it obfuscates what the spec. itself really is about. In this case the structural spec. may easily become confused with a syntax or file-format specification, something I understand it is not intended to be.

  • ad. Fig.1: as far as I understand this figure does not enforce annotations part of an axiom (which is a strange formulation in itself) to be part of the ontology as well. It just states: ontologies consist of axioms and annotations, axioms consist of annotations as well (actually, I understand that axioms just might 'have' annotations).
  • ad. Fig.1: the figure (and other figures as well) specify that the annotationURI and ontologyURI are both strings, but they are not, they are specific kinds of strings. Perhaps we should use the XML Schema (or OWL1.1 semantics) datatype definitions in UML diagrams, or move the bit in section 4.1 a bit more forward to show that these strings are actually constrained by certain datatype definitions.
  • Wording again:
An annotation consists of an arbitrary annotation URI

is confusing as the annotation URI is an attribute, and the 'consists of' relation between axiom and annotation certainly is not that between a class and an attribute. It is generally better to reserve such parthood-related words for the UML aggregation relation.

  • Why does an 'annotation URI' specify the type of annotation, and the 'ontology URI' the identifier of the ontology? I'd rather either use the former to be an identifier as well and introduce an 'annotation type' of some sorts, or the other way around.
  • Possible compatibility issue: As I read the part about owl:imports, it seems the OWL 1.1 spec. redefines a language construct from the OWL 1.0 specification. In most cases, the 1.1 spec. only introduces new elements for new features. This might cause backwards-compatiblity issues, but I need to read-up on the OWL 1.0 spec.

4.The Concept Language

4.1 Entities

  • ad. Fig.2. Wording, again: e.g. datatypeURI refers to the kind of datatype, and not to the uri of this particular constant. This is ok by me, but then the 'ontologyURI' should be renamed to 'ontologyID'. My point is primarily that we should be clear to distinguish between the datatype of an attribute (URI, string, integer) and the kind of information that is conveyed by the attribute (identifier, type).
  • ad. Fig.2, the owlClassURI etc. are missing from the UML diagram
  • Why have OWLEntity and OWLClass and not OWLObjectProperty, OWLIndividual etc.
  • It is true that from the RDF syntax specification of untyped and typed constants, it follows that only untyped constants can have a language tag, and typed constants cannot?

4.2 Object and Data Property Expressions

  • The definition of inverseObjectProperty seems to suggest that the language allows for infinitely nested inverseObjectProperty statements of the form:
InverseObjectProperty( InverseObjectProperty( InverseObjectProperty ( ... ) ) )
  • Why are ObjectPropertyExpression and DataPropertyExpression defined as interfaces?

4.3 Data Ranges

  • ... nesting holds for dataComplementOf and datatypeRestriction as well. Question: is this a potential problem, or am I nitpicking?

4.4 Entity Annotations

  • This section is slightly confusing as it has never before been stated that an Annotation should be considered to be an Axiom as well.
  • Also, in
Note that an entity annotation axiom provides for two types of annotation -- one for the axiom itself and one for the entity

it is unclear which axiom is referred to in "one for the axiom itself".

5. Classes

  • In the first paragraph, the term description should be introduced: how does it relate to OWLEntity, Axiom etc.?
  • ad. Fig.7,8: description in text vs. Description in figure 7 and 8. Same for object... vs Object... etc. Is this intended?
  • The width-height example is not immediately clear: perhaps it should be a bit more elaborate, or just left out (with perhaps a ref. to a use case)
  • Fig 10. is too wide, and not printable on A4-size paper.
  • The grammar for restrictions on data properties could use a better layout, but I assume this will be dealt with when migrating to the wiki.
  • This section could use some subsections to more easily distinguish between the different kind of restrictions.
  • About the UML diagrams: sometimes the distinction between aggregation-associations (diamond) and regular associations is not very insightful. To my understanding, the aggregation association expresses a 'part-of' relation: a decomposition of the class. But in in figure 7, the association between ObjectComplementOf and Description, and between ObjectUnionOf and Description only differ in cardinality, and not in type. The former could just as well be written as an aggregation association, or the later as a normal association. Perhaps this is merely the consequence of the UML case tool that was used by the designer(s), e.g. possibly only aggregation-associations can be stereotyped as <<set>> or <<list>>. In any case, it seems to add a distinction between associations that does not really exist and cannot be reconstructed from the grammar definition either.

6. Axioms

6.1 Class Axioms

...

6.2 Object Property Axioms

  • Figures 13 and 14 are too wide to print

6.3 Data Property Axioms

  • Figure 15 is too wide to print

6.4 Facts

  • Not immediately clear what a fact is.

7. Nonstructural Restrictions on Axioms

  • This section seems a bit out of place, if compared with the previous sections.

8. Declarations and Structural Consistency

  • There's something wrong with the layout: the text is one indentation level deeper than the rest of the document.