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

RE: Again: Anonymous Resources

From: Lee Jonas <lee.jonas@cakehouse.co.uk>
Date: Thu, 8 Mar 2001 12:55:46 -0000
Message-ID: <51ED29F31E20D411AAFD00105A4CD7A770B9@zingiber.cakehouse.co.uk>
To: "'Stefan Kokkelink'" <skokkeli@mathematik.uni-osnabrueck.de>, Aaron Swartz <aswartz@swartzfam.com>
Cc: RDF interest group <www-rdf-interest@w3.org>
This is my interpretation of anonymous resources, others will undoubtedly

IMHO *anonymous* means "without a name".  

I believe the intention of the RDF spec is that anonymous resources are
useful within the document fragment they are used, and are not referable
outside of that scope.  If that is the behaviour you want, you would have to
specify a "name" (i.e. URI) and it would no longer be anonymous.  Hence I
believe that the mere act of describing anonymous resources does _not_ give
them a name.  


Think of the RDF model forming a conceptual directed labelled graph.  Nodes
(Resources and Literals) are linked by labelled Arcs (Statements).
Regardless of whether the graph is stored directly as such in data
structures or not, it is useful to think of the nature of RDF model in this

Within this framework, an anonymous resource is simply a node without a name
that serves to link other resources with names in useful patterns - e.g. a
named Resource with a property, which refers to a qualified value (the
anonymous resource provides the necessary level of indirection to allow the
association of the actual value with its qualifiers).

Now, parsers reconstitute this conceptual directed labelled graph (RDF
model) from a serial text stream (e.g. RDF syntax, N3, etc) by emitting arcs
(Statements) in triple form.  This poses a problem for describing the arcs
to / from anonymous resources within the conceptual graph.  The description
of the above example as triples would be:

Subject         Predicate      Object
resource,       property,      anon_resource
anon_resource,  rdf:value,     value
anon_resource,  qual_prop1,    qual_resource1
anon_resource,  qual_prop2,    qual_resource2

How does a parser ensure the application knows that each of the four
statements above refer to the same anonymous resource?  The answer is to
generate a temporary name for it.  However, that is the sole purpose of the
temporary name and its scope should be restricted to the group of triples
outlined above.  Attempts to refer to it externally as
file://C:\Test\RDF\q.rdf#genid1 is incorrect as genid1 would be "out of

As an aside, XPointer poses an interesting question - should you be able to
refer to an anonymous resource as file://C:\Test\RDF\q.rdf#xpointer(1,1,1)
(or whatever the syntax is)?  This implies that the serialised form of the
description element describing the anonymous resource can be referenced.
However in pure RDF model terms, the description is not the same thing as
the nameless resource described.  It could be argued either way.  In a
purist sense you cannot reference anonymous resources this way, however
practical concerns may (just) warrant relaxing this stance and allowing it.
For example, to allow "3rd party" references to anonymous resources (where
you don't have control over the anonymous resource yourself).  I remain
unconvinced so far.

AFAIK, SiRPAC does not inform the application specifically that a resource
is anonymous - this is a problem.  David Megginson's RDF Filter extends the
notion of the triple to provide some additional information to the
application - from memory, a different method in the appilcation is called
depending on whether the resource is anonymous or not.


Lee Jonas

-----Original Message-----
From: Stefan Kokkelink [mailto:skokkeli@mathematik.uni-osnabrueck.de]
Sent: 08 March 2001 11:27
To: Aaron Swartz
Cc: RDF interest group
Subject: Again: Anonymous Resources

Hi Aaron,

moving this to RDF-IG, might me interesting for the
group ...


> >Umm. All resources have URIs -- that's their definition, I believe.


> > No: every resource *can* have a URI. In my opinion it would be a hard
> > restriction to RDF if one could only decribe resources that have a name
> > There are many things in the world that don't have names.


> Perhaps, but the act of describing them gives them a name. i.e. the first
> thing you described in file://C:\Test\RDF\q.rdf would usually be known as
> file://C:\Test\RDF\q.rdf#genid1 -- how does CARA deal with this? SiRPAC
> other programs I've used make up URIs like the one above for anonymous
> nodes.

Yes, but this raises some problems. For example try the
following code in SiRPAC [1]:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  <rdf:Description about="online:#genid1">
    <dc:type>no, only an anonymous resource</dc:type> 

I don't think this is a specific problem in SiRPAC. You always have
this problem when trying to calculate a URI for an anonymous 

(Note: If you use CARA [2] you should use the GraphViz visualization to
look at the RDF graph. The (default) triple representation is 

If we really want that anonymous resources are given URIs by parsers
we need to define a special URI scheme for these (no longer ;-)
'anonymous' resources and a well-defined algorithm how parsers
should calculate these URIs from the XML serialization. 

(But this is not easy: we would have to ensure that anonymous resources
different RDF files get *different* URIs!. Otherwise it becomes almost
impossible to join RDF graphs in a meaningful way. One advantage of 
anonymous resources is that they are not glued with other resources
when joining graphs!)

Currently, we don't have such a scheme defined
in the RDF specification nor an algorithm to calculate 
these URIs. 

Perhaps RDFCore should try to clarify things.

Personally I think it is a bad idea to require everything we want
to decribe with RDF to have a name. (Humans don't do this: we often
decribe things by the properties they have.) That would raise a lot
of problems ...


[1] http://www.w3.org/RDF/Implementations/SiRPAC/
[2] http://zoe.mathematik.Uni-Osnabrueck.DE/RDF/parser.html
Received on Thursday, 8 March 2001 07:56:11 UTC

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