Re: RDFCore Update

----- Original Message -----
From: <Patrick.Stickler@nokia.com>
To: <geoff@sover.net>; <bwm@hplb.hpl.hp.com>; <www-rdf-interest@w3.org>
Sent: 10/19/2001 11:06 AM
Subject: RE: RDFCore Update


>
>
> Consider a piece of fruit. One may define for a property something like
> 'rdfs:range="#fruit"' and then one could assign various values having
> types such as "#orange", "#banana", "#kiwi", etc., all of which are
> sub-types of "#fruit" and an RDFS schema validator is happy with any
> of them, because they are all valid "#fruit" values -- but nevertheless
> you *still* have to inform the RDFS validator the exact type for each
> value. You can't derive it from the rdfs:range, as that is a general
> type, not the *actual* type -- and you need to know the actual type, as
> it can affect system behavior (one might do things with bananas that one
> would never do with pineapples ;-) and you wouldn't want to have to
> enumerate all the descendant types of "#fruit" as ranges, as that
> precludes flexible extensibility (the ability to define new types of fruit
> which are valid values for that property).
>

I guess I don't see this as an argument for embedding type in a uri (unless
I've misunderstood you). What if you wanted to further classify and object
into an even more specific class? you'd have to give it a new uri?

One solution is to require that an rdf processing system be able to
distinguish between hard (extensional) and inferred (intensional) facts. So
you could ask for the type of #abanana and get the result #banana by just
querying hard facts; or query all facts (hard and inferred) to find that
#abanana is both a #banana and a #fruit. Or you build some rules that can
infer a #mostSpecificType property from all facts (though probably only in a
closed-world sense).

--geoff

Received on Friday, 19 October 2001 11:41:41 UTC