- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 1 Dec 2016 11:27:13 -0800
- To: Irene Polikoff <irene@topquadrant.com>
- Cc: public-data-shapes-wg@w3.org
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-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 >> > > -- 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 19:28:02 UTC