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

On 27/01/2017 16:06, Dimitris Kontokostas wrote:
> Good, this is getting closer to the previous state.
> I think the "expected type" term we had before would simplify the 
> definitions a lot.
> e.g. now, sh:languageIn & sh:in can also define shapes and if this is 
> taken to shacl full, any list-taking parameter can.

Sorry, I had fixed that shortly after my email - please check again in 
the latest version. It now says "shape-expecting and list-taking..." in 
the last sentence.

> These cases, even though might be (very) edge cases, would be needed 
> to properly determine recursion in a shapes graph
> Using expected type, we could define it only on the needed parameters 
> and say in e.g. sh:or, something like ".. The value of each sh:or is a 
> SHACL list. Each member of such list is an IRI or a blank node and its 
> expected type is sh:Shape ..."

I had thought about this but think it's better to have these 
enumerations in one place (otherwise people need to scan through the 
whole document). I don't think that introducing a new term "expected 
type" just for this single use case is necessary.

BTW I don't think extensions can still introduce new shape-expecting 
parameters since we deleted sh:hasShape. Is this correct?

> For reference, this is the previous version of the spec using the 
> expected type definition


> On Thu, Jan 26, 2017 at 10:45 PM, Holger Knublauch 
> < <>> wrote:
>     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
>     <>orblank node
>     <>|s|that
>     fulfills at least one of the following conditions in theshapes
>     graph <>:
>       * |s|is aSHACL instance
>         <>of|sh:NodeShape|or|sh:PropertyShape|.
>       * |s|issubject
>         <>of a
>         triple that
>         has|sh:targetClass|,|sh:targetNode|,|sh:targetObjectsOf|or|sh:targetSubjectsOf|aspredicate
>         <>.
>       * |s|issubject
>         <>of a
>         triple that has aparameter
>         <>aspredicate
>         <>.
>       * |s|is avalue
>         <>of
>         ashape-expecting
>         <>,
>         non-list-taking
>         <>parameter
>         <>such
>         as|sh:shape|, or amember
>         <>of aSHACL
>         list
>         <>that
>         is avalue
>         <>of
>         alist-taking
>         <>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
>>>>     < <>> 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
>>>>>     <>|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
>>>>>>     < <>> 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.
>>>>>>     <>
>>>>>>     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]
>>>>>>>     <> 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. 
> -- 
> Dimitris Kontokostas Department of Computer Science, University of 
> Leipzig & DBpedia Association
> Projects:,, 
> Homepage:
> Research Group: AKSW/KILT

Received on Friday, 27 January 2017 06:31:48 UTC