- From: Irene Polikoff <irene@topquadrant.com>
- Date: Fri, 17 Jun 2016 16:30:45 -0400
- To: <kcoyle@kcoyle.net>, <public-data-shapes-wg@w3.org>
I believe pretty much everywhere it is stated that each focus node is examined against the constraints. For example: "A constraint <¡¦> determines how to validate focus nodes based on the values of properties of the node.¡± I suppose if necessary for additional clarity one could change this to: "A constraint <¡¦> determines how to validate each focus node based on the values of properties of the node.¡± All the examples in 1.3, describe the constraints in the context of each focus node. And so on. Perhaps, I don¡¯t understand the question or the thinking behind it. What did you think was happening with focus nodes and constraints? Irene On 6/17/16, 2:47 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >Interesting. Can you point out where this is explained in the spec? - kc > >On 6/17/16 10:22 AM, Irene Polikoff wrote: >> The way I understand it, when one uses scopeClass, the constraints apply >> to each SHACL instance of a class individually. For example, each >>instance >> of a Person can have only two parents. And a condition is tested against >> each node individually. >> >> This constraint, however, doesn©öt apply to each instance individually. >>It >> is about the number of all instances. This is quite different, so I >> wouldn©öt expect to use scopeClass. >> >> Irene >> >> >> >> >> >> >> On 6/17/16, 1:10 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >> >>> My preference overall would be to not use classes at all in validation; >>> to have all operations on triples, and rdf:type would be simply a >>> predicate like any other. (I believe that ShEx takes this approach.) >>> However, if you encourage people to view the objects of rdf:type as >>> classes, then you have to allow them to do so throughout, otherwise it >>> becomes difficult to explain "when is a class not a class?". >>> >>> With the solution in this proposal, we have what to the user is a class >>> but it does not use scopeClass, and scopeNode binds to the subject of a >>> triple, AFAI can determine. The below would not match the schema.org >>> example.[1] >>> >>> kc >>> [1] http://schema.org/FlightReservation >>> >>> >>> On 6/13/16 5:04 AM, RDF Data Shapes Working Group Issue Tracker wrote: >>>> shapes-ISSUE-168 (instance count): How to constrain number of >>>>instances >>>> of a class in a graph [SHACL - Core] >>>> >>>> http://www.w3.org/2014/data-shapes/track/issues/168 >>>> >>>> Raised by: Holger Knublauch >>>> On product: SHACL - Core >>>> >>>> There was recent discussion about how to specify min/max numbers of >>>> instances in a graph. Off-list I had also received a question from >>>> schema.org people about how to state that a graph/message must have >>>> exactly one instance of schema:FlightReservation, possibly to ensure >>>> that a graph has a starting point/root for validation. >>>> >>>> A possible syntax that would easily work with the current architecture >>>> could be >>>> >>>> ex:MyShape >>>> a sh:Shape ; >>>> sh:scopeNode schema:FlightReservation ; >>>> sh:constraint [ >>>> sh:minInstanceCount 1 ; >>>> sh:maxInstanceCount 1 ; >>>> ] . >>>> >>>> >>>> >>>> >>> >>> -- >>> 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 Friday, 17 June 2016 20:31:21 UTC