W3C home > Mailing lists > Public > public-rdf-wg@w3.org > February 2013

Re: Using bnode identifiers for predicates, graph names

From: William Waites <wwaites@tardis.ed.ac.uk>
Date: Wed, 06 Feb 2013 10:06:36 +0000 (GMT)
Message-Id: <20130206.100636.393627653.wwaites@tardis.ed.ac.uk>
To: msporny@digitalbazaar.com
Cc: public-rdf-wg@w3.org
I'm not sure what a "blank graph" is either, but it is natural to use
blank nodes when we want to talk about the relationship between graphs
that may not have names (or we don't know or care what they are). This
happens in practice with FuXi,

    { ?a foo ?b } => { ?a bar baz }

could be written in a trigesque way as

    { _:g1 log:implies _:g2 }
    _:g1 { ?a foo ?b }
    _:g2 { ?a bar baz }

I know there's other stuff in there that is outwith the "normal" RDF
like the "for all" variables, ignoring those for now. Using blank
nodes like this seems obvious to me (as it probably did to the rdflib
developers early on where if you don't give a graph a name when you
create it, it gets a bnode, and to Chimezie when he made FuXi work
this way).

I could imagine a URI scheme that would do the same thing without
using blank nodes, but why go to that trouble? If we have to go to
that trouble, why bother with blank nodes at all when we can just
generate (spurious) skolem URIs in all cases?

All we need to do is say that the fourth column is drawn from (IRI or
Blank) and make sure we know the scope of blank nodes in documents
(document scope for simplicity [1]) and nothing else needs to change.

It would be nice if the spec were upwardly compatible enough to
sanction this kind of use.


[1] I would prefer a nested structure that works like lexical scoping,
    but I suspect it is unworkable because I think (but am not sure)
    there are perfectly reasonable bags of graphs that refer amongst
    themselves in ways that can't be written down in a lexically
    scoped way and certainly some (most) serialisations have no
    obvious notion of lexical scope.

Received on Wednesday, 6 February 2013 10:06:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:10 UTC