- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 28 Nov 2016 09:04:39 -0800
- To: public-data-shapes-wg@w3.org
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 Monday, 28 November 2016 17:05:19 UTC