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

BTW another example of a constraint where the WHERE clause would benefit 
from querying the shapes graph itself is Closed Shapes. These could be 
modeled using

ex:MyShape
     sh:property [
         ...
     ] ;
     sh:constraint [
         a sh:ClosedShapeConstraint .
     ]

where sh:ClosedShapeConstraint would walk the definition of sh:MyShape 
(and possibly its super-shapes) to collect all sh:predicates that are 
used. Then check that the instance has no property that is not among 
those predicates.

I believe the opportunities here are great and we shouldn't limit such 
scenarios to emerge, one way or another. With a generic solution anyone 
could define variations of things like Closed Shapes themselves in their 
own macro library.

Holger


On 4/10/15 4:35 PM, Dimitris Kontokostas wrote:
>
>
> On Fri, Apr 10, 2015 at 8:19 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     On 4/10/2015 15:12, Dimitris Kontokostas wrote:
>
>
>         I think you are referring  to sh:valueShape and the
>         sh:hasShape(?shape) function right? I don't see any other case
>         that could be problematic.
>
>
>     Also sh:OrConstraint (or any similar template that we or users may
>     want to add, such as negation and intersection). 
>
>
> Why can't we move these into the validation engine? e.g. (SPARQL Q1) 
> or/xor/... (SPARQL Q2)
>
>     And sh:allowedValues (which take a list or set of values, and
>     those must reside somewhere, I guess they should reside with the
>     shapes) - more general any template that takes rdf:List arguments
>     that need to be walked at runtime.
>
>
> These should indeed reside in the shapes graph(s). Implementations 
> could either pre-build the queries or build them at run-time.
> When we are working on immutable datasets (i.e. endpoints) 
> pre-building the values in the queries would be the only option.
> Implementations with other use cases could optimize this.
>
>
>         In this case, I was waiting for some clear definition for
>         recursion in order to make a proposal but I think we have many
>         options to go with.
>         For example: If the data and the constraints are in the same
>         graph we can use the sh:hasShape() function you propose,
>         otherwise use algorithm X to execute the ShEx validation in
>         multiple steps or Algorithm Y to convert the ShEx shape into a
>         (giant) SPARQL query similar to the ShEx 2 SPARQL [1].
>
>
>     I don't think we should limit ourselves to the hard-coded
>     built-ins of "ShEx" here - this should work with any user-defined
>     template/macro too.
>
>         If recursion is forbidden, things get much simpler and maybe -
>         I need to work on this first to say for sure - ShEx shapes
>         could be just treated as class shapes with an extra SPARQL filter.
>
>         We need to have a clear definition of the ShEx shapes to see
>         our options and we shouldn't limit the language design in advance.
>
>         Proposed resolution:Shapes and data are expected to exist in
>         different graphs unless specified specified otherwise
>
>
>     Agreed. In some cases the graph called the shapes graph could be
>     identical with the data graph though - it would just be accessed
>     via a magic named graph name or GRAPH ?variable.
>
>
> Indeed, the user could specify that they are identical in many cases 
> and implementations can optimize execution in these cases,
> But I think 'GRAPH ?variable' is an implementation detail, the spec 
> should assume that the data graph cannot access the shapes graph - or 
> provide alternative(s)
>
>
>
>     Holger
>
>
>
>
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://http://aligned-project.eu
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: http://aksw.org
>