W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > October 2016

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

From: RDF Data Shapes Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Thu, 13 Oct 2016 08:03:24 +0000
To: public-data-shapes-wg@w3.org
Message-Id: <E1buaz6-0009Ug-2H@maia.w3.org>
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 08:03:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:37 UTC