- From: <henry.story@bblfish.net>
- Date: Thu, 21 May 2015 08:56:14 +0200
- To: David Booth <david@dbooth.org>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, ahogan@dcc.uchile.cl, semantic-web@w3.org
> On 21 May 2015, at 04:26, David Booth <david@dbooth.org> wrote: > > On 05/20/2015 07:08 PM, Gregg Kellogg wrote: >>> On May 20, 2015, at 2:55 PM, David Booth <david@dbooth.org> wrote: >>> [ . . . ] currently there >>> is no standard way to directly refer to a bnode from a separate >>> SPARQL operation. This is a known problem already with SPARQL, >>> which causes grief when doing followup queries. But if SPARQL >>> servers were enhanced to (optionally) enable subsequent queries or >>> update operations to refer directly to blank nodes by their >>> *original* labels, then both PATCH and followup queries would work >>> on SPARQL servers. (In the case of implicit bnodes generated by >>> Turtle/SPARQL [] or () notation the server would assign an original >>> label.) This seems like a good route to take, though it means >>> adding that feature to SPARQL. I'll send this to the SPARQL list >>> https://lists.w3.org/Archives/Public/public-sparql-dev/ to see what >>> others there think. >> >> This might only work on SPARQL servers that are capable of >> “remembering” original identifiers, and can rapidly get out of sync >> as the dataset changes. > > I don't think it would have to get out of sync any more than URIs get out of sync. The servers would have to remember them, just as they remember URIs. Yes, that is why it is not a good idea to patch through a generic sparql endpoint. Rather one should use the PATCH verb directly on a resource, and so reduce the size of the graph patched, and so the risk that it changed in the mean time. Then etags work correctly. It is worth checking LDP for this http://www.w3.org/TR/ldp/ As Roy Fielding points out in his thesis on REST, the web is designed for medium sized slow changing resources. > >> Alternatively, some SPARQL servers may use >> stable internal identifiers that could serve this purpose (still >> requiring normative normalization), but I suspect that there are some >> implementations that don’t guarantee such stable identifiers). > > Right, it would involve enhancing SPARQL servers. > > David Booth > > Social Web Architect http://bblfish.net/
Received on Thursday, 21 May 2015 06:56:45 UTC