RE: Meaning of URIRefs

> -----Original Message-----
> From: www-rdf-interest-request@w3.org [mailto:www-rdf-interest-
> request@w3.org] On Behalf Of Sandro Hawke
> Sent: Friday, October 25, 2002 10:11 AM
> To: Peter F. Patel-Schneider
> Cc: www-rdf-interest@w3.org
> Subject: Re: Meaning of URIRefs
> 
> 
> 
> 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

Even if we are not _required_ to commit to someone else's statements
about a resource by using their name for it, it seems to me we
effectively will if the statements are made by an authoritative source
that many people trust. For example, if we use a trusted web
encyclopedia's URI for a resource to refer to that resource and someone
merges our statements with statements from their other trusted sources
(including the encyclopedia), we will have ended up agreeing in a way to
all authoritative statements about that resource (i.e. by using a common
name for something we buy into all aspects of its common meaning). In
fact it may be very difficult to not do so. Inverse functional
properties, cardinality restrictions, etc. may force a well-connected
reasoner to infer that the URI we use for something refers to the exact
same object that the authoritative source calls by a different name (and
so our URI and the authoritative URI can be used interchangeably). 

I wonder if it might be handy to have a way of scoping the consequences
of our use of a name. Instead of an inverse functional property being
used to infer the identity of objects, perhaps it could sometimes just
be used to infer equality under a set of properties. For example, say we
use a bNode to refer to a certain president and a property such as
http://www.us-presidents.org/justTheFacts#number (which is specified
somehow so that any two resources with the same value of this property
have the same values for all other properties that begin
http://www.us-presidents.org/justTheFacts#). Our bNode wouldn't inherit
the properties/values from
http://www.us-presidents.org/andNowSomeOpinions or other
namespaces/documents that are attributed to other URIs with the same
value of #number. Make any sense?

--Geoff Chappell

Received on Sunday, 27 October 2002 17:10:28 UTC