Re: shapes-ISSUE-190 (Shape identification): Identifying the shapes in a SHACL Full shapes graph [SHACL - SPARQL]

On Thu, Oct 13, 2016 at 12:30 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> Could you clarify the motivation for this: You state "to determine which
> nodes in a shapes graph are treated as shapes." When is this required?
>

There are many useful things people can do with shapes, like
 - drive UIs
 - analyse the shapes graph to perform optimisations on the execution of
the shapes
 - check for errors on the shape definitions or suggest improvements
 - + many things the ~20 people on the WG cannot think of


> To me it sounds like the important bit is to be able to determine which
> shapes must be validated when the whole graph is validated, and this can be
> achieved by finding all subjects of sh:targetXY triples (plus rdfs:Classes
> that are also sh:Shapes).


We emulated rdfs:range for sh:shape, sh:or, sh:and, ... with expected type
for SHACL Processors to identify shapes when people omit the rdf:type
sh:Shape statement
Are ou suggesting we do the same for rdfs:domain for all target properties
then we are redefining almost all of rdfs reasoning, this is a different
topic but should we go this way too?

the issue here is that sh:hasShape can turn any node into a shape and in
SHACL Full there is currenty no way to know which nodes these are

 Dimtiris

>
>
>
> On 13/10/2016 18:03, RDF Data Shapes Working Group Issue Tracker wrote:
>
>> shapes-ISSUE-190 (Shape identification): Identifying the shapes in a
>> SHACL Full shapes graph  [SHACL - SPARQL]
>>
>> http://www.w3.org/2014/data-shapes/track/issues/190
>>
>> Raised by: Dimitris Kontokostas
>> On product: SHACL - SPARQL
>>
>> the function sh:hasShape takes an IRI or a blank node as a second
>> argument that represents a shape.
>>
>> At the moment there is no requirement that the input is a shape, any
>> input node is treated as a shape.
>> This makes the static analysis of a shapes graph impossible.
>>
>> The reason is that shapes are determined at runtime and require the
>> evaluation of SPARQL queries to determine which nodes in a shapes graph are
>> treated as shapes.
>> Depending on the SPAQL queries, even the data graph may affect which
>> nodes become shapes.
>>
>> This makes :
>> 1) the identification of shapes depend on a specific validation (i.e. the
>> same shapes graph might use as shapes different nodes depending on which
>> data graph we are validating against)
>> 2) We cannot get all back the nodes that served as shapes in a specific
>> validation because this is internal to the SPARQL Engine
>>
>> One way to overcome this is to require every input of sh:hasShape to be a
>> shape (be a SHACL instance of sh:Shape or have sh:Shape as expected type)
>> However, this brings an overhead in the implementation of the function.
>>
>>
>> There are two options here:
>> 1) leave the definition as is but have no way to do static analysis of
>> SHAPES Graphs with SHACL Full
>> 2) require the input of sh:hasShape to be shapes
>>
>>
>>
>>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT