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

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

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.




> 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 <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 <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 <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:49:12 UTC