- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sun, 27 Nov 2016 09:08:59 +1000
- To: public-data-shapes-wg@w3.org
- Message-ID: <bd7d05a3-5b88-f7f7-4373-108e27fc1fe8@topquadrant.com>
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. 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> > >
Received on Saturday, 26 November 2016 23:09:38 UTC