- 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