Re: SEM/GUIDE: subclasses of classes of Properties? (5.3)

On Thu, 2002-08-08 at 11:46, Christopher Welty wrote:
> Dan, et al,
> 
> You said from this:
> 
>   my:KeyProperty rdfs:subClassOf owl:FunctionalProperty.
>   db:key rdfs:range db:KeyProperty.
>   fred:Order db:key fred:customer.
> 
> It should follow that:
> 
>   FunctionalProperty(fred:customer)
> 
> This example is so confusing, you couldn't have picked a better way to 
> show that there are huge misconceptions going on here.

Yes, my use of 'key' is misleading. Change it to db:knorfel and
the logic of the example remains the same (though the real-world
motivation goes down quite a bit.)

>  We really need a 
> semantics.

Well, the RDFCore WG has a semantics for RDFS, and the above
follows from it.

> There are a number of problems with this example:
> - You are using db:key but you are not getting a database key

right; maybe I meant foreignKey or something; I'll have
to think about the example some more.

> - Clearly an order shouldn't have customer as a database key
> - You have exposed *exactly* the kind of incompleteness that making the 
> language too expressive introduces.
> 
> 
> The real source of the confusion is the symbols you have chosen and what 
> they mean outside of this example.  key, order, and customer all have 
> real-world meanings, and here you are giving them a semantics that is not 
> consistent with that real-world meaning.

Yes, I chose db:key poorly.

> Even if there was a reasoner which could conclude this (which there never 
> will be),

Umm... there are at least two of them today: Euler and cwm.
I think there are a bunch of RDFS tools that will come
to the above conclusion too.


> if your goal from this example is simply to conclude 
> FunctionalProperty(fred:customer), all you are saying is that an order has 
> only one customer.  You are NOT saying that it is a "key" in the database 
> sense.

Right.

> As I have said in the description of the functionalProperty feature, 
> functionalProperty is weaker (less constrained) than the notion of a 
> database key.  In the database sense of "key", it is a 1:1 relationship 
> which, *for a specific table* uniquely identifies a row in the table, 
> however the "same" "property" could be used in another table and not be a 
> key. Since  owl:functionalProperty is a global restriction, concluding 
> FunctionalProperty(fred:customer) would mean that anywhwere fred:customer 
> is used, it is functional, even if it is used in instances of other 
> classes than fred:Order.
> 
> What you want is some sort of local restriction on fred:Order for the 
> fred:customer relation, and a restriction on the inverse of fred:customer 
> that it can have only one fred:Order.

No, I don't want to use restrictions on fred:Order; I want to use
a different lavel of abstraction to describe the only-one aspect
of fred:customer. I want FunctionalProperty to be usable like
any other RDFS Class.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 9 August 2002 09:19:18 UTC