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

On 13/10/2016 19:52, Dimitris Kontokostas wrote:
>
>
> On Thu, Oct 13, 2016 at 12:30 PM, Holger Knublauch 
> <holger@topquadrant.com <mailto: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

Which of these really do require an exhaustive list of shapes from a 
shapes graph? Driving a UI typically starts a given (instance) node and 
from there identifies the relevant shapes.

My concern is that the approach to somehow rely on the parameters of 
sh:hasShape to identify shapes is not working well. It would be like 
trying to infer the type of other RDF nodes because they happen to be 
used in some SPARQL function. The logic seems backward, and making 
sh:hasShape require expensive tests at runtime is a show stopper for 
that function. Unless there are strong reasons why finding all shapes in 
a graph is important, I don't think we even need to tackle this issue.

>     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?

Identifying shapes is basically a classification problem. RDFS/OWL were 
almost designed for the main purpose of solving classification problems. 
If rdfs:domain and rdfs:range can be used for that purpose then people 
who want to identify shapes in a graph can easily add these triples 
themselves. For SHACL we decided against full RDFS support because it is 
impractical to expect that to be activated on all RDF graphs. As you 
remember, Peter brought up these corner cases such as sub-properties of 
rdfs:subPropertyOf, so claiming any RDFS support quickly becomes an 
all-or-nothing question. I don't want us to go down that question again. 
I'd rather make the rdf:type sh:Shape triple a requirement (as long as 
we don't expect the same for sh:PropertyConstraint).

>
> 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

I see no practical problem with sh:hasShape simply assuming a default 
type for the parameters its gets.

Holger


>  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
>         <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
>