- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 6 Dec 2016 10:15:41 +1000
- To: public-data-shapes-wg@w3.org
- Message-ID: <fcbb875a-2309-9693-e673-c2f32b14fc7b@topquadrant.com>
RDF 1.1 Concepts and Abstract Syntax, section 1.2: AnyIRI <https://www.w3.org/TR/rdf11-concepts/#dfn-iri>orliteral <https://www.w3.org/TR/rdf11-concepts/#dfn-literal>denotessomething in the world (the "universe of discourse"). These things are calledresources. 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 >> >> >
Received on Tuesday, 6 December 2016 00:16:34 UTC