LDPath as influence to LDPatch? Well, I'm still awaiting what it contributes for what RDF Patch already does...
---------- Forwarded message ---------- From: Alexandre Bertails <[email protected]> Date: Jul 24, 2014 8:30 PM Subject: SPARQL subset as a PATCH format for LDP To: "[email protected]" <[email protected]> Cc: > All, > > I have been thinking a lot about the SPARQL subset idea and I would > like to share some thoughts. As you could have expected from the last > call, I am not in favor of it, so I have taken the time to document my > issues with the approach. > > First, let me remind you the scope of LD Patch. It is PATCH format for > partial updates of LDP-RS. So it's only about RDF graphs. It is not > intended for updating quad stores, nor named graphs. Also, it is not > meant to be a high-level language but rather an assembly one. For that > reason, the editors challenged themselves for not adding higher-level > features. > > Skolemization is not used. The assumption is that bnodes form tree > structures. The idea is that most of those trees (and the bnodes in > them) can be distinguished by filtering on sub-components of those > trees. I recommend [1] for a recent and thorough analysis confirming > those assumptions. > > That is the very reason behind the LD Path (no 'c') algebra, which > shares some similarities with XPath. They are applied left-to-right, > and recursively for path constraints. The semantics formally specifies > the order in which those operations must be evaluated. So LDP > application writers can rely on that semantics for runtime > characteristics, for example by restraining the node sets as early as > possible in the path, by probably starting from the leaves of the > tree, and then moving up in the tree, until reaching the bnode. > > So, SPARQL. Yes, you can consider a subset with similar expressive > power. People seem to think that defining the concrete syntax would be > enough, and that it would be as easy if not easier than LD Patch. I > disagree. First, the two concrete syntaxes would share a lot of the > production rules, basically all the ones borrowed from Turtle. The > additional ones are no issue in both cases. > > Then, I have heard people saying that we wouldn't need to write down > the operational semantics, because we could say it's the same than > SPARQL Update, but for that subset of the syntax. I disagree. Because > as a developer and as a user, I would have to be sure I understand > well the SPARQL semantics to either implement LD Patch (if I don't > want to depend on an existing SPARQL implementation), or to use it. So > I'd argue that the semantics _has_ to be written. And I'd have to > reject valid SPARQL Update queries which are not in the subset. > > Another issue is that we will still need Basic Graph Patterns, the (S > P O .)-s in the WHERE clause, which rely on intermediate ResultSet-s > for their semantics. > > For example: > > Bind ?event <http://conferences.ted.com/TED2009/> > /-schema:url[/schema:startDate="2009-02-04"]/schema:location[/schema:name="Long > > Beach, California"][/schema:geo[/schema:latitude][/schema:longitude]] > > would be equivalent to something like that: > > WHERE { > ?event schema:url <http://conferences.ted.com/TED2009/> . > ?event schema:startDate "2009-02-04" . > ?event schema:location ?loc . > ?loc schema:name "Long Beach, California" . > ?loc schema:geo ?geo . > ?geo schema:latitude [] . > ?geo schema:longitude [] . > } > > If we want the same performance characterics (mainly, predictability), > we would have to refine the SPARQL semantics so that the order of the > clauses matters (ie. no need to depend on a query optimiser). And we > would need to do some static analysis on the query to make sure that > ResultSet-s are not needed. In any case, it goes beyond the idea of > using subset of the syntax + a pointer to SPARQL Update semantics. > > Another problem is the support for rdf:list. I have just finished > writing down the semantics for UpdateList and based on that > experience, I know this is something I want to rely on as a user, > because it is so easy to get it wrong, so I want native support for > it. And I don't think it is possible to do something equivalent in > SPARQL Update. That is a huge drawback as list manipulation (eg. in > JSON-LD, or Turtle) is an everyday task. > > So to summarize my issues with the approach: > > 1. semantics is not that easy to define > 2. performance characteristics > 3. no native support for rdf:list > 4. needs to explain to the user how it differs from existing SPARQL > Update > > SPARQL Update is good at doing what it was designed for, but there is > little interest in being syntax compatible with it. > > Regards, > > Alexandre > > [1] http://www.websemanticsjournal.org/index.php/ps/article/view/365 >
