- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 5 Dec 2016 07:38:09 -0800
- To: Jan Voskuil <jan.voskuil@taxonic.com>, Irene Polikoff <irene@topquadrant.com>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
I like the wording that it is a resource (not just a node or an IRI), and that it is referred to *by means of an IRI*. That is much clearer and corresponds to how it is used in the spec. kc On 12/2/16 12:29 AM, Jan Voskuil wrote: > I agree. To be even more precise: a shape is a resource and can be referred to by means of an IRI or a blank node. Literals do not refer to resources. -j > > -----Original Message----- > From: Irene Polikoff [mailto:irene@topquadrant.com] > Sent: 02 December 2016 03:25 > To: kcoyle@kcoyle.net > Cc: public-data-shapes-wg@w3.org > Subject: Re: shapes-ISSUE-209 (What is a shape?): What is a shape [SHACL Spec] > > Shapes can be subjects and objects of triples. A shape can't be a literal. > > If it helps, the spec could say that a shape is either an IRI or an anonymous node. > > Sent from my iPhone > >> On Dec 1, 2016, at 2:27 PM, Karen Coyle <kcoyle@kcoyle.net> 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-n >>>>>>>>>> ode >>>>>>>>>> >>>>>>>>>> <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-s >>>>>>>>>> hapes-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-n >>>>>>>>>> ode >>>>>>>>>> >>>>>>>>>> <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-s >>>>>>>>>> hapes-graph >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-s >>>>>>>>>> hapes-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/bec7b6852529acc80954 >>>>>>>>>> dbc38cf4e435861238a2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc8095 >>>>>>>>>> 4dbc38cf4e435861238a2> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc8095 >>>>>>>>>> 4dbc38cf4e435861238a2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc8095 >>>>>>>>>> 4dbc38cf4e435861238a2>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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/2016Oc >>>>>>>>>> t/0029.html> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oc >>>>>>>>>> t/0029.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oc >>>>>>>>>> t/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 >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet/+1-510-984-3600 > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Monday, 5 December 2016 15:39:03 UTC