W3C home > Mailing lists > Public > www-rdf-interest@w3.org > July 2001

Re: Comments on Jena Paper

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Tue, 31 Jul 2001 01:50:01 +0100
Message-ID: <3B6600B9.62280DD@hplb.hpl.hp.com>
To: Aaron Swartz <me@aaronsw.com>
CC: RDF-Interest <www-rdf-interest@w3.org>

Aaron Swartz wrote:
> In http://www-uk.hpl.hp.com/people/bwm/papers/20001221-paper/ you wrote:
> > Each such URI defines a new resource.  Thus there may be many
> > resources which represent the same tree.
> Do you have evidence to support this claim? I have heard it as
> an opinion several times but I was curious whether this was
> clarified in any document.

What exactly is the claim you think that is being made.  I think the
claim the paper is making is that the interpretation of M&S on which I
based my implementation had resources 'identified' rather than 'named'
by a URI.

The language I tend to use, which is not universal, is that identifiers
have the property that foo.id != bar.id => foo != bar.  

A somewhat fuller quote from the paper is:

Can a resource have more than one URI?  This is a question not just for RDF, but
for web and internet architecture as a whole, which, at the time of writing, has
not finally been resolved.  

The RDF Model and Syntax specification, however,  takes a position on this
question.  No provision is made in the RDF data model for a resource to have
multiple URI's. Provision is made for a resource to have a single URI. Other
URI's could be associated with a resource through some property, but the RDF
specifications define no such property.  The implication is clear, that as far
as RDF is concerned, resources have a distinguished URI.

Web principles [9], however, dictate that there can be no central authority to
allocate URI's to conceptual mappings.  There is no way to stop many individuals
independently assigning URIs to represent, say, the trees in a particular park. 
Each such URI defines a new resource.  Thus there may be many resources which
represent the same tree.  The RDF specifications do not define a mechanism for
stating the equivalence of resources, i.e. that multiple resources represent the
same conceptual mapping.  This is left to higher layers of the stack such such
as DAML-ONT [10].

Does that answer your question?

> > RDF statements are not resources.
> Anything that can be identified is a resource and RDF statements
> can clearly be identified, so I'm pretty sure statements are
> resources. The issue, I think, is that RDF provides no built-in
> way to identify and address these resources.

I'm not sure what criteria you would use to identify a statement.  I take
the view that a statement is uniquely identified by its subject, property
and object.  But not everyone would agree with that, reference the
long discussions about statings v statements.

It seems clear that the authors of M&S did distinguish between a statement
and its reification.  Whether they were right to do so is not for me to
say.  Had a statement been a resource, there would have been no need
to add the concept of a reified statement to the spec.

And it also gets us back into issues of what exactly a resource is.  Take
the tree in the park.  Is the tree the resource?  Is the resource a mapping
between a URI and the tree.  Is the resource the platonic ideal of the tree?
A statement is defined to be a triple whose first component is a resource.
Is the subject of a statement the tree itself or some other thingy which
represents the tree.  Shudder.  Lets not go there, again.

Please bear in mind the context in which this paper was written.
It was trying to set down in one place an interpretation of M&S that was
consistent and formed the basis of an implementation.  It does not claim
that it presents the one true interpretation, others are possible and indeed
I hoped that by writing one, others might also be written.  Also, it
it was not an attempt to specify what M&S should have said - it was
merely a poor implementer recording how he was interpreting the spec and
why he was interpreting it that way.

Received on Monday, 30 July 2001 20:52:45 GMT

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