- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 1 Dec 2016 09:33:59 -0800
- To: public-data-shapes-wg@w3.org
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 17:34:40 UTC