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

On 6/11/15 1:40 AM, Peter F. Patel-Schneider wrote:
> -----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.

Not a correct conclusion. Templates are more general. In general, a 
Template is just a way to wrap any SPARQL query. There is a subclass of 
sh:Template called sh:ConstraintTemplate, and I suggest to add another 
subclass sh:ScopeTemplate. The SPARQL queries behind ConstraintTemplates 
produce constraint violations, while the SPARQL queries behind 
ScopeTemplates produce focus nodes (bindings for ?this).

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

Not true, and as I explained in my other emails, sh:shapeScope cannot be 
used for scoping.

Holger


>
> 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 22:45:28 UTC