W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2002

Re: Meaning of URIRefs (Argument for the entailment)

From: Sampo Syreeni <decoy@iki.fi>
Date: Sat, 26 Oct 2002 23:51:00 +0300 (EEST)
To: Sandro Hawke <sandro@w3.org>
cc: pat hayes <phayes@ai.uwf.edu>, <www-rdf-interest@w3.org>
Message-ID: <Pine.SOL.4.30.0210262256150.19499-100000@kruuna.Helsinki.FI>

On 2002-10-25, Sandro Hawke uttered to pat hayes:

>Claim-1b does kind of use the term "Mammal", in that it includes by
>reference the text of Doc-1.

I'd also want to join the fray, arguing to the contrary. The claim sorta
uses the term, yes, but actually you have no way of knowing what it does
with it:

Claim-d-1: Doc-1 is on the web at address URL-1; Doc-1 is known to encode
RDF; we however cannot interpret Doc-1, because [...].

Also, since we would eventually want some kind of reification to work,
(even if we abandon the current formalism), asserting everything that we
refer to sounds a bit silly:

Claim-d-2: Doc-1 is on the web at address URL-1; it is self-contradictory
because [...]

Judging by how meticulous today's Web designers are with their data, I
think this will indeed be the commonest result one can expect from
actually calculating the closure of a randomly picked graph and some
well-known facts, and looking for contradictions.

Furthermore, I can't understand why one would want to bind assertional
semantics to simply using a term:

Claim-d-3: Doc-1's name is URN-1; its location is not known.

Claim-d-4: Doc-1 used to be in location URL-1; now the location holds
something else.

Claim-d-5: Doc-1 has two versions online, at addresses URL-1 and URL-2;
the former is self-contradictory; the latter has been corrected; I vouch
for and assert the latter.

>Remember my description of how one communicates at least some of the
>meaning of a term? You publish a declarative statement which is true
>only for certain meanings of the term.

True. But what I'm wondering is why we should force the reader to believe
*everything* you say, and shouldn't let him decide by himself:

Claim-d-6: Doc-1 at address URL-1 contains <statements>; they couldn't
possibly all be true, because <something only we know>+<statements> =>
<contradiction>;  since <heuristics>, it seems likely that statement <one
of the statements> should be dropped.

Claim-d-7: I vouch for and assert the contents of document in location
URL-1, excepting <less than plausible statements>.

>What would it mean for me to say, "Spot is a member of the class of
>things called 'Dog' in Doc-1, although Doc-1 is not a true statement"?

Claim-d-8: Doc-1 is self-contradictory because [...]; what the author
probably means is [...] because [...]; class Dog seems especially useful;
Spot is a member of the class Dog.

Finally, I strongly object to the notion of anybody "owning" the terms
used in RDF. As far as I can see, strings are nobody's property, just as
words in a language aren't. Most of the time it's in my interest to use
terms as they commonly are, but there are exceptions. The above claims
represent a few of them.

I think it's no coincidence that "trust" is part of the layer cake --
people use terms as they wish, and they should; others should rank how
trustworthy such usage is, and act accordingly. I can never see trust as
emerging from legal sanctions (e.g. making people responsible for what
they assert) or appeals to authority (e.g. decreeing that Dog as defined
by Sandro is what a dog is). I also can't see how lasting interoperability
can be reached if one always has to define a new term when one wants to
change the definition of an older one. If everybody refers to dogs as
members of sandro:Dog, I'd rather build up a community using my new
definition of dog, name my dog sandro:Dog, and compete for signatures on
the trust level. That saves us from a lot of trouble should Sandro's
definition prove the right one, after all.
Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Saturday, 26 October 2002 16:51:10 UTC

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