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

I think this is related to the postponed ISSUE-49 (
http://www.w3.org/2014/data-shapes/track/issues/49) and should be tackled
in parallel.

Example:

ex:As a sh:Shape ;
  sh:scopeClass ex:A
  sh:property [
    sh:predicate ex:p1 ;
    sh:minCount 1 .
 ] .

ex:Bs a sh:ShapeClass
 sh:scopeClass ex:B
 sh:property [
  sh:predicate ex:p2
  sh:valueShape ex:As
 ]

# data graph

ex:inst1 ex:p1 "somevalue".

ex:inst2 a ex:B ;
  ex:p2 ex:inst1.

example, would this be correct or not? meaning, do we expect ex:inst1 a
ex:A to exist in the data?

I know that this is quite technical at the moment but as it looks like
scope will be part of the shape and not separate as per Peter's suggestion.
What ever option we make we also need to decide if the scope / filtering
will be validated and if yes reusing the existing property facets will make
this easier

Best,
Dimitris



On Fri, Jun 5, 2015 at 3:54 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> Not sure if it helps, but attached is a simplified graphical workflow for
> how this proposal would work.
>
> Holger
>
>
>
> On 6/5/2015 9:29, Holger Knublauch wrote:
>
>> On 6/5/2015 8:54, Peter F. Patel-Schneider wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> 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
>>>
>>> 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-----
>>>
>>
>>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://http://aligned-project.eu,
http://rdfunit.aksw.org
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: http://aksw.org