- From: Lee Jonas <lee.jonas@cakehouse.co.uk>
- Date: Thu, 8 Mar 2001 12:55:46 -0000
- 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 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 07:56:11 UTC