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

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 <http://w3c.github.io/data-shapes/shacl/#dfn-iri> or blank
>> node <http://w3c.github.io/data-shapes/shacl/#dfn-blank-node> s that
>> fulfills at least one of the following conditions in the shapes graph
>> <http://w3c.github.io/data-shapes/shacl/#dfn-shapes-graph>:
>>
>>    - s is a SHACL instance
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-instance> of
>>    sh:NodeShape or sh:PropertyShape.
>>    - s is subject <http://w3c.github.io/data-shapes/shacl/#dfn-subject> of
>>    a triple that has sh:targetClass, sh:targetNode, sh:targetObjectsOf or
>>     sh:targetSubjectsOf as predicate
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
>>    - s is subject <http://w3c.github.io/data-shapes/shacl/#dfn-subject> of
>>    a triple that has a parameter
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-parameters> as predicate
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
>>    - s is a value <http://w3c.github.io/data-shapes/shacl/#dfn-value> of
>>    a shape-expecting
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-shape-expecting-constraint-parameters>,
>>    non-list-taking
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-list-taking-constraint-parameters>
>>     parameter <http://w3c.github.io/data-shapes/shacl/#dfn-parameters> such
>>    as sh:shape, or a member
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-members> of a SHACL list
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-list> that is a
>>    value <http://w3c.github.io/data-shapes/shacl/#dfn-value> of a
>>    list-taking
>>    <http://w3c.github.io/data-shapes/shacl/#dfn-list-taking-constraint-parameters>
>>     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
>> <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-sh
>> apes/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