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

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.


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 Wednesday, 17 July 2002 13:51:58 UTC