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

Re: Again: Anonymous Resources

From: Stefan Kokkelink <skokkeli@mathematik.uni-osnabrueck.de>
Date: Thu, 08 Mar 2001 15:15:56 +0100
Message-ID: <3AA7941C.867F064D@mathematik.uni-osnabrueck.de>
To: Lee Jonas <lee.jonas@cakehouse.co.uk>
CC: Aaron Swartz <aswartz@swartzfam.com>, RDF interest group <www-rdf-interest@w3.org>
Lee Jonas,

I completely agree with your interpretation of
anonymous resources! But this has some consequences
for (valid) manipulations of RDF models, see [1]
for an example. And there are other points that
need clarification. Let's do some odd things ;-) :

<rdfs:Property>
  <rdfs:subPropertyOf>
    <rdfs:Property>
       <rdfs:subPropertyOf>
         <rdfs:Property/>
       </rdfs:subPropertyOf>
    </rdfs:Property>
  </rdfs:subPropertyOf>
</rdfs:Property>

According to RDF Schema this leads to the conclusion
that the first Property is also subPropertyOf the
third one. But: you can't express this fact in the
XML serialization (although you are the owner of
the data).

I agree with Brian (great paper!): 'It is unfortunate 
that the XML serialization defined for RDF does not 
permit the representation of all possible
graphs containing anonymous resources.' (Section 2.2) 

I think this is a bug in the RDF serialization. Perhaps
the serialization should provide an 'rdf:anonymous_ID'
attribute in addition to rdf:ID. rdf:ID specifies
an URI, rdf:anonymous_ID a local identifier that is 
allowed to be changed (more precisely: mapped one
to one) by an RDF application (e.g. 
parser) processing the data. And this identifier should
not be interpreted as a URI, it's private data!

Greetings,
Stefan 

[1]
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0161.html

Lee Jonas wrote:
> 
> This is my interpretation of anonymous resources, others will undoubtedly
> disagree.
> 
> 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.
> 
> Justification:
> 
> 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
> way.
> 
> 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
> scope".
> 
> 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.
> 
> Regards
> 
> 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 ...
> 
> Aaron:
> 
> > >Umm. All resources have URIs -- that's their definition, I believe.
> 
> Stefan:
> 
> > > 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.
> 
> Aaron:
> 
> > 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
> and
> > 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#"
>          xmlns:dc="http://purl.org/dc/elements/1.1/">
>   <rdf:Description>
>     <dc:type>animal</dc:type>
>   </rdf:Description>
>   <rdf:Description about="online:#genid1">
>     <dc:type>no, only an anonymous resource</dc:type>
>   </rdf:Description>
> </rdf:RDF>
> 
> 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
> resource.
> 
> (Note: If you use CARA [2] you should use the GraphViz visualization to
> look at the RDF graph. The (default) triple representation is
> broken!)
> 
> 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
> from
> 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 ...
> 
> Greetings,
> Stefan
> 
> [1] http://www.w3.org/RDF/Implementations/SiRPAC/
> [2] http://zoe.mathematik.Uni-Osnabrueck.DE/RDF/parser.html
Received on Thursday, 8 March 2001 09:16:25 GMT

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