W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2009

Re: ACTION-277 complete

From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
Date: Sat, 31 Jan 2009 09:50:06 +0000
Message-Id: <1DE393A8-7809-4776-939E-4F05DAA73D9E@cs.manchester.ac.uk>
To: W3C OWL Working Group <public-owl-wg@w3.org>

On 31 Jan 2009, at 08:21, Christine Golbreich wrote:

> Hi
> I propose to change the sentence: "Please note that we will have a  
> more extensive documentation of the rationale behind this design in  
> the NF&R as well as some discussion in the primer. The working group  
> will contact you when they reach last call to see if the overall  
> solution meets your concerns"
> by
> "Please note that we have added more extensive documentation of  
> hasKey feature in the Syntax, NF&R and a better explanation in the  
> RDF-Based Semantics. The rationale behind this design from a  
> theoretical perspective is summarized in the section Theoretical  
> Perspective" of the NF&R (see http://www.w3.org/2007/OWL/wiki/New_Features_and_Rationale#F9 
> :_Key). We will have also some discussion in the primer.

This doesn't seem to be an improvement. The comment, as an LC comment,  
is directed against, primarily, last call documents (the documents  
mention were Syntax and the "model theory", which I interpret as the  
Direct Semantics"). The change discussed by the working group in  
response was only in the Syntax. That we may do other things in other  
documents that will, in the future, need review is relevant of course,  
which is why I mentioned it. But tying it to specific details of those  
documents which 1) are not responsive and 2) likely to change is not  
helpful. Hence my future looking statement. I intend, at the time that  
Primer and NF&R go to last call that we should point Jim to the  
relevant sections and ask his advice. (Or even ask it earlier, but  
that's not part of the LC response.)

I don't see any scenario wherein the appropriate response is a change  
to the *theoretical* perspective on keys. There was no  
misunderstanding of the theory, afaict, only the *utility* and  
*surprisingness* of it. My changes to syntax help prevent surprise by  
explaining the utility up front. I would hope that NF&R would provide  
a slightly expanded description of the utility. For example (and this  
might help with the reply to <http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0062.html 

"""Keys in OWL are somewhat differently expressive than one might  
expect coming from an RDBMS perspective. For example, it's common to  
think of keys as being *global* to a database, where as OWL keys are  
*scoped* to a class (though that class can be owl:Thing). One key  
reason for this is that OWL is often used in data integration  
scenarios and, in particularly, for integration between multiple  
databases or data sources. The same attribute might be a key in one of  
these and not in another or a key in both but not a key *across* both.  
(For example, keys might be recycled over time due to turn over in a  
workforce, but in OWL we are trying to capture the entire history of  
the data.) In this sense, OWL keys are more expressive than the  
typical RDBMS approach.

Similarly, generally in an RDBMS keys are thought of as *functional*,  
that is, any item can have only one key instance of any particular  
key. (Obviously different attributes might equally well work as keys.)  
One can enforce this in OWL by making the key property functional, or  
maxCardinality|Cardinality 1 for a particular class. There are two  
main reasons that functionality is not enforces: 1) it makes it more  
continuous with relevantly similar constructs in OWL, and 2) in the  
case of multiple databases with the same key attribute, the same  
entity might end up with two different key values (one for each  
database) which is something useful to be able to represent in OWL, So  
this representational freedom is both in the spirit of OWL and helps  
with its general applicability."""

> I'm not sure about the first sentence, "The working group was  
> unsure ..." and prefer to let others to clarify it.

Jim pointed out that two CS PhDs with lots of experience with  
databases didn't see the rationale. Which is fair enough, but  
sometimes a rationale isn't obvious to experts *because* they are  
experts (i.e., they make assumptions other people wouldn't make  
because, well, they know more!). Knowing Jim, I'd be *very* surprised  
if he wanted us to optimize our text for experts! In this case, I  
don't think we did, so its fine.

Received on Saturday, 31 January 2009 09:50:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 31 January 2009 09:50:45 GMT