W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 2002

Re: Meaning of URIRefs (new test case, comments on Concepts draft)

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Fri, 25 Oct 2002 08:47:55 -0400 (EDT)
Message-Id: <20021025.084754.10855354.pfps@research.bell-labs.com>
To: sandro@w3.org
Cc: www-rdf-comments@w3.org

[A discussion on whether using foo#bar commits one to the information
available at foo, moved from www-rdf-comments.]

Sandro's position is that the use of a URI reference commits one to the
entirety of the information in the document that can be found by
dereferencing the non-fragment part of the URI reference.  

The basic problem that I have with this position is that I feel that it
poses a significant bar to communication.  

To pick a very mundane example, suppose that company A has a URI,
http://A.com.ex/invoice.rdf, whose contents consist of invoices.  

The first problem with Sandro's position is that company A has a serious
dilemma in placing identifiers for other companies in these invoices.  The
only reasonable kind of identifier for another company, say company B,
would be a URI reference from a URI controlled by company B.  But the
simple use of this URI reference, say http://B.com.ex#B, commits company A
to everything said on http://B.com.ex.  It is certain that http://B.com.ex
is going to make disputable claims about company B, which company A does
not want to commit to.

The second problem with Sandro's position is that other companies are going
to have problems in disputing the invoices of company A.  The only way they
have to refer to these invoices is via URI references taken from 
http://A.com.ex/invoice.rdf, but just the use of one of these URI
references commits the other company to the information in
http://A.com.ex/invoice.rdf, which is going to include the fact that the
invoice in question is a valid invoice.

I don't see any way around these dilemmas without denying Sandro's

Peter F. Patel-Schneider
Bell Labs Research
Received on Friday, 25 October 2002 08:48:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:01 UTC