Re: [ISSUE-62] A clean proposal with sh:Scope

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

There were already separate scopes for individual-based scoping and
class-based scoping.  Do you mean that there should now be a new kind of
template for scopes, and new special scopes, all separate from constraints?

Constraints are already available, and can do double duty as scopes.  Why
not use them for determining the scope of a shape particularly as you then
actually do use them for this purpose, but as filters.  I don't see what the
point is of adding all this extra stuff.

peter


On 06/03/2015 04:16 PM, Holger Knublauch wrote:
> I thought more about the issue of generic scopes and filters and have
> come up with a variation of Peter's design. Assuming we define
> 
> - Scope: takes a graph as input and produces bindings for the focus node
> (?this)
> 
> Graph -> focus nodes
> 
> - Constraint: that takes a focus node as input and produces (violation)
> results:
> 
> focus nodes -> results
> 
> I think we should make Scopes an explicit concept in SHACL's RDF
> vocabulary, similar to how shapes are defined. There would be the
> following class hierarchy:
> 
> sh:Scope sh:NativeScope sh:TemplateScope
> 
> And native scopes can have sh:sparql (or a JS body etc). Example
> 
> # Applies to all subjects that have a skos:prefLabel ex:MyShape sh:scope
> [ a sh:NativeScope ; # Optional rdf:type triple sh:sparql """ SELECT
> DISTINCT ?this WHERE { ?this skos:prefLabel ?any } """ ] ; sh:constraint
> [ a ex:UniqueLanguageConstraint ; ex:predicate skos:prefLabel ; ] .
> 
> This (common) case above could be turned into a template
> sh:PropertyScope:
> 
> ex:MyShape sh:scope [ a sh:PropertyScope ; sh:predicate skos:prefLabel . 
> ] ; sh:constraint [ a ex:UniqueLanguageConstraint ; ex:predicate
> skos:prefLabel ; ] .
> 
> and we could provide a small collection of frequently needed scopes,
> e.g.
> 
> - all nodes in a graph - all subjects - all nodes with any rdf:type - all
> IRI nodes from a given namespace
> 
> Systems that don't speak SPARQL would rely on the hard-coded IRIs from
> the core vocabulary, such as sh:PropertyScope.
> 
> We could now also formally define the scope behind sh:scopeClass (and 
> sh:nodeShape):
> 
> sh:ClassScope a sh:TemplateScope ; sh:argument [ sh:predicate sh:class ;
> # Becomes ?class sh:valueType rdfs:Class ; ] ; sh:sparql """ SELECT
> ?this WHERE { ?type rdfs:subClassOf* ?class . ?this a ?type . } """ .
> 
> In addition to these scopes, I suggest we turn sh:scopeShape into 
> sh:filterShape, and use these filters as pre-conditions that are
> evaluated for a given set of focus nodes. The workflow then becomes:
> 
> - sh:scope produces bindings for ?this - sh:filterShape filters out the
> values of ?this that do not match the given shape - the actual
> constraints are evaluated
> 
> I believe this design provides the flexibility of a generic scoping
> mechanism (as suggested in Peter's design) without getting into the
> complexity of having to analyze SPARQL syntax or rely on hacks with
> rdfs:Resource, while having a user-friendly syntax. The fact that we
> separate sh:Scope from sh:Shape means that we can enforce different,
> explicit semantics on scopes. For example we could allow a sh:Scope to
> encapsulate another SPARQL query that tests whether a given ?this is in
> scope, i.e. the inverse direction of the SELECT query, to optimize
> performance.
> 
> Thanks, Holger
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVcNcvAAoJECjN6+QThfjzi28H/3x3+0mmUmrKvEkbxuQ4Vp4a
1E65QIwcZuWhmocT+nHwtPT9Bb0nCMA4D+lsCfwGCp671dhoFmrHAAERe/xDKbSL
IJ1vRkstNA0Y+QKS29M2eKtICbO+R8z3ez6xlUNUA7yY0TfE4W1zB2nHh/wzJFyY
VM9KHhyQV7ZA+c5hdbai163rGOcFu7Mr54LsUiF2nZ5kAlgtZnJfn45Ewfip+kIO
a5zBlyqDY5T+GvgSEvFi1u+V0RjZPVnvApxT/oRbepLOu+EintFttH8IpB4T+HBB
yv/kyUGNH4lxNrsYVyAEzYmMi6KIUHuQEiI2VfB4tYRwLJwA7+VsECsRcRtjR/A=
=0+/m
-----END PGP SIGNATURE-----

Received on Thursday, 4 June 2015 22:55:23 UTC