- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 7 Dec 2016 13:35:53 +1000
- To: public-data-shapes-wg@w3.org
Sorry I don't see a connection to what we discussed before. Could you elaborate? Holger On 7/12/2016 13:09, Karen Coyle wrote: > 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 >>>> >>>> >>> >> >
Received on Wednesday, 7 December 2016 03:36:33 UTC