- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 6 Dec 2016 19:09:16 -0800
- To: public-data-shapes-wg@w3.org
RDF 1.1 Semantics, section 9, valid triples: rdf:_2 rdfs:domain rdfs:Resource . rdf:_2 rdfs:range rdfs:Resource . kc On 12/5/16 4:15 PM, Holger Knublauch wrote: > RDF 1.1 Concepts and Abstract Syntax, section 1.2: > > Any IRI <https://www.w3.org/TR/rdf11-concepts/#dfn-iri> or literal > <https://www.w3.org/TR/rdf11-concepts/#dfn-literal> denotes something in > the world (the "universe of discourse"). These things are called resources. > > This states that literals *can* refer to resources but blank nodes can > not. Shapes can be represented by blank nodes in SHACL. > > What practical value does the term "resource" add? We are defining a > syntax (vocabulary) which is parsed by a machine. Of course humans are > free to link these syntactic structures to some real-world entity (such > as the concept of a shape) in our heads. Different people will have > different mental pictures of what this entity could be for them, and > that's a good topic for tutorials, but is IMHO not necessary to > formalize the algorithms for the machines. > > Holger > > > On 6/12/2016 1:38, Karen Coyle wrote: >> 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 Wednesday, 7 December 2016 03:09:58 UTC