- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 27 Jan 2017 16:31:07 +1000
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <ea96d38d-f28d-5dc2-2032-2a59f47e28f1@topquadrant.com>
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 <mailto: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:
>
> Ashapeis anIRI
> <http://w3c.github.io/data-shapes/shacl/#dfn-iri>orblank node
> <http://w3c.github.io/data-shapes/shacl/#dfn-blank-node>|s|that
> fulfills at least one of the following conditions in theshapes
> graph <http://w3c.github.io/data-shapes/shacl/#dfn-shapes-graph>:
>
> * |s|is aSHACL instance
> <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-instance>of|sh:NodeShape|or|sh:PropertyShape|.
> * |s|issubject
> <http://w3c.github.io/data-shapes/shacl/#dfn-subject>of a
> triple that
> has|sh:targetClass|,|sh:targetNode|,|sh:targetObjectsOf|or|sh:targetSubjectsOf|aspredicate
> <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
> * |s|issubject
> <http://w3c.github.io/data-shapes/shacl/#dfn-subject>of a
> triple that has aparameter
> <http://w3c.github.io/data-shapes/shacl/#dfn-parameters>aspredicate
> <http://w3c.github.io/data-shapes/shacl/#dfn-predicate>.
> * |s|is avalue
> <http://w3c.github.io/data-shapes/shacl/#dfn-value>of
> ashape-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 amember
> <http://w3c.github.io/data-shapes/shacl/#dfn-members>of aSHACL
> list
> <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-list>that
> is avalue
> <http://w3c.github.io/data-shapes/shacl/#dfn-value>of
> alist-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 <mailto: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.
>
> --
> 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
Received on Friday, 27 January 2017 06:31:48 UTC