ACTION-61 (F2F minutes link fix up) complete and two points

I've added all the missing links in (I hope) a reasonable and  
consistent way. For each set of slides that Alan gave me, there is a  
link in the appropriate section of:
	http://www.w3.org/2007/OWL/wiki/F2F1_Minutes

Please, if you gave a presentation, check your session for the slides  
(and maybe someone elses!) Once Peter checks, we'll have accepted the  
F2F minutes ;)

While doing this I hit two interesting points:

One from Boris:
	""Every OWL API wants to provide "what are the classes in this  
ontology", but what does that mean for OWL?"""

However, my understanding of the current structural specification is  
that this is not answered. Ontologies contain axioms, not classes.  
Are the classes "in" an ontology the classes in the signature of the  
ontology? All terms? Declared classes? Classes mentioned in imported  
ontologies but not in local axioms?

And in this section:

	http://www.w3.org/2007/OWL/wiki/F2F1_Minutes#OWL_DL_and_OWL_Full

There are these two lines from Jeremy:

	Jeremy Carroll: for me the whole point is to get compatibility with RDF
	Jeremy Carroll: A goal is "least surprise" for users of RDF when  
using OWL

This expresses exactly my goals when introducing such features as the  
skolem reading of bnodes, punning, etc. This is the *goal*. I'm happy  
to debate the means and sometimes we have to trade off surprises. I  
think the *general methodology* for achieve less surprise is to look  
at existing systems and behaviors and try to figure out what people  
actually expect. The letter or, I would argue, the spirit of the old  
specs are secondary. Esp. when some aspects of a spec have been  
neglected or misunderstood or just idle.

That's not to say we shouldn't default, all things being equal, to  
specwards compatibility. But most users don't read specs. I've spent  
a *lot* of painful time working on understanding the RDF semantics  
and the various OWL Semantics (including the OWL Full; there are  
definitely people who understand it better than me, I think, but I've  
put in comparable effort as anyone). This knowledge and effort could  
be invalidated by changes. I count that less important than reducing  
user surprise or improving the user experience. (Goodness knows I've  
taken on and encouraged others to take on tough implementation  
challenges! I do want them to be *worth* that effort in terms of the  
user experience.)

So if I get caught up in a "spec implementation technique" as the  
issue that's an error on my part. For example, I'm convinced that  
there are details in the "skolemization" proposal that need work  
(Boris' parse time mapping suggestion has a lot of merit, IMHO). The  
issue is the user problem (how to handle certain classes of RDF graphs).

Cheers,

Bijan.

Received on Wednesday, 16 January 2008 20:24:38 UTC