Re: issue 5.10: a position statement (sameState over peopleKey)

Dan - I'm confused as to the import of the peopleKey example - have 
looked at the rdf (btw, there's a small bug - you use "oneto99" 
instead of "oneto9" at one point)  - you are going to pick a member 
of your family and assign them a key from that range.  Since there 
are potentially more than 10 family members, there will be someone 
who cannot be assigned a range - but it seems you're asking the 
system to recognize a logical inconsistency at a "definitional" level 
that doesn't occur until you try to use them -- that is, you haven't 
said everyone of these people will be assigned a key.  So it seems to 
me that until the 11th time you ask for this to be used, the system 
is fine -- and there's no way for the system to read your ontology 
definitions and know for sure that you will eventually ask for all 
these people (maybe you're just picking names for your future kids 
and if you end up never having that 11th, you'll never get in 
  It would be nice to have validators that could say things like "I 
notice you only are assigning ten keys to a list that could 
potentially eventually have an 11th element, so please be careful" 
but I'm not convinced there really is a logical inconsistency in such 
a definition.

  This is a long-winded way of saying I find being able to do the 
state stuff more compelling than the potential personkey problem...

At 1:39 PM -0500 7/18/02, Dan Connolly wrote:
>On Thu, 2002-07-04 at 09:07, Peter F. Patel-Schneider wrote:
>>  I feel that there are really two different positions on issue 5.10
>>  (DAML+OIL semantics are too weak).
>>  The first position is that what matters most is getting the entailments
>>  correct for OWL.  This position would support entailments like
>>	John belongs to the intersection of Student and Employee
>>	entails
>>	John belongs to the intersection of Employee and Student
>>  and many other natural entailments.
>>  The second position is that what matters most is making OWL have the exact
>>  same syntax as RDF and have its semantics be an extension of the RDF
>>  semantics.  This position would support entailments only if they can be
>>  done without disturbing this compatability.
>>  I find the first position by far the most compelling.  I cannot understand
>>  why OWL should be potentially crippled by forcing it into a overly-strict
>>  compatability with RDF.
>OWL is uninteresting, to me, on its own.
>OWL is only interesting inasmuch as, when making new RDF vocabularies
>(or refining descriptions of old ones),
>widespread deployment of OWL allows me to use owl terms to constrain
>the meanings of the terms in my RDF vocabulary in such a way that
>lots of other folks will understand those constraints.
>If I can't use OWL along with the mozilla open directory,
>Adobe's XMP tools, RSS 1.0, CC/PP, PRISM, MusicBrainz,
>etc. (see, then I don't
>understand why I'm working on it. By "along with" I mean:
>in the same documents, with the same domain of discourse,
>with all the entailments justified by the RDF Core specs.
>Meanwhile, I wonder if this sort of rhetorical debate is likely
>to get us anywhere.
>I would prefer to debate the specifics of the sameState
>vs. peopleKey test cases (along with any other specific
>test cases and tools that are available). As far as I can tell,
>we can't expect software to get both of them right
>any time soon.
>On the basis of my experience as a user and an implementor,
>I prefer that our spec justifies the sameState entailment, and
>it's acceptable to me if it doesn't justify the peopleKey entailment.
>This does not support the "detecting inconsistency" goal, but as
>far as I can tell, it doesn't contradict any of our agreed requirements.
>As an example of this experience, please see:
>   Semantic Web Travel Tools
>Dan Connolly, W3C

Professor James Hendler
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)

Received on Thursday, 18 July 2002 17:03:48 UTC