W3C home > Mailing lists > Public > www-webont-wg@w3.org > June 2002

Re: Issue 4.1 UniqueProperty is a bad name

From: Jeff Heflin <heflin@cse.lehigh.edu>
Date: Fri, 14 Jun 2002 16:37:01 -0400
Message-ID: <3D0A53ED.73C4ADF8@cse.lehigh.edu>
To: Dan Connolly <connolly@w3.org>
CC: Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>, www-webont-wg@w3.org

Borrowing from database terminology, here's another option we can choose
from:

UnambiguousProperty -> Key or KeyProperty

A corresponding alternative for UniqueProperty might be InverseKey
(although not as satisfying). Functional would probably work as well.

As for HasOnlyOne, I agree with Mike Dean. I think it is a meaningful
name, but does not work well with the way we have previously expressed
the syntax of these feature in RDF. UniqueProperty is a class, and
properties are said to be a subclass of UniqueProperty. However, saying
"father" is a subclassOf HasOnlyOne doesn't make sense. If the majority
prefers this name, then we should model this feature as a property with
domain and range Class. For example, we could say something like:

<rdfs:Property rdf:ID="bornIn">
   <owl:hasOnlyOne rdf:resource="Country">
</rdfs:Property>

In this case owl:hasOnlyOne could be a subclass of rdf:range, so that it
simultaneously makes a statement about the range and (global)
cardinality of the property. If there was a reasonable analog for
UnambiguousProperty, then I could live with an approach like this one.

Finally, I think ManyToOne and OneToMany are very clear, but they suffer
from the same problem as hasOnlyOne. That is, saying father is a
subclass of ManyToOne just doesn't sound right. Furthermore, I don't
think turning them into properties would help either. One possible
solution would be to leave them as classes, but add Property at the end
of each name (i.e., ManyToOneProperty and OneToManyProperty) but that is
a little too verbose for my tastes. However, I could live with this
option if pushed.

Jeff


Dan Connolly wrote:
> 
> On Thu, 2002-06-06 at 12:31, Frank van Harmelen wrote:
> >
> >
> > I propose to close this issue by renaming this language element
> > as HasOnlyOne,
> > as first proposed by Pat Hayes in http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0146.html:
> >
> > "This will allow expressions like HasOnlyOne Father"
> 
> Hmm... I'm not sure I like it.
> 
> In the presentation syntax I use, that would be:
> 
>         :father a ont:HasOnlyOne.
> 
> Kinda goofy.
> 
> In RDF/XML, it would be:
> 
>         <ont:HasOnlyOne rdf:about="#father"/>
> 
> Hmm... not too bad. I don't suppose I'd object, if it came to that.
> i.e. I can live with that.
> 
> Other candidates I've heard of, in case anybody finds them
> preferable...
> 
>         <ont:FunctionalProperty rdf:about="#father"/>
>         <ont:ManyToOne rdf:about="#father"/>
> 
> By the way... is there a separate issue for UnambiguousProperty
> being a bad name? What would be the analog of HasOnlyOne?
> 
> Analogs of the above two:
> 
>         <ont:FunctionalProperty rdf:about="#father"/>
>         <ont:Injective rdf:about="#personalMailbox"/>
> 
>         (i.e. if ?x personalMailbox ?z
>         and ?y personalMailbox ?z then ?x=?y)
> 
>         <ont:ManyToOne rdf:about="#father"/>
>         <ont:OneToMany rdf:about="#personalMailbox"/>
> 
> I think I prefer ManyToOne and OneToMany.
> 
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Friday, 14 June 2002 16:37:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:50 GMT