- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Tue, 3 May 2016 08:34:59 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
I think that part of the problem is that scopes and filters, and indeed the whole notion of just how validation works, are badly defined. When are scopes used? Is it the case that filters are always used to cut down on the nodes that are validated by constraints? It is difficult to determine answers to these questions from the spec. Here are some bits of the spec that show how bad this is currently done. Section 2. The set of focus nodes may be defined explicitly in a shape using scopes and filter shapes, or provided by the validation engine as defined in later sections. Shape scopes define the selection criteria for the focus nodes. Shapes with scopes MAY additionally provide filter shapes. Filter shapes further refine the focus nodes to the ones that conform to a set of filter shapes. Section 2.1 Scopes define the set of focus nodes for a shape and SHACL provides three scope types: Node scopes define a specific RDF node as scope. Class-based scopes define the scope as the set of all instances of a class. General scopes are a flexible mechanism to define arbitrary focus nodes. When multiple scopes are provided in a shape, the scope of a shape is the union of all focus nodes produced by these scopes. Focus nodes produced by scopes might not exist in the data graph. Section 2.2 A filter shape can further refine the scope of a focus node. [...] Formally, filter shapes eliminate entries from the collection of focus nodes selected by a shape's scopes, [...] Section 3. For property constraints the value nodes are the objects of the triples that have the focus node as subject and the given property as predicate. [...] For inverse property constraints the value nodes are the subjects of the triples that have the focus node as object and the given property as predicate. [...] For node constraints the value nodes are the individual focus nodes, forming a set of exactly one node. There needs to be some place that lays out how SHACL validation actually works. peter On 05/03/2016 07:22 AM, Dimitris Kontokostas wrote: > Hi Karen, > > I tried to reformulate 2.1.3.1 Property scopes (sh:PropertyScope) > Can you check if this makes it more clear? if it does I will adjust the rest > of the sections accordingly > https://github.com/w3c/data-shapes/commit/d2d70f5caa72f7911567d7692b58741fe7481625 > (the edit is also live) > > Dimitris > > On Mon, May 2, 2016 at 4:40 PM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> wrote: > > > > On 5/1/16 6:49 PM, Holger Knublauch wrote: > > Hi Karen, > > yes these are good points. The use of "scope class" here is confusing, > also due to the overlap with the unrelated sh:scopeClass property. The > proper term for them would be "scope type", which is also used in > section 8.2 > > Please review my edits: > > https://github.com/w3c/data-shapes/commit/4f74748b0637eeb5406abfce2797335baad6e33a > > > On 1/05/2016 10:27, RDF Data Shapes Working Group Issue Tracker wrote: > > shapes-ISSUE-159: [Editorial] Eliminate "scope class" from 2.1.n > [SHACL Spec] > > http://www.w3.org/2014/data-shapes/track/issues/159 > > Raised by: Karen Coyle > On product: SHACL Spec > > I would like to clarify 2.1.3 and its subsections by eliminating the > phrase "scope class". The current description in the introduction is: > > 2.1.3 (sentence 3) > "SHACL includes four built-in scope classes: sh:PropertyScope... etc." > > The pattern for each subsections reads: > > 2.1.3.1 Property scopes (sh:propertyScope) > "The scope class sh:PropertyScope selects all subjects that have at > least one value for a given property sh:predicate." > > I would suggest that we replace sentence 3 in 2.1.3 with: > "SHACL includes four subclasses of sh:Scope that define the core scope > types:...." > > And the pattern first statement for the subsections would be: > > "The class sh:PropertyScope is the class of those subjects that have > at least one value for a given property sh:predicate." > > > In the latter case I diverged a bit from your suggestion to the pattern > "represents the class of scopes of XY". I prefer this because a scope > does not represent a class of subjects - the term class is already > overloaded with different meaning IMHO. Scopes "represent" sets of nodes > in my opinion. > > > For the latter statement you have: > > "The scope type <code>sh:PropertyScope</code> represents the class of > scopes of all subjects that have at least one value for a given property > <code>sh:predicate</code>." > > This introduces a new concept "scope type" which isn't defined, and > includes "class of scopes" which is a grammatical rewording of "scope > class". Also, The sentence is too dense to be readable. Let's first talk > about what we want it to mean, then we can develop wording. > > -First is sh:PropertyScope a class? I believe that is the case. To what > extent that matters here is another matter. > > -Next, what is the "thing" (in the RDF sense) that is a member of that > class? First, "class of scopes" is as vague as our original "scope class". > What is the thing, and in which graph (shapes graph or data graph) is that > thing to be found? > > -What is meant here by "subject"? I believe that this refers to a node in > the data graph. Is that the case? > > -Finally, in editorial mode, "represents" should be "is". If there is a > type "sh:PropertyScope" it *is* a class. > > If I understand correctly, the shapes graph can have a subject (aka > "node") that is defined as being of rdfs:type sh:PropertyScope. That > subject has a predicate "sh:predicate" whose value is the predicate in the > data graph that is the target of the validation rules that are linked to > this shapes graph node. > > Or, to put this in simple English, the shapes graph states (or > "indicates") the predicate in the data graph that is the target of validation. > > kc > > > > Are these edits addressing your issue? > > Thanks > Holger > > > > Reasons: this eliminates the vague phrase "scope class", and also does > not ascribe agency to the subclasses (subclasses do not SELECT). > > > > > > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600> > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://http://aligned-project.eu <http://aligned-project.eu/> > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT >
Received on Tuesday, 3 May 2016 15:35:29 UTC