W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2004

Re: URIs may not mean *exactly* what you think

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 5 May 2004 09:30:19 -0400 (EDT)
To: Benja Fallenstein <b.fallenstein@gmx.de>
Cc: "Rhoads, Stephen" <SRhoads@ThruPoint.net>, "'www-rdf-interest@w3.org'" <www-rdf-interest@w3.org>
Message-ID: <Pine.LNX.4.55.0405050915100.14126@homer.w3.org>

On Tue, 4 May 2004, Benja Fallenstein wrote:
a sound explanation, leading to...

>There are other uses, too, but this is the most fundamental one. If you
>don't like that from a pet:owner triple you can infer that the object is
>a foaf:Person, you can make up your own property.
>So my point in this e-mail is: You seem to be saying that global domain
>and range constraints should not be used -- or maybe even ignored when
>they are used -- because they prohibit valid uses of certain properties.

>But if the owner of the property gives it a range constraint that says
>that object X is not in its range, than using it with an object X
>*cannot* be a valid use of the property. You could say that prohibiting
>these uses is pointless nitpicking, but it's not, because it is what
>allows us to make useful inferences! And nothing gets less expressive,
>because you can make your own URI that expresses the semantics you want.

It is true that statements about a property or class are what give RDF and
OWL reasoning power. It is not true that there is an owner of a property - if
I declare that range of pet:owner is the union of foaf:Person and things of
the type represented by wordnet:Gorilla, then I will go on inferring that
this is the range. And so will anyone else who picks up my declaration,
unless they are actually tracking contexts/provenance/trust/whatever you like
to call it.

>You could say that it's better to use standard terms, but it is NOT
>better to use standard terms for something else than what they were
>defined for -- and that is what you do if you violate the owner's domain
>or range constraints.

I agree (with the caveat that the owner of a property is really only defined
by the application that consumes it)

>So it's not domain and range constraints that are the problem, it's
>ignoring the URI owner's definition of a term, including those
>constraints, that is the problem. Looking at the name of a property
>doesn't suffice to use it correctly.
>(I think that's an important point, which is why I reply so elaborately.
>Sorry for the long mail.)

Yes, I think it is an extremely important point.

It also clarifies my "owner" comment. As far as I know, the RDF Core working
group, whose official language is english as spoken in the USA are not
capable of providing a spanish comment and label for the schema for RDF/RDFS.
So I wrote one in conjunction with some well-qualified spaniards, as a set of
RDF statements. (Sadly, I think I may have lost it in a recent equipment
catastrophe, but I can do it again).

While my assertions about these classes and properties are not made by "the
owner", there may not be any good reason not to use them - for example for
building a spanish interface for an RDF tool.

The working group may even be able to retrospectively bless them. If I  get a
Basque version, I don't think there is anyone who can make meaningful comment
on that in the working group, or in any other definition of "owner". In a
good system it would be nice to be able to decide whether to trust my
statements based on what others say about them, but we don't really have that
kind of machinery standardised yet. In the meantime, if I put them onto the
Web one would expect RDF harvesters to find them, and for people to use them,
unless they have some specific hacks to represent some model of ownership...

My point, at such length, is that there is no inherent reason why people
cannot refine the definition of a property that someone else initially
defined, and in some cases this is valuable. But as Benja points out, there
are good reasons for being VERY conservative in doing so...


Received on Wednesday, 5 May 2004 09:30:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:51 UTC