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

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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
>
> iQEcBAEBCAAGBQJVcZDFAAoJECjN6+QThfjz5JEH/iCrAv0qYg3HnqZjxqIP4e0C
> cTJVrhSU3td+cKdRqe7gomMT8iQ+wwv4lAzmIuVLkePX1gpuPIMegOo39Hrgo1/7
> Xilum+XX9tfW81YOWBKyeoX+VLcG8VVVtCt8B6v997NMLJZQz9CduKMV0Au+ZG/r
> Ljdjn8aqOcE9qTXehXLJ71PSRBoMUw26bo7FAwke4VAhNrARSxO3x89xe1Aw+g96
> dydZIgU65Ega8NhEAjWz3RLjJXNLfF1TZ8Ti9nNzlb4H2PeReIRiTsRPKVvXdFXo
> 9sXFF29LtWJs5QlJ5LSqJS8AMZOJK9uNACVm14DL5HCP//vx/iU734/A6d/xYNw=
> =Pa8K
> -----END PGP SIGNATURE-----

Received on Monday, 8 June 2015 10:16:16 UTC