Re: shapes-ISSUE-74 (SPARQL endpoint support): Should SHACL support vallidating RDF graphs accessible via unmodified SPARQL endpoints [SHACL Spec]

Holger/Peter,

I think Peter's example graph is reasonable and graphs like it occur
frequently in the real world. Developers often use blank nodes rather
than create IRIs because it makes the RDF more compact looking, not
because they are making an existential statement (which is what blank
nodes are for). In many cases, you can avoid blank nodes and use hash
IRIs instead to indicate substructure. However, if SHACL is going to
be relevant to the real world, it will have to deal with blank nodes.

That being said, if the problem is how to interpret the constraint
violation results for even a single SPARQL query, then I don't see
SHACL as being any more problematic in this respect than SPARQL which
lets you return blank nodes in a result. If this becomes a problem in
practice, then we could look at improving the error reporting in
SHACL, e.g. by providing additional context for the blank nodes.

-- Arthur

On Thu, Jul 16, 2015 at 7:10 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> On 7/17/2015 4:01, Arthur Ryman wrote:
>>
>> Peter,
>>
>> I assume the point of this example is that it contains a blank node
>> which makes it problematic to have two separate SPARQL calls.
>>
>> It seems to me that whatever mechanism is used to associate a shape
>> with a node would provide a starting point from which one could
>> navigate to all subsequent nodes using suitable property paths. This
>> would provide enough context for subsequent SPARQL calls. However,
>> this certainly complicates the implementation.
>
>
> The issue remains that even if we put everything into a single query, there
> is no way to make sense of the results (i.e. pointers to specific blank
> nodes) because SPARQL endpoints have no round-trippable bnode identifiers.
> Given this and the aforementioned limitations of endpoints, my response to
> this ticket is that the best thing we can achieve is to define an
> Endpoint-safe subset of SHACL that excludes bnodes, user-defined functions,
> recursion and mixing SPARQL with other languages. I am finding it
> unfortunate that this topic is influencing the discussion about ?shapesGraph
> access, which is unproblematic in Dataset-based architectures. (I still have
> a task to open a separate wiki page on that).
>
> Holger
>
>
>>
>> -- Arthur
>>
>> On Sat, Jul 11, 2015 at 11:58 PM, RDF Data Shapes Working Group Issue
>> Tracker <sysbot+tracker@w3.org> wrote:
>>>
>>> shapes-ISSUE-74 (SPARQL endpoint support): Should SHACL support
>>> vallidating RDF graphs accessible via unmodified SPARQL endpoints [SHACL
>>> Spec]
>>>
>>> http://www.w3.org/2014/data-shapes/track/issues/74
>>>
>>> Raised by: Peter Patel-Schneider
>>> On product: SHACL Spec
>>>
>>> Should it be possible to validate SHACL shapes on RDF graphs that are
>>> only accessible via unmodified SPARQL endpoints?
>>>
>>> For example, suppose
>>> G = { < ex:a ex:r _:a .
>>>          _:a ex:q ex:b . }
>>> is a data graph to be validated against the shapes
>>> S1 = ex:r S2 [1,1]
>>> S2 = ex:q [1,1]
>>>
>>> Should it be possible to perform the validation if the only access G is
>>> via SPARQL queries?
>>>
>>> If this is possible, it should also be possible for very large data
>>> graphs.
>>>
>>>
>>>
>
>

Received on Thursday, 6 August 2015 19:51:30 UTC