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

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 07:24:07 UTC