Re: oneOfDistinct, a proposal for 5.18 - Unique names assumption

> [[
> Issue 5.18 - Unique names assumption
> ACTION:  Dan Connolly to write up the 'all different' proposal for Issue
> 5.18.
> ]] -- 12Nov
> OK, trying to get all the relevant stuff on one page...
> let's start with the issue description...
> "The differentIndividualFrom form provides a way of enumerating pairwise
> disjointness between individuals.
> The abstract syntax document mentions DifferentIndividuals that takes a
> list as an argument that then states that all of the individuals in the
> list are distinct.
> Both of these options however still require a complete listing of all of
> the individuals that are distinct either stating pairwise disjointness
> of combining them in a list.
> This issue requests additional support for stating uniqueness."
> This proposal doesn't really address the issue. So it's
> a proposal to add a term to our language that mimics
> the abstract syntax feature described above, but then to
> POSTPONE the issue, since we don't have adequate implementation
> experience with designs for expressing things like
> "all the names in this namespace denote distinct things".
> Let's look at the oneOf section in the guide...
> The example there is
> ----------
> <owl:Class rdf:ID="WineColor">
>   <rdfs:subClassOf rdf:resource="#WineDescriptor"/>
>   <owl:oneOf rdf:parseType="Collection">
>     <owl:Thing rdf:about="#White"/>
>     <owl:Thing rdf:about="#Rose"/>
>     <owl:Thing rdf:about="#Red"/>
>   </owl:oneOf>
> </owl:Class>
> ----------
> note that this doesn't actually say that #White and
> #Rose are distinct things. So let's introduce
> a new property...
> Several of us liked "allDifferent"
> back on 12Nov, but I'd like the guide editors
> and such to noodle on better names, because it
> doesn't flow very well in context. Let's
> go with oneOfDistinct for now...

that's indeed a nice and better name

> <owl:Class rdf:ID="WineColor">
>   <rdfs:subClassOf rdf:resource="#WineDescriptor"/>
>   <owl:oneOfDistinct rdf:parseType="Collection">
>     <owl:Thing rdf:about="#White"/>
>     <owl:Thing rdf:about="#Rose"/>
>     <owl:Thing rdf:about="#Red"/>
>   </owl:oneOfDistinct>
> </owl:Class>
> I propose that the guide editor take an ACTION
> to integrate that example into the section
> on enumerated classes, salting to taste.
> Mike S, does that make sense?
> Likewise, the language reference editor will
> please take an ACTION to add something
> like this to our vocabulary/schema/owl.owl thingy:
>   owl:oneOfDistinct a rdfs:Property;
>          rdfs:label "all different";
>          rdfs:subPropertyOf owl:oneOf.

I think that "a rdfs:Property" is redundant
while also saying rdfs:subPropertyOf

> Mike D, does that tell you what you need to
> know to update the reference doc?
> I dunno if it deserves discussion in the synopsis;
> it's not critical to me. But I'd like an ACTION
> for the feature synopsis editor to think about it.
> As to semantics, here's how I wrote in in N3
> in my experiments (which, due to list handling
> bugs in cwm, never quite worked; Jos, maybe you can
> check my work here. I prefer not to use
> the math:index stuff.)
> { ?C owl:oneOfDistinct ?L } log:implies { ?L a :DistinctList }.
> { ?L a :DistinctList; l:rest ?L2 } log:implies { ?L2 a :DistinctList }.
> { ?L a :DistinctList;
>      l:first ?X;
>      l:rest [ l:first ?Y ] }
>   log:implies { ?X owl:differentFrom ?Y }.

?X owl:differentFrom ?Y could indeed be found that way
but only if they are next to each other in the list, no?

the simplest change I can come up with is

{ ?L a :DistinctList;
     l:first ?X;
     l:rest [ owl:item ?Y ] }
  log:implies { ?X owl:differentFrom ?Y }.

and that works but we have a very poor performance
for large lists e.g. for in our gedcom example at we have a list of 37
items and we then need 153831703 steps (even with some
premis reordering) compared to the 51162 steps (i.e.
a factor of 3000) that we have when using math:indexOf
(we did a similar attempt before but came to similar
poor performance and so looked for something which
gives more of a linear performance with the length of
the list, but I agree it is wild web layer crossing
BTW the math:greaterThan in
is enough because we have
  owl:differentFrom a owl:SymmetricProperty.

> I'm pretty sure Pat Hayes, among others, understands
> what I mean well enough to edit the semantics document accordingly.
> As to test cases, Jos seems to have at least two
> drafted...

well, that's the same testcase, but don't mind

> There. That's it. OK?


> --
> Dan Connolly, W3C

-- ,
Jos De Roo, AGFA

Received on Thursday, 12 December 2002 07:03:51 UTC