Re: Indicating Skolem Nodes (was Re: AW: {Disarmed} Re: blank nodes (once again))

Steve, Pat, note that I'm not suggesting the Skolem names *have* to be
dereferenceable, just that the Skolemizer should have the choice to make
them so.   That is, they could generate an http URL containing the magic
string, or generate a tag: URI containing the magic string; it's up to
them.  (Unfortunately, the urn:uuid: grammar doesn't allow for any extra
text.  It's hard to imagine what would break if you included some,
though.  It also hard to imagine harm from using the unregistered uuid:
scheme with extra text.)

My current use case for Skolemizing is a service which watches an RDF
graph someone publishes and in turn publishes a stream of deltas as that
graph changes.  I'd like the provider to be able to use arbitrary RDF,
including blank nodes, because I want them to be able to author by hand,
including using lists.  But RDF deltas are much, much simpler to apply
without blank nodes.   So I want the change service to Skolemize, if
necessary, before sending out the deltas.   And, of course, I want it to
all to be good linked data, so RDF browsers can walk through it, etc.
The rdfwatch service is perfectly happy to provide web service behind
the URLs it mints, and when you ask about a Skolem constant, it can
serve up the current contents of the g-box for which that constant
minted.

Note that I'm really scoping blank nodes to g-boxes here, not g-snaps,
saying that as the g-box changes from one g-snap to another, we consider
certain blank nodes to remain unchanged.  For example:

At t1: { _:x foaf:name "Sandro"; foaf:mbox "mailt:sandro@w3.org"; plus
many foaf:knows links }

At t2: { _:x foaf:name "Sandro"; foaf:mbox "mailt:sandro@hawke.org";
plus the same foaf:knows links }

I'd like the delta here to be small -- to consider one triple as having
changed, instead of the many triples that use that blank node.

Also, I think dereferenceability is more important for this use case
than indicating for downstream consumers that this used to be a blank
node.  In fact, until this discussion, I was perfectly to content to
Skolemize without indicating this formally.  Now I'm seeing that it
would be nice to indicate it.

   -- Sandro

On Sat, 2011-03-26 at 09:31 +0000, Steve Harris wrote:
> On 2011-03-26, at 09:09, Steve Harris wrote:
> > I get where you're coming from, but I suspect that not being able to dereference is a good thing in some cases.
> > 
> > If it's a dereferencable URI then you win a load of moral(?) obligations to make them stable and persistent, which is some of the things you're might be trying to get away from when using bNodes.
> > 
> > I like the UUID prefix, gets round a lot of practical issues.
> > 
> > <bnode:3dff1ee0-783a-42f4-8d67-4381dd4dd83e:123456> can't be resolved, but you can use it in, for e.g.
> > 
> > http://sparql.example.com/data?graph=bnode%3A3dff1ee0-783a-42f4-8d67-4381dd4dd83e%3A123456
> > 
> > Ignoring for a moment the raft of exciting scope issues that raises :)
> 
> A less crazy example is maybe:
> 
> http://sparql.example.com/?query=DESCRIBE%20%3Cbnode%3A3dff1ee0-783a-42f4-8d67-4381dd4dd83e%3A123456%3E
> 
> It's an exercise for the user to map UUIDs to endpoints, but that feels more practical than a global registry of every skolemised bNode.
> 
> - Steve
>

Received on Saturday, 26 March 2011 13:31:30 UTC