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

Re: Meaning of URIRefs

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 25 Oct 2002 11:10:34 -0400
Message-Id: <200210251510.g9PFAYD24471@wadimousa.hawke.org>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: www-rdf-interest@w3.org


In a message sent to www-rdf-comments that was intented for this list,
Peter F. Patel-Schneider wrote:
>
> [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
> position.

The way around these problems is to split definitional content and
general content into different documents.  The definitional content
about the invoice would include information like the invoice number
and an identifier for the parties issuing the invoice.  The general
content about the invoice would include identifying the goods and
services rendered, their prices, etc.  A dispute over the definitional
content would have quite a different quality than a dispute over the
general content; it would probably be resolved by finding the right
invoice.

Similarly, the definitional information about company B should only
make claims which serve to identify company B, such as its official
(name, jurisdiction) pair.  Additional information (such as its
dispute resolution policies) belong elsewhere.

If companies A and B choose not to offer such unencumbered
definitional content, then others are free to do so.  In the worst
case, where no one is willing to publish such a definition, one can
always fall back to doing it with a bNode inside your own document.
This fallback approach requires reasoning about inverse functional
properties instead of just string-equality, but it is already in use
[1] [2].

In situations where the definitions are more complex, and many terms
are interrelated (such as with OWL, DC, CC, RSS, ... basically any
non-trivial ontology) this bNode approach is less feasible.  Then it
becomes more important to have a stable URI for good definitional
content, but it's also much more likely because the ontology creators
are likely to understand this issue better.

    -- sandro

[1] http://www-106.ibm.com/developerworks/xml/library/x-foaf2.html
[2] http://lists.w3.org/Archives/Public/www-rdf-logic/2001Sep/0004.html
Received on Friday, 25 October 2002 11:11:13 GMT

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