- From: Michael Brian Orr <mike@michael-brian-orr.net>
- Date: Fri, 21 May 2004 00:09:31 -0700
- To: "'Paul Gearon'" <pag@tucanatech.com>, "'Graham Klyne'" <GK@ninebynine.org>, "'Richard Lennox'" <listserve@richardlennox.net>
- Cc: www-rdf-interest@w3.org
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org] On Behalf Of Paul Gearon
>
> Michael Brian Orr wrote:
> <snip/>
>
> > I've used the "composed relationship that indirects via
> > an intervening node" approach with excellent results in
> > building a specialized class library over an RDF
> > library...
>
> The advantage of "code" is that your data structures can be
> quite flexible, as demonstrated. However, representation
> on disk becomes difficult...
>
----( SNIP )------------
>
> Anyway, my point is that this solution only seems to be
> useful for "in-memory" code, rather than the general case.
The solution I described doesn't rely on any state outside the
graph; in my case I persist completely as NTriples.
What I do - and what I think Graham Klyne was describing,
though I haven't followed his citations yet - is to bulk up
certain node relationships by representing them not as
Subject predicate Object .
but as
Subject predicate' Intermediate .
Intermediate predicate' Object .
The upside is that you can refer to this edge-analogue
(instance) by ID, and you can attach additional edges to it.
The downside is that you add some complexity to the graph (as
do all the solutions that have been discussed on this thread).
It doesn't use anything non-RDF; it does use a simple but not
quite trivial graph idiom. I edit my graph with Protege all
the time; it's just that the edge-IntermediateNode-edge
construct is visible and must at times be manipulated
explicitly.
This pattern works well in the class library case because
it's so easy to do the interpretation of the idiomatic
construct in the API, by exposing instances simultaneously as
IGraphEdge and IGraphNode (or whatever).
Regards,
Mike
Received on Friday, 21 May 2004 03:09:45 UTC