W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

Re: Simplification of scopes section (see also ISSUE-148)

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sat, 14 May 2016 08:53:12 -0700
To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <573749E8.6020304@kcoyle.net>
Another way to look at this is that there is a data graph that is to be 
addressed. If the data graph as a whole is not to be the target of the 
constraints, then one must apply a scope to define the subset of the 
graph that is the focus of the constraints. There is no change (AFAIK) 
in the function of the constraint between:


ex:MyShape
     a sh:Shape ;
     rdfs:comment "every dct:subject must have IRIs as objects" ;
     sh:scopeClass ex:Class;
     sh:property [
         sh:predicate dct:subject ;
         sh:nodeKind sh:IRI ;
     ] .

and

ex:MyShape
     a sh:Shape ;
     rdfs:comment "every dct:subject must have IRIs as objects" ;
     sh:property [
         sh:predicate dct:subject ;
         sh:nodeKind sh:IRI ;
     ] .

In both cases, the constraint applies to the scope of the shape; this 
can be either the entire data graph or a subset of the data graph. If 
the property constraint can function on a graph selected with rdf:type 
then it can function on the data graph as a whole. The pre-selection of 
every triple with property dct:subject seems unnecessary. It also seems 
hard to grasp because node and class scopes pinpoint a starting node for 
a graph while the property scope is going to return individual triples. 
These do not seem to be the same logical function.

kc



On 5/14/16 5:07 AM, Dimitris Kontokostas wrote:
> Karen's example could be modeled with multiple shapes and property
> scopes or a single shape with allSubjectsScope and multiple sh:property
> definitions for dct:title & dct:subject which is more efficient
>
> Another gap that sh:AllSubjectsScope came to fill is sh:scopeClass
> rdfs:Resource that was available in very early versions of SHACL
> In general this scope gives shacl core the flexibility to define complex
> focus nodes using all subjects + filters that will not be easy otherwise
> so I would be keen on keeping this in core
>
> On Sat, May 14, 2016 at 7:22 AM, Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
>
>     Looking at this:
>
>     On 5/13/16 5:23 PM, Holger Knublauch wrote:
>
>         ex:MyShape
>               a sh:Shape ;
>               rdfs:comment "every dct:subject must have IRIs as objects" ;
>               sh:scopeProperty dct:subject ;
>               sh:property [
>                   sh:predicate dct:subject ;
>                   sh:nodeKind sh:IRI ;
>               ] .
>
>
>     There is 100% redundancy between sh:scopeProperty and the
>     constraint. If I were to state what I want to do in terms of
>     validation, it would come out like this:
>
>
>     ex:MyShape
>          a sh:Shape ;
>          rdfs:comment "every dct:subject must have IRIs as objects" ;
>          sh:property [
>              sh:predicate dct:subject ;
>              sh:nodeKind sh:IRI ;
>          ] .
>
>     because I am not using a scope at all. What this means is what is in
>     the comment. A scope, logically, is a selection from the data graph,
>     but this use case makes no such selection, and the constraint is
>     sufficient.
>
>     Is there a use of scopeProperty that would not be redundant?
>
>
>     kc
>
>     --
>     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://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Saturday, 14 May 2016 15:53:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC