- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 7 Dec 2016 12:11:54 -0800
- To: Irene Polikoff <irene@topquadrant.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Right, I mistook that for a blank node. However, I have been told by unnamed others, and of course this began with a useful suggestion by Jan Voskuil, that blank nodes are indeed referred to as resources, albeit unnamed - as Irene points out below. Yet when I suggested that we use the term "resource" because it makes sense to people, I was told in no uncertain terms by Holger that a blank node cannot be a resource so we cannot use that term. I'm giving up on this. All I get is very definite "no" to suggestions I make that endeavor to make this document more readable. I do not feel that my community's needs are being met in this standards process because of this continuous push-back against even editorial changes. It has become a waste of my time. kc On 12/7/16 11:42 AM, Irene Polikoff wrote: > I am also not sure what Karen is pointing out. rdf:_2 is not a blank > node. Karen, can you please clarify? > > The relevant (to this exchange) part of RDF 1.1 Concepts and Abstract > Syntax, section 1.2 is: > > Unlike IRIs <https://www.w3.org/TR/rdf11-concepts/#dfn-iri> and > literals <https://www.w3.org/TR/rdf11-concepts/#dfn-literal>, blank > nodes <https://www.w3.org/TR/rdf11-concepts/#dfn-blank-node> do not > identify specific resources > <https://www.w3.org/TR/rdf11-concepts/#dfn-resource>. Statements > <https://www.w3.org/TR/rdf11-concepts/#dfn-rdf-statement> involving > blank nodes say that something with the given relationships exists, > without explicitly naming it. > > A blank node indicates that a resource that fits the description exists > without naming it. There may be more than one. Thus, a blank node can > be used to say that a shape exists and describe it without naming it. > > A URI indicates one resource exists and names it. > > Formally speaking: > > * A shape is an abstract concept (in the domain of discourse, which in > RDF is everything, including RDF). > * An RDF Term refers (denotes, names) a shape. If it is a URI it is > because that URI is defined to be a shape - that information is not > in the graph. > * Because it is an abstract concept, it is not a literal. Literals > denote values (datatype). Actually, they self-denote which is what > makes them literals. > > So far, there are no triples and no graphs. This is all about naming or > denoting things. A URI refers to a shape because the creator of the URI > says it does. > > From there we can go into triples: > > It may be useful to add > > <x> a shacl:Shape . > > because that makes the information explicit in the graph. We now have a > graph that describes a shape. The graph is not a shape. It is a graph of > RDF Terms and a triple. Graphs describes (as in "Resource Description > Format") a shape in its various aspects. There are other ways of knowing > a term denotes a shape other than "a shacl:Shape". e.g. rdfs:domain of a > property. > > We could say that a shape is a resource that is denoted by an RDF Term. > I see no problem with this, but it would be like saying nothing. RDF > Terms denote. That's all they do. > > I propose a definition along these lines: > > A shape describes a set of conditions the structure of an RDF graph > must meet. By structure we mean what triples can and can not be a > part of a graph. A shape has a scope of applicability. By scope of > applicability we mean what subgraphs in an RDF data graph are > expected to conform to a shape. > > A shapes graph is a set of triples describing zero or more shapes. > > (A graph is a shapes graph if it is used as one. Any graph could be > that - nothing much happens if there are no shapes.) > > Data graph is any set of triples that is tested for conformance to > the shapes in the shapes graph. > > (This could be any graph including a graph that describes shapes. It > is the fact of it being tested that makes it a data graph.) > > What makes a graph the “shapes graph” or the "data graph" are their > roles in the process, not their content. > > A SHACL processor finds shapes in a graph by looking for nodes that > meet one of the following criteria: > > · the node is a SHACL instance > <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-instance> of > sh:Shape or > > · the node has the expected type > <http://w3c.github.io/data-shapes/shacl/#dfn-expected-type> > sh:Shape, which is the case if it is used as a value of > shape-expecting constraint parameters > <http://w3c.github.io/data-shapes/shacl/#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 is a member > <http://w3c.github.io/data-shapes/shacl/#dfn-members> of the > corresponding lists) or > > · the node has a value > <http://w3c.github.io/data-shapes/shacl/#dfn-values> for any of > the target <http://w3c.github.io/data-shapes/shacl/#dfn-target> > properties sh:targetClass, sh:targetNode, sh:targetObjectsOf, > sh:targetSubjectsOf and sh:target > > > (I am using the above bullets as-is in the spec, but they could and > probably should be further cleaned up.) > > > Irene > >> On Dec 6, 2016, at 10:09 PM, Karen Coyle <kcoyle@kcoyle.net >> <mailto:kcoyle@kcoyle.net>> 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 <mailto:kcoyle@kcoyle.net> >>>>> Cc: public-data-shapes-wg@w3.org <mailto: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 >>>>>> <mailto: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 >>>>>>>> <mailto: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> >>>>>>>>>>>>>> <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 >>>>>>>>>>>>>> <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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>>>>>> m: 1-510-435-8234 >>>>>>>> skype: kcoylenet/+1-510-984-3600 >>>>>> >>>>>> -- >>>>>> Karen Coyle >>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>>>> m: 1-510-435-8234 >>>>>> skype: kcoylenet/+1-510-984-3600 >>>>> >>>>> >>>> >>> >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net <mailto: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 20:12:33 UTC