Re: SEM: 5.1 literal/data values (sameState, peopleKey TESTs)

On July 17, Dan Connolly writes:
> 
> re
>    ACTION connolly point to use case for having datatypes
>      and obejct property in integrated domain
> 
> [[
> For example, U.S. states that have the same 2-letter
> postal code are the same state. So if I know
> 
>   :stateCode a ont:UnambiguousProperty.
> 
>   _:x :stateCode "KS".
>   _:x :population "2688418".
> 
>   _:y :stateCode "KS".
>   _:y :stateBird :WesternMeadowlark.
> 
> then I should be able to conclude
> 
>   _:z :population "2688418".
>   _:z :stateBird :WesternMeadowlark.

Of course it would be convenient to do this, but as you know there are
serious computational implications.

On the other hand, by using a slightly different representation you
may be able to get most of what you want without imposing this
computational penalty on the language. E.g.: everything would be fine
if "KS" were an individual instead of a data value. Alternatively, you
could add an axiom for each state such as:

sameClassAs(oneOf(Kansas), restriction(onProperty(stateCode),someValuesFrom("KS")))

Ian

> 
> 
> Full details, with namespaces spelled out and all that, in:
>   http://www.w3.org/2002/03owlt/sameStateP.rdf
>   http://www.w3.org/2002/03owlt/sameStateC.rdf
> ]]
>  -- http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0261.html
> 
> 
> It's very important to a number of applications I have
> built and seen that this entailment holds.
> 
> 
> Now on to the other case...
> 
> On Tue, 2002-07-16 at 04:39, Jeremy Carroll wrote:
> > 
> > 
> > I was and remain underwhelmed by the discussion.
> > 
> > Ian:
> > > Can I point out that I already did this once! See the thread beginning
> > > with:
> > >
> > > http://lists.w3.org/Archives/Public/www-webont-wg/2002Mar/0241.html
> > >
> > > and in particular:
> > >
> > > http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0354.html
> > > http://lists.w3.org/Archives/Public/www-webont-wg/2002May/0044.html
> 
> Yes, I'm familiar with that thread, but it doesn't show me something
> that somebody wants to do and is unable to do because of the
> interaction between datatypes and unambiguous properties.
> 
> I suppose I should have been more clear in the teleconference;
> this is an "example illustratin computational difficulties in
> having both datatypes and objects in integrated domain" but
> what I'm after is: some plausible end-user requirement that
> conflicts with uniform treatment of datatypes.
> 
> I tried to make this into a test case...
> 
> 
> > To recap ...
> > 
> > Ian:
> > > > Unfortunately, the interaction of UnambiguousProperty and datatypes
> > > > makes this problematical. Imagine, for example, that a datatype
> > > > consisting of integers in the range 0-999
> 
> Firstly, RDFCore's designs for datatypes don't accomodate facets;
> so I can have a datatype consisting of integers, but not
> integers in the range 0-99. I think this sort of design
> is incomplete, but I wasn't able to convince the WG...
> 
>   # user-defined datatype (facet) support needed?
>   Dan Connolly (Tue, Apr 30 2002) 
>   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Apr/0547.html
>   continuing with...
>  
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002May/thread.html#5
> 
> Do we have an issue around datatypes? yes...
> http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.8-Datatypes
> 
> 
> Anyway... despite all that, I do expect we'll be able
> to express, in OWL, a class of integers between 0 and 999;
> something like:
> 
> :OneTo99 ont:intersectionOf (
>   [ is dtaux:valueSpace of dt:integer ]
>   [ dt:maxExclusive "1000"]
>   [ dt:minInclusive "0"]
>   ).
> 
> > > > is used as a unique-id/key
> > > > for instances of the class Person such that all persons have exactly
> > > > one unique-id, all unique-ids are integers in the range 0-999, and
> > > > unique-id is an UnambiguousProperty.
> 
> OK, I can encode all that...
> 
> :uniqueId a ont:UnambiguousProperty;
>   s:domain :Person;
>   s:range :OneTo999.
> 
> 
> > > >  In order to function correctly,
> > > > a reasoner is now required to understand the properties of datatypes,
> > > > e.g., that the cardinality of this particular datatype is 1,000, and
> > > > that as a result no model can contain more than 1,000 instances of
> > > > Person (note that this would not be the case if unique-ids were reals
> > > > in the range 0-999).
> 
> Well, I'd agree that those are consequences of the language semantics,
> but it's not clear, to me, how the intractibility will show up
> in practice.
> 
> Ah... perhaps w.r.t. inconsistency detection...
>   http://www.w3.org/TR/webont-req/#goal-inconsistency
> 
> I've taken the liberty of making something up:
> suppose the range of uniqueID is 0-9.
> 
> And suppose I say that my family has 11 people;
> I should be able to detect an inconsistency.
> 
> to elaborate, suppose...
> 
> :givenName a ont:UniqueProperty. # different name -> different person
> 
> and I say my family has 11 people...
> 
> :MyFamily ont:oneOf (
>   [:givenName "Fred"],
>   [:givenName "Wilma"],
>   [:givenName "Bob"],
>   [:givenName "Susie"],
>   [:givenName "Jill"],
>   [:givenName "Amy"],
>   [:givenName "Jordan"],
>   [:givenName "William"],
>   [:givenName "Gertrude"],
>   [:givenName "Janet"],
>   [:givenName "Mark"],
> ).
> 
> :MyFamily s:subClassOf :Person.
> 
> 
> Then I have contradicted myself.
> 
> test case, with namespaces and all that...
> 
>   http://www.w3.org/2002/03owlt/peopleKeyP.rdf
>   http://www.w3.org/2002/03owlt/peopleKeyC.rdf
> 
> (using old ont: namespace; perhaps out of date
> w.r.t. other namespace changes as well...)
> 
> 
> Hmm... I certainly don't have an implementation that
> passes that test, and yet our requirements suggest
> strongly that it should be supported.
> 
> Hmm... thinking out loud about implementation/specificatoin
> strategy... in the case of integral datatypes
> bounded above and below, we know they're finite,
> and we can figure out their size. And we
> know that
> 	X size XS
> 	Y size YS
> 	X subClassOf Y
> 	=> XS <= YS.
> 
> ... upper bounds on size of oneOf classes are easy,
> but lower bounds involve N^2 differentFrom proofs.
> The NoRepeatsList thing would make life much easier
> (and support R12. Local unique names assumptions).
> 
> Hmm... I'll have to think about it some more.
> 
> Meanwhile, I'd like to think the above two
> test cases (sameSate, peopleKey) are clear enough
> that folks in the WG can say "as a user,
> yes, I expect/want/need that conclusion to
> follow" or not, or "as an implementor, I
> expect to be able to provide that conclusion
> before the sun burns out."
> 
> 
> Jeremy:
> > For me the dog is reasoning about the things people really want to say,
> 
> me too; meanwhile...
> 
> > and the
> > tail is the logical and computational properties analysis that Ian and Peter are
> > so good at. I would be quite happy to permit unambiguous datatype properties and
> > indicate that implementations are not expected to resolve the cardinality
> > issues.
> 
> How do you feel about the peopleKey test above?
> OK if implementations don't pass it?
> Doesn't that seem to contradict our
> "3.4 Inconsistency detection" goal?
> and/or "R16. Cardinality constraints"?
> 
> 
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> 
>

Received on Thursday, 18 July 2002 10:58:35 UTC