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

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

In my proposal sh:sparqlScope is designed to allow raw SPARQL.
sh:shapeScope is for shapes, i.e., currently RDF-encoded built-in shapes.
If templates are allowed, then template instances would be shapes and thus
would fit into sh:shapeScope.

So, no, it does not make sense to extend sh:sparqlScope in this way, but the
ability would be picked up via sh:shapeScope.

peter


On 06/08/2015 03:15 AM, Holger Knublauch wrote:
> Hi Peter, could we try to take baby steps towards a resolution here. My
> first question: your proposal has sh:sparqlScope - a query fragment that
> delivers bindings for ?this. Do you agree that it makes sense to
> generalize this to also allow templates here? This would allow us and
> others to introduce something like sh:PropertyScope or
> sh:AllSubjectsScope as high-level language terms without forcing users to
> repeat the underlying SPARQL query over and over again. It would also
> cater for other languages than SPARQL, if we decide to allow other
> extension languages.
> 
> Thanks, Holger
> 
> 
> On 6/5/15 10:06 PM, Peter F. Patel-Schneider wrote: So this ends up with
> scopes, filters, and constraints.  It requires that constraints do double
> duty, as both constraints and filters.
> 
> I still think that it is cleaner for shapes to have a scope and one or
> more constraints only, and to have constraints be used in both places.
> It eliminates a construct without eliminating any expressive power.
> 
> As far as binding goes there are several reasonable solutions, one of
> which is in essence automatically adding in a "universal" binding when
> required. I think that using constraints as filters is going to have the
> same issue anyway.
> 
> 
> 
> Using constraints as scopes can be done without requiring double
> expansion in templates.   For the example you mention below, my SPARQL
> expansion for hasValue on rdf:type to http:/example.org/Person could be
> used as the scope. It is not formulated in the opposite direction.
> 
> 
> peter
> 
> 
> 
> On 06/04/2015 04:29 PM, Holger Knublauch wrote:
>>>> On 6/5/2015 8:54, Peter F. Patel-Schneider wrote: There were
>>>> already separate scopes for individual-based scoping and
>>>> class-based scoping.
>>>> 
>>>>> Yes, my proposal is to keep sh:scopeClass and sh:nodeShape as
>>>>> syntactic sugar for the frequently needed cases that they cover.
>>>> Do you mean that there should now be a new kind of template for
>>>> scopes, and new special scopes, all separate from constraints?
>>>> 
>>>>> Yes, because scopes and shapes are very different concepts.
>>>>> Scopes produce focus nodes, while constraints validate given
>>>>> focus nodes.
>>>> 
>>>> 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.
>>>> 
>>>>> Because they cannot always do double duty, as we had discussed
>>>>> here at length. This is due to the way that they are implemented.
>>>>> A constraint produces violation instances, but what we need are
>>>>> focus nodes. In other words, constraints look for the counter
>>>>> examples, while we would need the opposite direction to find all
>>>>> nodes that actually fit. I am surprised about your feedback,
>>>>> because your own proposal had exactly the same concept, in form
>>>>> of sh:sparqlScope. In your own example, you use it to return all
>>>>> instance of ex:Person: [ rdf:type sh:Constraint ; sh:severity
>>>>> sh:fatalError ; sh:report "SELECT ?person" ; sh:sparqlScope
>>>>> "?person rdf:type <http://example.org/Person>" ; sh:sparqlShape
>>>>> """FILTER NOT EXISTS { ?person ex:offspring ?offspring . FILTER
>>>>> NOT EXISTS { ?offspring rdf:type ex:Person . } }""" ] . If this
>>>>> scope were a constraint, then it would be formulated in the 
>>>>> opposite direction "report an error if this is not an instance
>>>>> of ex:Person". All I have done is generalize your approach to
>>>>> allow sparqlScope to also be a template, and I have moved your
>>>>> sh:shapeScope into sh:filterShape. This solves the problem with
>>>>> your approach, that some constraints simply do not bind ?this.
>>>>> Your work-around was to inject some magic to bind ?this with all
>>>>> instances of rdfs:Resource, so but even this hack now can have an
>>>>> official solution: sh:ShapeScope a sh:ScopeTemplate sh:argument [
>>>>> sh:predicate sh:shape ; # becomes ?shape in the query
>>>>> sh:valueType sh:Shape ; rdfs:comment "The shape that all focus
>>>>> nodes must have" ] ; sh:sparql """ SELECT ?this WHERE { ?this a
>>>>> rdfs:Resource . FILTER sh:hasShape(?this, ?shape) } """ . And we
>>>>> side-step the question whether ?this should by default be all 
>>>>> subjects, all nodes, all instances, etc. We just define a
>>>>> generic mechanism and let the model do the rest. Anyone can add
>>>>> their own scoping template. As a bonus we don't have to look into
>>>>> complex SPARQL query analysis to find out whether a query is
>>>>> binding ?this and similar unnecessary complexity that few users
>>>>> will understand. Hope this makes sense, I can elaborate further. 
>>>>> Holger
>>>> 
>>>> 
>>>> 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

iQEcBAEBCAAGBQJVeFp1AAoJECjN6+QThfjzLWoH/jFHBN8lNpNiO36MrY0wzkoO
NHou8scRSCjO1evJtUIlEhoZ73Uo90q0dnWUtI2NewY8eQFA3N7j5Bo7mD2OZ2yb
IpDo/pefdxXJwIf5qvcn9ev2m9jETt51YPvm7qIjwZs09Du+iIt2j3LD/sKTBQ/O
OsNEapCOvqM6IsvMNMaIES7ThGytmiOwpx/BuEw7H3UUqARElep74RUSdAj00zGR
iGTsTAbtriQLAhNDqdFYSi6hboNgOzMXsAiIcOpbma9RNXGA+yj30lQxRA6D9We2
G3lep0DENJeSev2jXEvgr1dmiK0DI51ntvHgC6aRtoh09KnIIg9w+dv1qP2esUg=
=axso
-----END PGP SIGNATURE-----

Received on Wednesday, 10 June 2015 15:41:10 UTC