Re: shapes-ISSUE-220 (what is a shape): defining shapes in a shapes graph [SHACL - Core] from Holger Knublauch on 2017-01-26 (public-data-shapes-wg@w3.org from January 2017)

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 27 Jan 2017 06:45:34 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <80037a6f-ad62-d1ec-b953-cc22255ccd9e@topquadrant.com>
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:

Ashapeis anIRI <http://w3c.github.io/data-shapes/shacl/#dfn-iri>orblank 
node <http://w3c.github.io/data-shapes/shacl/#dfn-blank-node>|s|that 
fulfills at least one of the following conditions in theshapes graph 
<http://w3c.github.io/data-shapes/shacl/#dfn-shapes-graph>:

  * |s|is aSHACL instance
    <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-instance>of|sh:NodeShape|or|sh:PropertyShape|.
  * |s|issubject <http://w3c.github.io/data-shapes/shacl/#dfn-subject>of
    a triple that
    has|sh:targetClass|,|sh:targetNode|,|sh:targetObjectsOf|or|sh:targetSubjectsOf|aspredicate
    <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
  * |s|issubject <http://w3c.github.io/data-shapes/shacl/#dfn-subject>of
    a triple that has aparameter
    <http://w3c.github.io/data-shapes/shacl/#dfn-parameters>aspredicate
    <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
  * |s|is avalue <http://w3c.github.io/data-shapes/shacl/#dfn-value>of
    ashape-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 amember
    <http://w3c.github.io/data-shapes/shacl/#dfn-members>of aSHACL list
    <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-list>that is
    avalue <http://w3c.github.io/data-shapes/shacl/#dfn-value>of
    alist-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 <mailto: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 <mailto: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/b2e47ae36f77cbcbd538f0ac5d04958149ff5fcd
>>>>>
>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Thursday, 26 January 2017 20:46:42 UTC