Re: reconsidering: blank nodes as named-graph labels

LDP has not committed to use a TriG-ish format.  It's one possibility 
and this particular variant has some issues, raised before, that this 
proposal ignores.

Why not use a restricted SPARQL update?

DELETE DATA { .... }
INSERT DATA { .... }

A big practical advantage is that a mix of DELETE/INSERT can be done and 
has the obvious meaning of applying in order given.

The TriG design requires that all changes are known before the TriG is 
written (client) or processed (server).  At scale, this c an be a large 
burden.

A (DELETE|INSERT)* style can be created by recording changes as they 
happen - so it scales both at the client and at the server.  The 
declarative nature of the TriG design is a practical disadvantage here.

Restricted SPARQL update opens to more of SPARQL if the LDP-WG or an 
LDP-engine so chooses.  Useful ones being CLEAR and the shorthand form 
DELETE WHERE { }.

On 11/05/13 04:08, Pat Hayes wrote:
> I entirely agree.  I also note that SPARQL engines can surely just
> treat the bnodeIDs as if they were skolemized IRIs, and nothing would
> break. All that matters in either case is the ability to check
> identity of identifiers.

Won't such systems would have to skolemize all bNodes - a bnode can be 
be used in the graph data as well as be used for a graph label.

And have to do it all the time because an incoming document could have 
the manifest last (seems really quite sensible after all the data is 
known about):

-----------------------------------------------------
@prefix ldp: <http://www.w3.org/ns/ndp#> .

<#i1> {  ... triples to add ... uses _:b0 ... }

_:b0 { ... triples to delete ... }

<#i1> {  ... more triples to add ... }

_:b0 { ... more triples to delete ... but before any inserts ... }

{
[] a ldp:Patch
    ldp:delete _:b0;
    ldp:insert <#i1>.
}
-----------------------------------------------------

so it does not know which are deletes and which are inserts until the 
end nor whether it skolemization is necessary so it has to do it all the 
time.

If there are additional syntactic restrictions on the TriG (e.g. exactly 
two graph blocks, manifest first) then it's not helpful to use TriG.

>> At the last LDP F2F we talked about it and the group was
>> overwhelmingly in favor of a dataset-based design.  They're very
>> happy with the idea of patches that look something like this:
>>
>> prefix ldp: <http://www.w3.org/ns/ndp#>
>> # ... application data prefixes ...
>>
>> prefix ldp: <http://www.w3.org/ns/ndp#>
>> # ... application data prefixes ...
>>
>> [] a ldp:Patch
>>     ldp:delete <#d1>;
>>     ldp:insert <#i1>.

This is not valid TriG.

>>
>> <#d1> { ... triples to delete ... }
>> <#i1> {  ... triples to add ... }
>>
>> So I've been working out the details for how to do that, and mostly
>> I think it'll work great.


>> Thinking about why we decided against blank nodes, the main thing I
>> believe was the SPARQL spec says that in datasets the labels are
>> IRIs.   I think it's not a huge problem to live with two different
>> kinds of datasets like this.
 >> It would mean some compliant SPARQL
>> systems can only handle SPARQL 1.1 datasets, not full RDF
>> Datasets.    People who wanted to use blank node graph names in
>> SPARQL 1.1 would have to either lobby to get that extension put into
>> their favorite SPARQL system (some have it already),

Which ones?

>> or they'd have
>> to make do with Skolemization.   That's a bit painful, but the
>> alternative is to require every client who wants this functionality
>> (even non-SPARQL LDP ones) to Skolemize or psuedo-Skolemize with a
>> UUID; that seems even more painful.

As has been pointed out, some systems do specific optimisations knowing 
that a position can only be a URI (Jena does not; 4Store & 5Store were 
mentioned).  You seen to have skipped that bit and other concerns.

As I recall it, not allowing bNodes also means we don't have to fact 
impossible (future) formal semantics and its that area that means the 
safer, restricted choice.

	Andy

Received on Saturday, 11 May 2013 15:52:12 UTC