Karen, Tom, all,
On Friday, July 03, 2015 7:35 PM, Tom Johnson wrote:
> At first glance, Holger's "left side" diagram looks okay to me. I'd quibble about
> the terminology---I think what he's really talking about is the SPARQL Semantics
> (as opposed to a SPARQL Engine, which seems like an implementation detail
> which can vary) interfacing with a Dataset---but without digging too deep, this
> seems like a good approach. It avoids the need for a new query semantics
> except with respect to the Shapes Graph, but allows SHACL functions to sit in a
> layer above.
I too think that it's OK to make SHACL support different implementation levels where some implementations are powerful than others.
> I think the concerns I would have are as follows:
>
> - that the SHACL spec would be overly prescriptive, saying that the graph(s) to
> be validated need actually live behind a SPARQL endpoint.
Yes, this is my main concern, too. My requirements are essentially:
- Graph description as an RDF graph
- Streaming graph validation (validating a graph as it comes over the wire)
> - that the SHACL layer itself will defer too much to SPARQL, causing it lack
> appropriate semantics for expressing constraints rather than queries.
Excellently put!
> The first concern is manifest in the "right side" diagram, but not in the left. The
> second applies equally to both, but is not inherent in either.
>
> My feeling is that we should give our support to Holger's argument, and press
> the second point whatever the outcome.
+1
/Lars
|