- From: McBride, Brian <bwm@hplb.hpl.hp.com>
- Date: Wed, 4 Oct 2000 10:13:56 +0100
- To: "'Tim Serong'" <tims@ixla.com.au>
- Cc: "RDF Interest (E-mail)" <www-rdf-interest@w3.org>
Intererting question, Tim. You may get multiple views on this one. My thoughts are that the second rdf:description element does not specify what resource it describes. Standard RDF processors will therefore not be able to figure out its about the element in which it is embedded. However, you have specific application knowledge that does allow you identify the resource it describes. So you could write your own processor, that would use that knowledge and be aware of the identity of resource being described. Whilst you could do that, it doesn't feel like a very clean solution. What advantage do you get out of using RDF in this way? Could XSLT help here at all? Would it be possible to start with a file in the format you prefer and have the fragment ID's inserted automatically by an application or XSLT transform. Then you would have more useful RDF, could use standard RDF tools and your data could be processed by other systems. Brian McBride HPLabs > The second <rdf:Description> refers to an anonymous resource. Could I > assume that this anonymous resource is the <second-element> > element? Could > I assume that this anonymous resource is the file itself? Or > can I know > nothing at all about the resource other than what is defined > inside the > <rdf:Description> block? > > What I'm actually trying to do is define a simple hierarchy, > and I want to > be able to describe arbitrary pieces of the hierarchy using > RDF, without > having to keep track of fragment IDs...
Received on Wednesday, 4 October 2000 05:14:38 UTC