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

URIs may not mean *exactly* what you think when looking at them (was: Re: less-restrictive range and domain terms)

From: Benja Fallenstein <b.fallenstein@gmx.de>
Date: Tue, 04 May 2004 21:18:35 +0200
Message-ID: <4097EC8B.9070704@gmx.de>
To: "Rhoads, Stephen" <SRhoads@ThruPoint.net>
Cc: "'www-rdf-interest@w3.org'" <www-rdf-interest@w3.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rhoads, Stephen wrote:
| <slightlyOffTopic>
|
|>>I understand what you mean: intuitively, "the" right
|>>range of pet:owner might be foaf:Person.
|
| Until someone comes along and wants to say:
|
| Benji rdf:type ex:Dog
| Benji pet:owner ex:AtlantaPoliceDepartment

I was assuming that pet:owner is defined so that it does have rdfs:range
foaf:Person, in a similar way that foaf:mbox is defined to be an inverse
functional property.

(I'm aware that pets may be 'owned' by something else than a person,
although I was more thinking of e.g. families. Restricting pet:owner to
people makes sense when you're specifically interested in pets owned by
individual persons.)

What I think you're ignoring above is that text in URIs and the qnames
that abbreviate them is only mnemonic -- it does not *define* what the
URI means, it's only a hint.

I think that's an important point. You say,


| What to do?  Range is something broad like "Entity"?  And when someone
finds
| a valid use for pet:owner with a "non-Entity"?

but if the precise meaning of pet:owner does *not* include general
"entities," much less "non-entities," such a use would not be 'valid'
and would not make sense. If I see a use for

~    Annie foaf:mbox <mailto:AandEMiller@example.com>
~    Elin  foaf:mbox <mailto:AandEMiller@example.com>

then that doesn't change the fact that it's not a *valid* use -- even
though the address was obviously specifically created to be used by
Annie and Elin together, so if you look only at the qname, 'foaf:mbox,'
the above makes perfect sense. The problem is that it defies one of the
very purposes of foaf:mbox, namely identifying people (well, entities
;-) ) uniquely.

If I want to express the above semantics, I should make up my own
property that is defined with the semantics I intend.

And the very same thing applies to "global domain and range constraints
within the context of the Web." Their point is being able to infer
something -- in our example, that the object of pet:owner is a person.
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.
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.

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.)

Cheers,
- - Benja
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAl+v9UvR5J6wSKPMRAke3AJ9sg5N1V/UBlpFMVGBR6xw40EetFwCg0eHr
EjNYD3nBrPwDsAHqV0Wg1Hw=
=q70u
-----END PGP SIGNATURE-----
Received on Tuesday, 4 May 2004 15:19:48 GMT

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