W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2004

Recursive graphs?

From: Benja Fallenstein <b.fallenstein@gmx.de>
Date: Thu, 12 Feb 2004 21:43:26 +0200
Message-ID: <402BD75E.4070506@gmx.de>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Cc: Bob MacGregor <macgregor@ISI.EDU>, Dan Brickley <danbri@w3.org>, www-rdf-interest@w3.org

Hash: SHA1


Jeremy Carroll wrote:
| One could have a convention where the first graph is always asserted,
| and may simply be a single statement that the second graph is not
| asserted ...

Please don't shoot me for throwing another idea into this discussion;
perhaps it's un-thought-out, but my intent here is to understand the
options and your thinking on them better.

You have already established that you're willing to change the abstract
syntax so that the graphs in a 'graphset' can share anonymous nodes with
each other.

How about instead changing it so that a graph can contain other graphs?
Or, to be precise, in addition to triples, a graph can contain the
following kind of pair:

~    (<node>, <set of triples and pairs>)

which means that <node> is a graph containing exactly <set of triples
and pairs>. Let's call these "child graphs." The set of blank nodes is
shared between a graph and its child graphs.

The problem of assertion would be solved by only considering child
graphs as asserted for which the surrounding graph contains an
"asserted" triple.

This would also solve the syndication problem, in that you could always
incorporate a graph and its child graphs into a larger graph.

Also, it would mean that an application/trix+xml or whatever file would
be interpretable as a graph, and thus be on a similar semantic level as
existing RDF files, rather than as a set of graphs.

On the downside, it's ugly. But remember, I've mostly raised it to
understand the arguments here better. So, what's the semantic problems
with this proposal?

- - Benja
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

Received on Thursday, 12 February 2004 14:43:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:49 UTC