- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 22 Sep 2014 19:00:13 -0400
- To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, "henry.story@bblfish.net" <henry.story@bblfish.net>
- CC: "public-ldp-comments@w3.org" <public-ldp-comments@w3.org>, public-ldp <public-ldp@w3.org>, Semantic Web <semantic-web@w3.org>
- Message-ID: <5420A9FD.8010101@w3.org>
On 09/22/2014 06:40 PM, Pierre-Antoine Champin wrote:
> Hi Henry,
>
> On Mon, Sep 22, 2014 at 4:06 PM, henry.story@bblfish.net
> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
> <mailto:henry.story@bblfish.net>> wrote:
>
>
> On 22 Sep 2014, at 09:47, Pierre-Antoine Champin
> <pierre-antoine.champin@liris.cnrs.fr
> <mailto:pierre-antoine.champin@liris.cnrs.fr>> wrote:
>
>> Hi Henry,
>>
>> On Sat, Sep 20, 2014 at 12:57 PM, henry.story@bblfish.net
>> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
>> <mailto:henry.story@bblfish.net>> wrote:
>>
>> Turtle Patch [1] makes it obvious that being able to name the
>> bnode
>> URIs in a patch request makes patching exceedingly easy to
>> implement as well as very easy to create patches. All that is
>> needed for
>> a client implementation is to know what triples it needs to
>> remove:
>> there is no need to find a pattern that would identify those
>> triples
>> among all others. The main problem with Turtle Patch is that it
>> requires one to then make a new HTTP request with genid blank
>> nodes,
>> to get the patchable format of the resource, or to always
>> request them
>> and then sadly turn all bnodes de facto into URIs.
>>
>>
>> Agreed, also I'm not sure I'm coming to the same conclusions as
>> you do below...
>>
>>
>> Where there is usually a valid concern about naming bnodes - the
>> point of bnodes is that they the server publishing them
>> should not have to
>> maintain references to them add eternam
>>
>>
>> Who says I should maintain them /ad eternam/??
>> In my understanding, skolemization does not require the genid
>> URIs to be the same across all successives states (versions) of a
>> given resource. The only have to persist as long as the resource
>> does not change, so that one can safely patch it?
>
> I find genids pretty hackish part of the rdf1.1 spec frankly.
> Genids are recognised apparently by analysing the schema
> of the URI, which is pretty much against web architecture.
> http://www.w3.org/TR/rdf11-concepts/#section-skolemization
>
> So now every RDF linked data client would need to look at each URI
> to see if it contains a ".wellknown/genid" string to know if it
> should follow it
> or not. That's pretty un linked-data-ish. Frankly I am quite
> surprised it made its way through to the spec. The people
> supporting it
> must have made a lot of noise.
>
>
> Not everything is about your particular use case, Henry ;-)
>
> RDF does not equate linked data. It does not mandate URIs to be
> derefenceable. In that regard, genid URIs are no special case, so they
> do not need the special treatment that you suggest above. If you try
> to dereference them, you will get a 404, that's all. It's not ideal in
> a Linked Data perspective (though not lethal either), but it is
> perfectly acceptable from the point of view of RDF.
>
You don't even have to get a 404. The Skolemizing server can answer
the URLs it mints, and if it's doing linked data it should.
The point of genid is that systems Skolemize all the time, and this way
everyone else can at least see what's going on and avoid the
out-of-control proliferation of generated IRIs we were seeing. It's
neither a license nor a requirement to violate any good practices.
-- Sandro
>
>>
>> - in the case of a PATCH
>> the action is directly on the graph in question, and so there
>> is in this
>> case no problem of cross reference with other resources.
>>
>>
>> Given this I think one should be able to have a simpler
>> version of Turtle
>> patch without the need for genids, that keep the bnodes local
>> to the
>> resource and that also don't require the extra request to be
>> made to the
>> server ( the one that is required to GET the graphs with the
>> genids using
>> the "Prefer: return=representation blank-nodes=use-genid"
>> header ).
>>
>> It could simply be decided that a resource that advertises
>> the given
>> Patch Format - lets call it N3-Patch - understands there to
>> be an automatic
>> mapping from the order of bnodes in their representation to a set
>> of explicit bnodes such as _:bn1 to _:bnN . One could then
>> have something like
>> the following document at /asterix
>>
>>
>> Well, in my opinion, we are back to problem #1:
>> you ask the server to maintain an *order*, while the underlying
>> data model (RDF abstract syntax) has no such notion.
>> So you still put an extra burden on the server.
>
> No the ordering can be agreed to as part of the protocol. The
> client or the server would only need to
> work on the ordering if the patch had blank nodes. If it did then
> the nodes could be ordered. The server
> could cache the order.
>
>
> In my view, it *has* to cache the order (see argument above). I'm not
> saying this is impossible to achieve (I agree with your arguments
> below as to how to do it), I'm only saying that it is not a standard
> functionality of triple stores, so you have to change them (even if
> slightly). And I do not consider that as something that should become
> a standard feature, since this notion of order is not part of the RDF
> model.
>
> best
>
> The nice thing is that there is no need for an extra GET to
> skolemise the nodes,
> and on the internet it is http connections that are the slowest of
> all.
>>
>> Granted, it is not a huge deal, and is probably a good way to
>> keep the extra information that allows you to skolemize bnodes,
>> but this is still something that you get out of the box for
>> standard triple stores.
>
> I think you could calculate it from a graph without needing to
> change your triple store.
> One would just need to start from something like
> http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf
> where the alogrithm could be followed by just using triples.
>
>
> And in our case we are just interested in an ordering of blank nodes.
>
> There are more recent works on this too.
>
>>
>> pa
>>
>>
>> GET /asterix HTTP/1.1
>>
>>
>> HTTP/1.1 200 Ok
>> E-Tag: "slab v2"
>>
>> [] foaf:name "Asterix".
>> foaf:knows [ foaf:name "Julius Caesar";
>> foaf:homePage <http://palace.rome/> ].
>>
>> [] foaf:name "Obelix" .
>>
>> And patch it with the following PATCH Request
>>
>> PATCH /asterix HTTP/1.1
>> Content-Type: text/n3
>> If-Match: "slab v2"
>>
>> @prefix foaf: <http://xmlns.com/foaf/0.1/>
>>
>> { _:bnx1 foaf:knows _:bnx2 } patch:replaceWith { _:bnx1
>> foaf:knows _:bnx3 }
>>
>> Which would result in a following request
>>
>> GET /asterix HTTP/1.1
>> Accept: text/turtle
>>
>> HTTP/1.1 200 Ok
>> Content-Type: text/turtle
>>
>> [] foaf:name "Asterix".
>> foaf:knows [ foaf:name "Obelix" ].
>>
>> [] foaf:name "Julius Caesar";
>> foaf:homePage <http://palace.rome/>
>>
>>
>> Henry
>>
>>
>> [1] http://www.w3.org/2001/sw/wiki/TurtlePatch
>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>
Received on Monday, 22 September 2014 23:00:19 UTC