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

On Fri, Apr 10, 2015 at 8:19 AM, Holger Knublauch <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