- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Thu, 20 Dec 2001 18:30:29 +0000
- To: Mike Moran <mmoran@netphysic.com>
- Cc: Dave Beckett <dave.beckett@bristol.ac.uk>, www-rdf-interest@w3.org
Hi Mike, Tarod did capture what I meant rather better than I expressed it, thank you Tarod. And strictly speaking Peter is correct. Let me take a little more time than I was able to this morning and try to offer you two possible solutions to your problem. As I understand it, the key issue is that you have resources with common properties and you want to ensure that you can update a common property just once and all the resources will be 'updated'. The first option one is a variation of Dave Beckett's proposal, which is to represent the common properties in the RDF graph itself, though I'm using a slightly different style to make sure I keep clear of Peter's objection. Lets define a property, say moran:also which is defined to mean that any property of its object is also a property of its subject. So we could do the following, in a way very similar to what Dave proposed: <rdf:Description rdf:ID="commonProps"> <eg:prop>example prop</eg:prop> ... more shared properties here </rdf:Description> <rdf:Description rdf:about="http://example.org/tom"> <moran:also rdf:resource="#common"/> .. more properties here ... </rdf:Description> <rdf:Description rdf:about="http://example/jane"> <moran:also rdf:resource="#common"/> .. more properties here ... </rdf:Description> Now an application can 'know' that to determine the properties of a resource, as well as listing all the direct properties, it has to list all those linked through the moran:also property as well. Some implementations of RDF API's, e.g. those based on prolog or with some inferencing engine such as cwm or euler, could do this very easily by loading a rule like: triple(?s, ?p, ?o) :- triple(?s, moran:also, ?x), triple(?x, ?p, ?o). which is just prolog for our definition of the moran:also property. If this data is only going to be processed by applications you write, this is a possible way to go. You can write the code which will check for the moran:also property and process it correctly, or you can use an rdf implementation which supports rules. However, if you send this data to me, I don't know about and don't implement the special processing of the moran:also property, then information has been lost. An alternative solution would be to use XSLT, as you suggested at the beginning of this thread. Lets imagine we write something like: <moran:macro ID="commonProps"> <eg:prop>example prop</eg:prop> ... more shared properties here </moran:macro> <rdf:Description rdf:about="http://example.org/tom"> <moran:callMacro macro="commonProps"/> .. more properties here ... </rdf:Description> <rdf:Description rdf:about="http://example/jane"> <moran:callMacro macro="commonProps"/> .. more properties here ... </rdf:Description> we run this through an XSLT processor with some appropriate transform that implements the macro expansion and outputs straight RDF: <rdf:Description rdf:about="http://example.org/tom"> <eg:prop>example prop</eg:prop> ... more shared properties here .. more properties here ... </rdf:Description> <rdf:Description rdf:about="http://example/jane"> <eg:prop>example prop</eg:prop> ... more shared properties here .. more properties here ... </rdf:Description> If you do it this way, then any bog standard RDF processor will correctly know that all the common properties apply to each of the resources. No special processing at their end required; you've done it all up front in the xslt processor. I suspect, this latter approach might be best for you. Does this help? Brian
Received on Thursday, 20 December 2001 13:30:57 UTC