Re: shapes-ISSUE-220 (what is a shape): defining shapes in a shapes graph [SHACL - Core]

Good, this is getting closer to the previous state.

I think the "expected type" term we had before would simplify the
definitions a lot.
e.g. now, sh:languageIn & sh:in can also define shapes and if this is taken
to shacl full, any list-taking parameter can.

These cases, even though might be (very) edge cases, would be needed to
properly determine recursion in a shapes graph

Using expected type, we could define it only on the needed parameters and
say in e.g. sh:or, something like ".. The value of each sh:or is a SHACL
list. Each member of such list is an IRI or a blank node and its expected
type is sh:Shape ..."

For reference, this is the previous version of the spec using the expected
type definition
https://jimkont.github.io/data-shapes/shacl/#OrConstraintComponent



On Thu, Jan 26, 2017 at 10:45 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> After some more discussions with Irene and Andy I have for now changed the
> definition of "shape" to include the bullet items that I had previously
> made informative only. See the updated definition in section 2.1, also
> copied below:
>
> A shape is an IRI <http://w3c.github.io/data-shapes/shacl/#dfn-iri> or blank
> node <http://w3c.github.io/data-shapes/shacl/#dfn-blank-node> s that
> fulfills at least one of the following conditions in the shapes graph
> <http://w3c.github.io/data-shapes/shacl/#dfn-shapes-graph>:
>
>    - s is a SHACL instance
>    <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-instance> of
>    sh:NodeShape or sh:PropertyShape.
>    - s is subject <http://w3c.github.io/data-shapes/shacl/#dfn-subject> of
>    a triple that has sh:targetClass, sh:targetNode, sh:targetObjectsOf or
>    sh:targetSubjectsOf as predicate
>    <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
>    - s is subject <http://w3c.github.io/data-shapes/shacl/#dfn-subject> of
>    a triple that has a parameter
>    <http://w3c.github.io/data-shapes/shacl/#dfn-parameters> as predicate
>    <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
>    - s is a value <http://w3c.github.io/data-shapes/shacl/#dfn-value> of a
>     shape-expecting
>    <http://w3c.github.io/data-shapes/shacl/#dfn-shape-expecting-constraint-parameters>,
>    non-list-taking
>    <http://w3c.github.io/data-shapes/shacl/#dfn-list-taking-constraint-parameters>
>     parameter <http://w3c.github.io/data-shapes/shacl/#dfn-parameters> such
>    as sh:shape, or a member
>    <http://w3c.github.io/data-shapes/shacl/#dfn-members> of a SHACL list
>    <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-list> that is a
>    value <http://w3c.github.io/data-shapes/shacl/#dfn-value> of a
>    list-taking
>    <http://w3c.github.io/data-shapes/shacl/#dfn-list-taking-constraint-parameters>
>     parameter such as sh:or.
>
> If we go down this route, we need to make sure we cover all scenarios
> exhaustively - it needs to be waterproof. In this respect I have added
> rules 2 and 3 which were absent in the other proposals. Rule 3 makes sure
> that targetless, typeless shapes can still be used by direct invocation of
> the engine.
>
> Please everyone review this and let me know where this definition is
> lacking.
>
> HTH
> Holger
>
>
>
> On 26/01/2017 18:01, Holger Knublauch wrote:
>
>
>
> On 26/01/2017 17:48, Irene Polikoff wrote:
>
> Holger,
>
> I can live with the section you have added. However, I was trying to
> figure out if there was a way to define something more normative.
>
> I made one assumption in the definition: users would have to explicitly
> say ex:Shape is a ex:Shape or ex:PropertyShape or sh:NodeShape.
>
>
> Yes, I expect that people will do this for all named shapes, and we have
> this as a "should" in sections 2.2 and 2.3.
>
>
> And the only time they would not have to do so is when a shape is
> specified in-line as a blank node e.g., there are 3 shapes below two of
> which are blank nodes:
>
> ex:QualifiedValueShapeExampleShape
>  a sh:NodeShape ;
>  sh:targetNode ex:QualifiedValueShapeExampleValidResource ;
>  sh:property [
>   sh:path ex:parent ;
>   sh:minCount 2 ;
>   sh:maxCount 2 ;
>   sh:qualifiedValueShape [
>    sh:path ex:gender ;
>    sh:hasValue ex:female ;
>   ] ;
>   sh:qualifiedMinCount 1 ;
>  ] .
>
> Because of this assumption, there is no need to talk about targets, etc.
> as a way to determine if a node is a shape.
>
>
> Note that even blank nodes may have targets, and I see no reason to
> disallow these cases. So the reasoning above does not apply.
>
>
> This means that given {ex:Shape sh:targetClass ex:Person}, ex:Shape is not
> a shape unless/until the type triple is added.
>
> This, of course, could be seen as a downside.
>
>
> Yes, I see that as a downside.
>
> Holger
>
>
>
>
>
>
> On Jan 26, 2017, at 2:23 AM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>
> Irene,
>
> why do you believe we should use this definition? It introduces an
> unnecessary term "expected type" and opens new kinds of complications. For
> example it does not include targets, making our definition of validation of
> data graphs against shapes graphs invalid because this would no longer
> count as shape:
>
>     ex:Shape sh:targetClass ex:Person .
>
> And this definition
>
>     ex:Shape sh:class ex:SomeClass .
>
> would no longer count as a shape either but we have prose that states that
> people can directly invoke validation with a given shape and a given focus
> node, bypassing the target mechanism. In that case the "shape" would not
> meet the formal definition of shapes.
>
> If anyone can show why the current spec requires the stronger notion of
> shapes anywhere, I am happy to change my mind. So far I am not seeing this
> and worry that we are creating unnecessary complications.
>
> Why are you not happy with the section that I have just added?
>
> Holger
>
>
> On 26/01/2017 17:06, Irene Polikoff wrote:
>
> Holger,
>
> What issues do you see with the following definition of a shape?
>
> The shapes of an RDF graph G are those nodes in G with SHACL or expected
> type
> <https://jimkont.github.io/data-shapes/shacl/core.html#dfn-expected-types>
>  sh:Shape in G
>
> RDF terms have zero or more expected types in an RDF graph. Each expected
> type for an RDF term in an RDF graph G is the result of the RDF term
> being the  object  of an RDF triple in G with a particular predicate as
> described below:
>
> If s is the object of an RDF triple in an RDF graph G with predicate
> sh:shape, sh:not, or sh:qualifiedValueShape then s has **expected type**
> sh:Shape in G.
> If s is a member of a SHACL list in an RDF graph G that is the object of
> an RDF triple in G with predicate sh:and, sh:or or sh:xor then s has
> **expected type** sh:Shape in G.
> If s is the object of an RDF triple in an RDF graph G with predicate
> sh:property then s has **expected type** sh:PropertyShape and **expected
> type** sh:Shape in G.
>
> The idea here is that when a shape is an IRI, there is no reason why its
> type should not be declared explicitly. Thus, saying “a node with SHACL
> type sh:Shape” works in this case.
>
> However, when a shape is a blank node that is described “in-line” as part
> of another shape, we don’t need to require such explicit typing. Instead,
> we could use the “expected type”.
>
> Are you concerned that this is too strict of a definition that may create
> issues for some user defined constraint components?
>
> Irene
>
>
> On Jan 25, 2017, at 7:44 PM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>
> As also discussed yesterday, I have added a paragraph right after the
> definition of "shape" in 2.1 explaining how this definition relates to
> well-formed shapes. This paragraph also links to a new section on "Finding
> Shapes in a Graph" with the patterns that can be used to distinguish shapes
> from other nodes.
>
> Note that these are informative because they are only required by a
> (hypothetical) group of applications such as UI tools, each of which may
> have different rules. For example some tools may rely on targets but others
> call shapes directly, by other means. Validation (which is our focus in the
> spec) does not need a formal definition of these rules, and making them a
> formal requirement invites new challenges on corner cases. So why
> complicate things further.
>
> https://github.com/w3c/data-shapes/commit/b2e47ae36f77cbcbd538f0ac5d0495
> 8149ff5fcd
>
> Corrections or additions are welcome.
>
> I hope this addresses this ticket.
>
> Holger
>
>
> On 26/01/2017 8:15, RDF Data Shapes Working Group Issue Tracker wrote:
>
> shapes-ISSUE-220 (what is a shape): defining shapes in a shapes graph
> [SHACL - Core]
>
> http://www.w3.org/2014/data-shapes/track/issues/220
>
> Raised by: Dimitris Kontokostas
> On product: SHACL - Core
>
> The current editor's draft (as of today) defines the following:
>
>  - A shape is an IRI or blank node in the shapes graph.
>  - sh:Shape is the SHACL superclass of those two shape types in the SHACL
> vocabulary. Its subclasses sh:NodeShape and sh:PropertyShape can be used to
> represent node and property shapes, respectively.
>  - A node shape is a shape in the shapes graph that is not the subject of
> a triple with sh:path as its predicate.
>  - A property shape must be the subject of a triple that has sh:path as
> its predicate. A node that has more than one value for sh:path is
> ill-formed. Each value of sh:path must be a well-formed SHACL property path.
>
> with the current definition, every non-literal node in a shapes graph is a
> shape. if a node has a value for sh:path the node is a property shape and
> all other nodes are node shapes.
> This provides no standardised way of identifying the shapes in a shapes
> graph.
>
> The recent editors draft as well as the latest WD (as of August 14th) had
> this well defined. The new spec introduced by Holger removed this
> definition.
>
>
>
>
>
>
>
>
>
>
>


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