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

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
>

Received on Monday, 30 March 2015 23:07:26 UTC