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

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