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

Re: RDF/XML Syntax Specification (Revised) W3C Working Draft published

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 20 Dec 2001 18:30:29 +0000
Message-Id: <5.1.0.14.0.20011220180523.02127e60@0-mail-1.hpl.hp.com>
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 GMT

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