- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 2 Dec 2016 08:09:33 +1000
- To: public-data-shapes-wg@w3.org
- Message-ID: <7513b92b-d8b9-19d5-2b31-539b74ae1132@topquadrant.com>
This is already explained in the spec. Either:
* the node is aSHACL instance <#dfn-shacl-instance>of|sh:Shape|
* the node has theexpected type <#dfn-expected-type>|sh:Shape|, which
is the case if it is used as a value ofshape-expecting constraint
parameters <#dfn-shape-expecting-constraint-parameters>such
as|sh:shape|(in the case of the list-valued
parameters|sh:and|,|sh:or|and|sh:partition|it must be amember
<#dfn-members>of the corresponding lists)
* the node has avalue <#dfn-values>for any of thetarget
<#dfn-target>properties|sh:targetClass|,|sh:targetNode|,|sh:targetObjectsOf|,|sh:targetSubjectsOf|and|sh:target|
These rules can only be fulfilled by either a subject or (in the case of
rule 2) an object of existing triples. It cannot be a literal because
none of these rules can be applied to literals (the values of the
shape-expecting parameters are all limited to bnodes and IRIs).
HTH
Holger
On 2/12/2016 5:27, Karen Coyle wrote:
> Uh, yes. But the question is about how shape is defined in SHACL, not
> what node means in RDF. When the document says "a shape is a node" is
> it defining a shape as either a subject, predicate or object? and does
> that also mean that a shape can be a literal? Because all of those are
> possible with the RDF definition of node.
>
> kc
>
> On 12/1/16 10:20 AM, Irene Polikoff wrote:
>> A node can participate in multiple triples and play a different role
>> in different triples, yet it is the same node and it can be talked
>> about simply as a node in a graph. Talking about a node as a subject,
>> object or a predicate makes sense only in a context of a specific
>> triple.
>>
>>> On Dec 1, 2016, at 12:33 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>>>
>>> One more thing - a node can be a subject, predicate or object. Would
>>> a node in predicate or object position define a shape? Can a shape
>>> be a literal?
>>>
>>> Peter pointed this out in an earlier email, which I am still
>>> searching for.
>>>
>>> kc
>>>
>>> On 11/28/16 9:04 AM, Karen Coyle wrote:
>>>>
>>>>
>>>> On 11/27/16 4:28 PM, Holger Knublauch wrote:
>>>>>
>>>>>
>>>>> On 28/11/2016 8:33, Karen Coyle wrote:
>>>>>> There is a simple solution to this, and it follows in part the
>>>>>> example
>>>>>> of the Annotations Working Group. Their spec defines a :
>>>>>>
>>>>>> ***
>>>>>> An Annotation is a rooted, directed graph that represents a
>>>>>> relationship between resources.
>>>>>> There are two primary types of resource that participate in this
>>>>>> relationship, Bodies and Targets.
>>>>>> Annotations have 0 or more Bodies.
>>>>>> Annotations have 1 or more Targets.
>>>>>> ****
>>>>>>
>>>>>> All that needs to be done is to define "shape" as a graph whose root
>>>>>> is a subject is of type sh:Shape, and has 0 or more targets and 1 or
>>>>>> more constraints.
>>>>>
>>>>> This would not be correct. A shape doesn't need one or more
>>>>> constraints.
>>>>> sh:Shape is a subclass of sh:Constraint (which makes every shape
>>>>> automatically also a constraint), but this doesn't "do" anything by
>>>>> itself. Also the zero or more doesn't add anything. (Shapes may also
>>>>> have labels etc).
>>>>
>>>> So drop the zero or more, but the spec itself says that shapes have
>>>> constraints:
>>>>
>>>> "property constraints of the shape" (3.1.1)
>>>>
>>>> Anyway, I'll take this to DCMI leadership. At this point, I can
>>>> only say
>>>> that our needs are not being met.
>>>>
>>>> kc
>>>>
>>>>
>>>>>
>>>>> As always, the more complexity we are adding here, someone will find
>>>>> problems with it. And pointing out issues is trivial compared to
>>>>> getting
>>>>> everything right. That's why I would leave out anything that isn't
>>>>> formally needed. We can leave such explanatory prose to other
>>>>> documents,
>>>>> and if these other documents prefer to understand a shape as a
>>>>> collection of specific triples then fine.
>>>>>
>>>>> Holger
>>>>>
>>>>>
>>>>>>
>>>>>> Really, that's all that is needed.
>>>>>>
>>>>>> kc
>>>>>> p.s. I like the idea of the shape having a "root" node. I'm not sure
>>>>>> if something needs to be said about targets, which are also of
>>>>>> sh:Shape - is it necessary to say that they are not what is meant
>>>>>> when
>>>>>> the spec talks about "shapes"?
>>>>>>
>>>>>> On 11/27/16 7:16 AM, Karen Coyle wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/26/16 3:08 PM, Holger Knublauch wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25/11/2016 5:41, Irene Polikoff wrote:
>>>>>>>>> I took the initial question to be "when is a resource (or a
>>>>>>>>> node) a
>>>>>>>>> shape?". And not to be "what are all the triples that describe a
>>>>>>>>> shape?".
>>>>>>>>>
>>>>>>>>> To me, these are two completely different questions. Colloquially
>>>>>>>>> speaking, shape may be said to be a set of triples. But writing a
>>>>>>>>> spec
>>>>>>>>> requires us to be precise. And precisely speaking, shape is
>>>>>>>>> not a set
>>>>>>>>> of triples, it is a node. Information about it is
>>>>>>>>> described/specified/defined using a set of triples.
>>>>>>>>>
>>>>>>>>> Thus, I would recommend closing the first question as resolved.
>>>>>>>>>
>>>>>>>>> As for the second question, why does it need to be answered? A
>>>>>>>>> more
>>>>>>>>> meaningful question may be "when is a shape graph sufficiently
>>>>>>>>> complete to be able to process it and what should a SHACL
>>>>>>>>> processor do
>>>>>>>>> when a shapes graph doesn't have all the necessary information"?
>>>>>>>>>
>>>>>>>>> For example, let's say a shapes graph contains only the following
>>>>>>>>> triples:
>>>>>>>>>
>>>>>>>>> ex:PersonShape
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:targetClass ex:Person ;
>>>>>>>>> sh:property [
>>>>>>>>> sh:predicate ex:worksFor;
>>>>>>>>> sh:shape ex:OrganizationShape;
>>>>>>>>> ].
>>>>>>>>>
>>>>>>>>> This, to me, would be insufficient to do anything with since to
>>>>>>>>> validate data against it, we need to have a description of
>>>>>>>>> ex:OrganizationShape. What should happen in such cases?
>>>>>>>>
>>>>>>>> This case is covered by the spec. It's simply a shape without
>>>>>>>> constraints, i.e. every node conforms to it. Yet it's
>>>>>>>> syntactically
>>>>>>>> valid because the expected type of sh:shape is sh:Shape.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Other examples mentioned by Karen:
>>>>>>>>>
>>>>>>>>> ex:ExampleShapeWithPropertyConstraints
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:property [
>>>>>>>>> sh:predicate ex:email ;
>>>>>>>>> sh:name "e-mail" ;
>>>>>>>>> sh:description "We need at least one email
>>>>>>>>> value" ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> ] ;
>>>>>>>>> sh:property [
>>>>>>>>> sh:path (ex:knows ex:email) ;
>>>>>>>>> sh:name "Friend's e-mail" ;
>>>>>>>>> sh:description "We need at least one email for
>>>>>>>>> everyone you know" ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> ] .
>>>>>>>>>
>>>>>>>>> There is only one shape -
>>>>>>>>> ex:ExampleShapeWithPropertyConstraints. If
>>>>>>>>> this is all the content of a shapes graph, it is fine. All the
>>>>>>>>> information needed for validation is here.
>>>>>>>>>
>>>>>>>>> ex:MyShape
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:targetNode ex:MyInstance ;
>>>>>>>>> sh:property [
>>>>>>>>> # Violations of sh:minCount and sh:datatype are
>>>>>>>>> produced as warnings
>>>>>>>>> sh:predicate ex:myProperty ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> sh:datatype xsd:string ;
>>>>>>>>> sh:severity sh:Warning ;
>>>>>>>>> ] ;
>>>>>>>>>
>>>>>>>>> One shape - ex:MyShape. It refers to a target node. Target
>>>>>>>>> node is
>>>>>>>>> not
>>>>>>>>> a shape, it identifies a node in a data graph that is to be
>>>>>>>>> validated
>>>>>>>>> against a shape, so I am not sure what is the question.
>>>>>>>>>
>>>>>>>>> ex:PersonShape
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:targetClass ex:Person ;
>>>>>>>>> sh:property ex:PersonShape-name .
>>>>>>>>>
>>>>>>>>> ex:PersonShape-name
>>>>>>>>> a sh:PropertyConstraint ;
>>>>>>>>> sh:predicate ex:name ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> sh:deactivated true .
>>>>>>>>>
>>>>>>>>> There is only one shape - ex:PersonShape. All the information
>>>>>>>>> necessary for validation is present and, in fact, there would be
>>>>>>>>> automatic conformance since the only constraint is disabled.
>>>>>>>>> However,
>>>>>>>>> if a shapes graph only contained the following, validation
>>>>>>>>> would not
>>>>>>>>> be possible (I think):
>>>>>>>>>
>>>>>>>>> ex:PersonShape
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:targetClass ex:Person ;
>>>>>>>>> sh:property ex:PersonShape-name .
>>>>>>>>>
>>>>>>>>> So, again, what should happen in these cases?
>>>>>>>>>
>>>>>>>>> All the examples above are for a single shape. In some of the
>>>>>>>>> examples
>>>>>>>>> information about it is complete enough to validate data
>>>>>>>>> against the
>>>>>>>>> shape. In others, it is not. We should also consider the fact
>>>>>>>>> that a
>>>>>>>>> shapes graph can and often will contain multiple shapes and some
>>>>>>>>> shapes may have sufficient description to validate against and
>>>>>>>>> others
>>>>>>>>> may not. Also, some shapes may have some information that can be
>>>>>>>>> checked and some that can't be. For example, given the shape
>>>>>>>>> graph
>>>>>>>>> below we would know enough to check conformance of values of
>>>>>>>>> ex:email,
>>>>>>>>> but not know enough to check values of ex:worksFor.
>>>>>>>>>
>>>>>>>>> ex:PersonShape
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:targetClass ex:Person ;
>>>>>>>>> sh:property [
>>>>>>>>> sh:predicate ex:worksFor;
>>>>>>>>> sh:shape ex:OrganizationShape;
>>>>>>>>> ];
>>>>>>>>>
>>>>>>>>> sh:property [
>>>>>>>>> sh:path (ex:knows ex:email) ;
>>>>>>>>> sh:name "Friend's e-mail" ;
>>>>>>>>> sh:description "We need at least one email for
>>>>>>>>> everyone you know" ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> ] .
>>>>>>>>>
>>>>>>>>> So, one proposal may be as follows:
>>>>>>>>>
>>>>>>>>> If a shapes graph contains any shapes that are insufficiently
>>>>>>>>> specified, processing doesn't happen and SHACL engine returns an
>>>>>>>>> error.
>>>>>>>>
>>>>>>>> The spec mentions several conditions under which a shapes graph is
>>>>>>>> invalid. These are typically written as "a shape must ...".
>>>>>>>>
>>>>>>>> On the more general topic of node vs triples, I find this rather
>>>>>>>> philosophical. The spec is pretty clear about what happens in each
>>>>>>>> context. Which triples "belong" to a shape is following from
>>>>>>>> that, but
>>>>>>>> not valuable on its own right.
>>>>>>>
>>>>>>> The spec is not "pretty clear" and this is not "philosophical" -
>>>>>>> it has
>>>>>>> to be clear *to all* what is being described in the spec. Insisting
>>>>>>> that
>>>>>>> the spec is ok when others are saying it is not is one of the
>>>>>>> things
>>>>>>> that is making the progress very slow. It is incredibly generous of
>>>>>>> people to be putting time into trying to make it actually clear,
>>>>>>> but,
>>>>>>> personally, I'm running out of steam. However, note that DCMI
>>>>>>> will not
>>>>>>> approve a highly flawed spec.
>>>>>>>
>>>>>>> kc
>>>>>>>
>>>>>>>>
>>>>>>>> Holger
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Another proposal may be:
>>>>>>>>>
>>>>>>>>> Data is processed against shapes that are sufficiently specified.
>>>>>>>>> Warning is issued regarding shapes that are insufficiently
>>>>>>>>> specified
>>>>>>>>> and, thus, ignored.
>>>>>>>>>
>>>>>>>>> Yet another proposal may be:
>>>>>>>>>
>>>>>>>>> Data is processed against shapes that are sufficiently specified.
>>>>>>>>> Warning is issued regarding shapes that are insufficiently
>>>>>>>>> specified.
>>>>>>>>> SHACL processor will perform as much validation as it able to
>>>>>>>>> against
>>>>>>>>> insufficiently specified shapes.
>>>>>>>>>
>>>>>>>>> Of course, we would need to define what it means to be
>>>>>>>>> "insufficiently
>>>>>>>>> specified".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 24, 2016 at 12:29 PM, Karen Coyle <kcoyle@kcoyle.net
>>>>>>>>> <mailto:kcoyle@kcoyle.net>> wrote:
>>>>>>>>>
>>>>>>>>> Actually, I don't think this solves the problem that came
>>>>>>>>> up at
>>>>>>>>> the meeting. As we discussed in the meeting, the conflict is
>>>>>>>>> between a node, which is a single IRI, and a graph, which is a
>>>>>>>>> set
>>>>>>>>> of triples. Throughout the document, the term "shape" is
>>>>>>>>> used to
>>>>>>>>> refer to more than a single IRI.
>>>>>>>>>
>>>>>>>>> The statement below could be used for how a shape is
>>>>>>>>> identified
>>>>>>>>> (although I think we should discuss that further) but does not
>>>>>>>>> define how one finds the finite boundaries of the set of
>>>>>>>>> triples
>>>>>>>>> that is used as an instrument to define the validation
>>>>>>>>> rules that
>>>>>>>>> will be applied to a data graph.
>>>>>>>>>
>>>>>>>>> Something that was said in the meeting made me think that
>>>>>>>>> defining
>>>>>>>>> where a shape ends is as important as defining where it
>>>>>>>>> begins.
>>>>>>>>> (Note that in this case I am speaking of a shape as a set of
>>>>>>>>> triples, not a node - we know where a node ends, because it
>>>>>>>>> is a
>>>>>>>>> single point.)
>>>>>>>>>
>>>>>>>>> In an example like this (taken from the spec), I assume
>>>>>>>>> that this
>>>>>>>>> represents a single shape:
>>>>>>>>>
>>>>>>>>> ex:ExampleShapeWithPropertyConstraints
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:property [
>>>>>>>>> sh:predicate ex:email ;
>>>>>>>>> sh:name "e-mail" ;
>>>>>>>>> sh:description "We need at least one email
>>>>>>>>> value" ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> ] ;
>>>>>>>>> sh:property [
>>>>>>>>> sh:path (ex:knows ex:email) ;
>>>>>>>>> sh:name "Friend's e-mail" ;
>>>>>>>>> sh:description "We need at least one email for
>>>>>>>>> everyone you know" ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> ] .
>>>>>>>>>
>>>>>>>>> Where there is a target, which is also a shape, is this one or
>>>>>>>>> two
>>>>>>>>> shapes? And if two, what are the boundaries of each?
>>>>>>>>>
>>>>>>>>> ex:MyShape
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:targetNode ex:MyInstance ;
>>>>>>>>> sh:property [
>>>>>>>>> # Violations of sh:minCount and sh:datatype
>>>>>>>>> are
>>>>>>>>> produced as warnings
>>>>>>>>> sh:predicate ex:myProperty ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> sh:datatype xsd:string ;
>>>>>>>>> sh:severity sh:Warning ;
>>>>>>>>> ] ;
>>>>>>>>>
>>>>>>>>> The following is an example of the case that I believe was
>>>>>>>>> intended at the meeting. The question is whether this is one
>>>>>>>>> shape
>>>>>>>>> or two? And if it is two, how is that distinguished from the
>>>>>>>>> shape
>>>>>>>>> immediately above that has a target?
>>>>>>>>>
>>>>>>>>> ex:PersonShape
>>>>>>>>> a sh:Shape ;
>>>>>>>>> sh:targetClass ex:Person ;
>>>>>>>>> sh:property ex:PersonShape-name .
>>>>>>>>>
>>>>>>>>> ex:PersonShape-name
>>>>>>>>> a sh:PropertyConstraint ;
>>>>>>>>> sh:predicate ex:name ;
>>>>>>>>> sh:minCount 1 ;
>>>>>>>>> sh:deactivated true .
>>>>>>>>>
>>>>>>>>> If this seems petty, remember that throughout, the document
>>>>>>>>> refers
>>>>>>>>> to a thing called "shape" and all of the understanding of the
>>>>>>>>> document depends on the reader understanding exactly what that
>>>>>>>>> means.
>>>>>>>>>
>>>>>>>>> kc
>>>>>>>>>
>>>>>>>>> On 11/23/16 7:34 PM, Holger Knublauch wrote:
>>>>>>>>>
>>>>>>>>> Done.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Holger
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 24/11/2016 13:32, Irene Polikoff wrote:
>>>>>>>>>
>>>>>>>>> I suggest changing
>>>>>>>>>
>>>>>>>>> <A shape can be a node
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-node
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-node>>
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>> a shapes graph
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-shapes-graph
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-shapes-graph>>.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A node is a shape if and only if it fulfills either of
>>>>>>>>> the
>>>>>>>>> following
>>>>>>>>> conditions in the shapes graph:>
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> <A shape is a node
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-node
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-node>>
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>> a shapes graph
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-shapes-graph
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-shapes-graph>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>> fulfills either of the following conditions:
>>>>>>>>>
>>>>>>>>> On Wed, Nov 23, 2016 at 7:48 PM, Holger Knublauch
>>>>>>>>> <holger@topquadrant.com
>>>>>>>>> <mailto:holger@topquadrant.com>
>>>>>>>>> <mailto:holger@topquadrant.com
>>>>>>>>> <mailto:holger@topquadrant.com>>> wrote:
>>>>>>>>>
>>>>>>>>> The current definition in 2.1 reads
>>>>>>>>>
>>>>>>>>> A shape can be a node
>>>>>>>>> <#m_1017120090268237992_dfn-node> in
>>>>>>>>> a shapes graph
>>>>>>>>> <#m_1017120090268237992_dfn-shapes-graph> that is
>>>>>>>>> a SHACL instance
>>>>>>>>> <#m_1017120090268237992_dfn-shacl-instance> of
>>>>>>>>> |sh:Shape|; or it
>>>>>>>>> can be a node so that the expected type
>>>>>>>>> <#m_1017120090268237992_dfn-expected-type> of the node
>>>>>>>>> is |sh:Shape|, or a node that has a value
>>>>>>>>> <#m_1017120090268237992_dfn-values> for a target
>>>>>>>>> <#m_1017120090268237992_dfn-target> property such
>>>>>>>>> as |sh:targetClass| in the shapes graph
>>>>>>>>> <#m_1017120090268237992_dfn-shapes-graph>.
>>>>>>>>>
>>>>>>>>> These are all (3) ways of how shapes are
>>>>>>>>> identified. I
>>>>>>>>> have just
>>>>>>>>> added some precision based on the newly introduced
>>>>>>>>> term
>>>>>>>>> shape-expecting constraint parameters, and
>>>>>>>>> explicitly
>>>>>>>>> enumerated
>>>>>>>>> the target properties. The definition now reads
>>>>>>>>>
>>>>>>>>> A shape can be a node
>>>>>>>>> <#m_1017120090268237992_dfn-node> in
>>>>>>>>> a shapes graph
>>>>>>>>> <#m_1017120090268237992_dfn-shapes-graph>. A node
>>>>>>>>> is a shape if and only if it fulfills either of
>>>>>>>>> the
>>>>>>>>> following
>>>>>>>>> conditions in the shapes graph:
>>>>>>>>>
>>>>>>>>> * the node is a SHACL instance
>>>>>>>>> <#m_1017120090268237992_dfn-shacl-instance> of
>>>>>>>>> |sh:Shape|
>>>>>>>>> * the node has the expected type
>>>>>>>>> <#m_1017120090268237992_dfn-expected-type>
>>>>>>>>> |sh:Shape|, which
>>>>>>>>> is the case if it is used as a value of
>>>>>>>>> shape-expecting
>>>>>>>>> constraint parameters
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <#m_1017120090268237992_dfn-shape-expecting-constraint-parameters>
>>>>>>>>>
>>>>>>>>> such
>>>>>>>>> as |sh:shape| (in the case of the list-valued
>>>>>>>>> parameters |sh:and|, |sh:or| and
>>>>>>>>> |sh:partition| it
>>>>>>>>> must be a
>>>>>>>>> member of the corresponding lists)
>>>>>>>>> * the node has a value
>>>>>>>>> <#m_1017120090268237992_dfn-values> for
>>>>>>>>> any of the target
>>>>>>>>> <#m_1017120090268237992_dfn-target> properties
>>>>>>>>> |sh:targetClass|, |sh:targetNode|,
>>>>>>>>> |sh:targetObjectsOf|,
>>>>>>>>> |sh:targetSubjectsOf| and |sh:target|
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Change:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd appreciate if WG members could double check
>>>>>>>>> this
>>>>>>>>> definition.
>>>>>>>>> Meanwhile I have turned the change above into a
>>>>>>>>> PROPOSAL for a
>>>>>>>>> future meeting:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209:_What_is_a_shape
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209:_What_is_a_shape>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209:_What_is_a_shape
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209:_What_is_a_shape>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Holger
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 24/11/2016 9:49, Irene Polikoff wrote:
>>>>>>>>>
>>>>>>>>> I believe the question is "How do I know
>>>>>>>>> that a
>>>>>>>>> node is a
>>>>>>>>> shape?". The spec says that it is
>>>>>>>>> "typically" a
>>>>>>>>> SHACL instance of
>>>>>>>>> sh:Shape. This is one way, but not the
>>>>>>>>> definitive
>>>>>>>>> way (because of
>>>>>>>>> "typically") to determine that something is a
>>>>>>>>> shape.
>>>>>>>>>
>>>>>>>>> What are other ways? E.g., any subject of a
>>>>>>>>> triple
>>>>>>>>> with one of
>>>>>>>>> the SHACL target or constraint predicates is a
>>>>>>>>> shape.
>>>>>>>>>
>>>>>>>>> On Sun, Nov 20, 2016 at 3:58 PM, RDF Data
>>>>>>>>> Shapes
>>>>>>>>> Working Group
>>>>>>>>> Issue Tracker <sysbot+tracker@w3.org
>>>>>>>>> <mailto:sysbot%2Btracker@w3.org>
>>>>>>>>> <mailto:sysbot+tracker@w3.org
>>>>>>>>> <mailto:sysbot%2Btracker@w3.org>>> wrote:
>>>>>>>>>
>>>>>>>>> shapes-ISSUE-209 (What is a shape?): What
>>>>>>>>> is a
>>>>>>>>> shape [SHACL Spec]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.w3.org/2014/data-shapes/track/issues/209
>>>>>>>>> <http://www.w3.org/2014/data-shapes/track/issues/209>
>>>>>>>>>
>>>>>>>>> <http://www.w3.org/2014/data-shapes/track/issues/209
>>>>>>>>> <http://www.w3.org/2014/data-shapes/track/issues/209>>
>>>>>>>>>
>>>>>>>>> Raised by: Karen Coyle
>>>>>>>>> On product: SHACL Spec
>>>>>>>>>
>>>>>>>>> Peter's mail:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct/0029.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct/0029.html>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct/0029.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct/0029.html>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> "Just what are shapes?
>>>>>>>>>
>>>>>>>>> The terminology section says:
>>>>>>>>>
>>>>>>>>> "Shape
>>>>>>>>> A shape is a node in a shapes graph
>>>>>>>>> that is
>>>>>>>>> typically a SHACL
>>>>>>>>> instance of
>>>>>>>>> sh:Shape. A shape provides a collection of
>>>>>>>>> targets, filters,
>>>>>>>>> constraints and
>>>>>>>>> parameters of constraint components that
>>>>>>>>> specify how a data
>>>>>>>>> graph is
>>>>>>>>> validated against the shape. Shapes can
>>>>>>>>> also
>>>>>>>>> provide
>>>>>>>>> non-validating
>>>>>>>>> information, such as labels and comments."
>>>>>>>>>
>>>>>>>>> Section 2 says:
>>>>>>>>>
>>>>>>>>> "Shapes define constraints that a set of
>>>>>>>>> focus
>>>>>>>>> nodes can be
>>>>>>>>> validated
>>>>>>>>> against."
>>>>>>>>>
>>>>>>>>> This doesn't, however, provide guidance in
>>>>>>>>> determining what
>>>>>>>>> the shapes in a
>>>>>>>>> shapes graph are."
>>>>>>>>>
>>>>>>>>> (more in the email)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Karen Coyle
>>>>>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>>>>>>>> m: 1-510-435-8234 <tel:1-510-435-8234>
>>>>>>>>> skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Karen Coyle
>>> kcoyle@kcoyle.net http://kcoyle.net
>>> m: 1-510-435-8234
>>> skype: kcoylenet/+1-510-984-3600
>>>
>>
>>
>
Received on Thursday, 1 December 2016 22:10:17 UTC