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

Please feel free to edit this. I have no strong opinion.

Sent from my iPad

> On 27 Jan 2017, at 17:04, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> I would prefer something along the lines of Irene's wording; even without differentiating blank nodes. 
> but this is OK
> 
>> On Fri, Jan 27, 2017 at 8:31 AM, Holger Knublauch <holger@topquadrant.com> wrote:
>> 
>> 
>>> 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
>>> https://jimkont.github.io/data-shapes/shacl/#OrConstraintComponent
>> 
>> Holger
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> On Thu, Jan 26, 2017 at 10:45 PM, Holger Knublauch <holger@topquadrant.com> 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:
>>>> 
>>>> A shape is an IRI or blank node s that fulfills at least one of the following conditions in the shapes graph:
>>>> s is a SHACL instance of sh:NodeShape or sh:PropertyShape.
>>>> s is subject of a triple that has sh:targetClass, sh:targetNode, sh:targetObjectsOf or sh:targetSubjectsOf as predicate.
>>>> s is subject of a triple that has a parameter as predicate.
>>>> s is a value of a shape-expecting, non-list-taking parameter such as sh:shape, or a member of a SHACL list that is a value of a list-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 <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 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.
>>> 
>>> --
>>> Dimitris Kontokostas Department of Computer Science, University of Leipzig & DBpedia Association
>>> Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu
>>> Homepage: http://aksw.org/DimitrisKontokostas
>>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
> 
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>