W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: shapes-ISSUE-30 (shape-and-data-graphs): Are shapes and data in the same graph? [SHACL Spec]

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Tue, 31 Mar 2015 13:22:36 +0300
Message-ID: <CA+u4+a2=HO=O3u7tiKKF+b5zJfB1=kB8o_kd=stdhdyFAff+Ww@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
I am skeptical about this feature. I cannot work if for instance you want
to validate a SPARQL endpoint against a set of shapes not stored directly
in the endpoint.
If we allow this the difference should be somehow obvious, e.g. as a
separate (sub)property.

We also need to make clear that we check only the existence of the direct
literal values or IRIs and we do not perform subgraph comparison

# SHACL Graph - simplified
sh:property [
 sh:predicate ex:p1
 sh:allowedValues ex:a
ex:a ex:p2 ex:b

# Data Graph - simplified

ex:X ex:p1 ex:a
ex:a ex:p2 ex:c

This should pass since we do not check for the existence of "ex:a ex:p2
ex:b" in the data

On Tue, Mar 31, 2015 at 2:06 AM, Holger Knublauch <holger@topquadrant.com>

> FWIW my prototype uses two properties
> - sh:include (points from a graph to another data graph to include similar
> to owl:imports)
> - sh:library (points from a graph to a graph with constraint definitions
> These properties could be used to dynamically determine which other
> subgraphs need to be added into the query graph (visible in the WHERE
> clauses by default), versus the "compile-time" graph that is needed to
> figure out which constraints to validate at all.
> This assumes that a typical set up is roughly like
> my:InstanceGraph
>     sh:include/owl:imports my:ClassGraph (may include constraints)
>         sh:library SHACL namespace + other template libraries etc
> In that case, the query graph would consist of the first two graphs only,
> but exclude those graphs referenced via sh:library only.
> Another set up would be
> my:InstanceGraph
>     sh:include/owl:imports my:ClassGraph (just the schema)
>     sh:library my:ConstraintsGraph (constraints for schema)
>         sh:include my:ClassGraph
> in which case the query graph would consist of the first two graphs only,
> while my:ConstraintsGraph would only be visible at "compile time".
> I had hinted at such a solution when I wrote down the requirements
> https://www.w3.org/2014/data-shapes/wiki/Requirements#
> Organizing_Constraints_in_Named_Graphs
> https://www.w3.org/2014/data-shapes/wiki/Requirements#
> Including_Named_Graphs_for_Query_Evaluation
> which did not get any support yet. Maybe this problem was deemed too far
> down, and I am still not convinced that now is the best time to discuss
> these details - I believe we have more critical questions to answer first.
> Holger
> On 3/31/2015 3:11, Karen Coyle wrote:
>> On 3/29/15 3:49 PM, Richard Cyganiak wrote:
>> This though assumes that you have control over the instance data, which
>> is not always the case. So although this may work for some applications,
>> others will be operating over data created by third parties who have their
>> own data model. I mention this just so we can keep in mind that we have
>> both situations to address.
>>> I don't follow. Why does the described design require that I have
>>> control of the instance data, and why wouldn't it work with third-party
>>> data?
>>> Richard
>> Richard, I may have misunderstood your example, but the situation I am
>> referring to is one in which you are unlikely to know what graphs are used
>> in someone else's instance data, but you still need to validate properties
>> and values.
>> kc

Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Received on Tuesday, 31 March 2015 10:23:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:18 UTC