[Impr] Structural Specification and Functional-Style Syntax

[I'm confining my comments to document issues, mostly]

1) The first issue I have is that I don't understand the relation  
between this document, esp. its UML diagrams and the MOF-Based  
Metamodel document. In general, I'm not exactly sure what is gained  
overall from having both UML and a grammar. I believe that the UML  
represents some aspects not available in the grammar e.g., setness of  
some constructs:

	dataOneOf := 'DataOneOf' '(' constant { constant } ')'

doesn't express that the arguments form a set (that is, neither the  
unorderedness nor the lack of duplicates is captured by the  
production), yet the UML diagram does express that.

Of course, one might argue that this is a feature of the semantics of  
the semantics of the construct. And where one does this is a bit  
tactical: in this case, some bits which can be normalized away by  
using certain data structures in an api (e.g., a set rather than a  
list) the spec encourages us to normalize away.

For some purposes, perhaps the majority of them, this is fine. But I  
wonder if this is wise for certain classes of application, e.g.,  
editors, transformers, anything which should preserve surface aspects  
of the syntax. I think some discussion of this is appropriate and  
perhaps separating out the Metamodel, or having a metammodel which  
was less directed to structural identity. At the very least, we need  
some user (not just api developer) feedback.

2) Second, I'll point out that this has been a very successful  
document. The OWL API has been rewritten from this spec (and several  
other implementors have chimed in positively) and used as the basis  
of Protege4 and OWLSight as well to support new services (e.g.,  
module extraction, explanation finding). There were several positive  
post to public-owl-dev about this spec.

3) This is both a language and and a presentation issue: I think  
annotation properties should be entities (i.e., introduced in section  
4.1 and the UML diagram) and I think annotations are big deal and  
need to be better dealt with, including:
	Structured annotations
	Multiple annotations on entities (less important) and axioms (very  
important)
	Annotations for language extension (with mustUnderstand and  
mayIgnore like features)
		For example, we've used axiom annotations to expression conditional  
constraints (i.e., probability axioms) and for attaching ontoclean  
properties. In the former, you *may not* ignore them; in the latter  
you can.
	Reasoning with and constraining annotations; people shouldn't be  
forced to punning or to owl full to use dublin core property inheritence
	Etc. etc.
	(There is an OWLED task force devoted to this called  
"RichAnnotations".)
	(These are based on work I'm doing and on feedback from a variety  
people including folks at the National Cancer Institute.)

I might break out and group annotations together instead of having  
entity annotations at the end of the entity section and axiom  
annotations in the axioms one.

4) I'm not the hugest fan of the relentlessly typed syntax,  
especially when it's reflected out into user syntax and especially  
when both the constructor and the arguments are verbosely typed (as  
in the XML syntax).

5) The notion of structural consistency is interesting, and, in fact,  
is sort of there in OWL DL (though overloaded into expression  
typing). I think I might want something

Small bits (I'll enter them into the proposed issues list):

Should we move to CURIES instead of QNames?
	http://www.w3.org/2001/sw/BestPractices/HTML/2005-10-21-curie

It would be good to have links from this document to the various  
syntaxes, if this can be done unobtrusively.

I recall some problem in extracting the grammar....but I don't  
remember what it is. An informative "single grammar" as an appendix  
or note would be helpful.

This document corresponds to section 3 of the OWL 1.0 Semantics and  
Abstract Syntax document:
	http://www.w3.org/TR/owl-semantics/syntax.html

I'm unclear why "Classes" are a top level section and not a  
subsection of "The concept language" and indeed of "entities".

Cheers,
Bijan.

Received on Tuesday, 16 October 2007 15:48:31 UTC