W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2017

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

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 26 Jan 2017 18:01:14 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <d1e2f583-5618-c6be-f612-5d62a09ea11f@topquadrant.com>

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.


>> 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 08:01:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 January 2017 08:01:53 UTC