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

I would like to encourage everyone to be always careful and disciplined
when using the word ³validate² and its derivatives. Even if the writing is
not in a spec, the discipline will help in keeping the spec consistent.

For example:

"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)²


To me, this reads like shapes are validated against data and not the other
way around

Irene 




On 10/13/16, 4:03 AM, "RDF Data Shapes Working Group Issue Tracker"
<sysbot+tracker@w3.org> 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
>
>
>

Received on Thursday, 13 October 2016 15:27:55 UTC