Re: ISSUE-23: A specific proposal

Michel,

may I suggest that you raise your proposal as an ISSUE on the tracker? 
We can then move this thread into its proper place and derive a 
requirement for the WG's consideration.

Thanks,
Holger

PS: the shape selectors wiki page is not the right starting point, 
because it was just a generalization of the (global) 
rdf:type/sh:nodeShape patterns, not a selector tied to specific shapes.


On 4/27/2015 12:50, Michel Dumontier wrote:
> Adding a selector would add a lot of power to the approach, and would 
> be my preferred way of declaring a shape and having a simple pointer 
> to a target class.  when i look at the wiki page for shape_selectors, 
> i honestly don't see a simple, concrete example as i have just done. 
> Let's start with easy and work towards more complicated...
>
> m.
>
> Michel Dumontier, PhD
> Associate Professor of Medicine (Biomedical Informatics)
> Stanford University
> http://dumontierlab.com
>
> On Sun, Apr 26, 2015 at 6:23 PM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     On 4/27/2015 9:34, Michel Dumontier wrote:
>>
>>     On Sun, Apr 26, 2015 at 3:47 PM, Holger Knublauch
>>     <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>
>>         Michel,
>>
>>         SHACL validation is launched over a dataset that has a
>>         default graph - a collection of triples that have been
>>         selected by whatever mechanism. This includes the possibility
>>         for an application to build a (possibly temporary) default
>>         graph containing additional triples about a IRI not owned by
>>         you. So technically, this provides quite a bit of
>>         flexibility. I agree this practice would not necessarily
>>         translate well to a pure Linked Data approach where all
>>         information about a resource needs to reside at its URI.
>>
>>         On 4/27/2015 6:59, Michel Dumontier wrote:
>>>         It's fine to make a reference to a resource, but it's not OK
>>>         to make assertions where the subject IRI is not owned by
>>>         you. for instance, using the modeling I advocate,
>>>
>>>         bob's file:
>>>         bob:Issue
>>>           a owl:Class .
>>>
>>>         holger's file, where he modifies the meaning of bob:Issue
>>>         directly:
>>>         bob:Issue
>>>         sh:property [
>>>         sh:predicate ex:assignedTo ;
>>>         rdfs:label "assigned to" ;
>>>         rdfs:comment "The assignee of an issue must be a person." ;
>>>         sh:maxCount 1 ;
>>>         sh:valueType schema:Person ;
>>>         ] .
>>>
>>>         michel's file, where he creates a new shape to validate that
>>>         bob:Issues satisfy a particular constraint:
>>>
>>>         michel:IssueShape
>>>           rdfs:subClassOf bob:Issue
>>>           sh:property [
>>>         sh:predicate ex:assignedTo ;
>>>         rdfs:label "assigned to" ;
>>>         rdfs:comment "The assignee of an issue must be a person." ;
>>>         sh:maxCount 1 ;
>>>         sh:valueType schema:Person ;
>>>         ] .
>>
>>         Both approaches look fine to me. In the second approach you
>>         would still need to instruct the engine that all instances of
>>         Issue need to be verified against your extended IssueShape.
>>         This is covered by the existing rdf:type triples in the upper
>>         example. How would you like to represent this in the second
>>         approach?
>>
>>
>>     I guess this goes back to the comment i made a while ago ... with
>>     some kind of selector it would be more obvious how to choose the
>>     triples for validation.
>
>     I remember an earlier discussion with you that resulted in me
>     adding sh:scope to constraints:
>
>     http://w3c.github.io/data-shapes/shacl/#scope
>
>     and I like such a feature because it adds a consistent
>     filtering/pre-condition mechanism to constraints. It appears that
>     you would also like to have a similar mechanism for Shapes, see below.
>
>>     For instance, something like:
>>
>>     :IssueShape
>>       a sh:Shape;
>>       sh:selector [
>>          sh:property rdf:type;
>>          sh:valueType :Issue .
>>      ]
>>
>>      I like this because it gives us the power to generate more
>>     complex selectors. Otherwise, we'd might just specify to look for
>>     the rdfs:subClassOf predicate on the shape (obviously, we'd need
>>     to type our shape to sh:Shape here too).
>>       what do you think?
>
>     Yes this may work. We can tweak the metamodel in various ways to
>     allow such things. Indeed we had previous discussions in the
>     group, e.g. the idea of general Shape Selectors [1]. I also
>     believe that Peter's proposal [2] has coverage for such general
>     selection. I would be happy to add such features into the language
>     if there is sufficient agreement on this direction within the
>     group. Clearly this should be in addition to selection based on
>     rdf:type and sh:nodeShape as outlined in my current draft [3] - we
>     don't want to over-complicate the simple use cases. Neither do we
>     want to overload the language with too many modes of operation.
>
>     There is one performance issue to consider though, if we allow
>     shapes to specify under which conditions they apply. Example: if
>     the user is editing a form of a specific resource, and wants to
>     perform validation of her edits, then only that resource needs to
>     be validated - not the whole graph. This would be similar to the
>     validateNode operation [4]. In the case of general selectors, this
>     means that the system would need to walk through all defined
>     shapes and check their selectors. In large models this may be
>     quite time consuming. In the case of rdf:type and sh:nodeShape,
>     the situation is simpler because the system only needs to look at
>     a small number of shapes.
>
>     Thanks,
>     Holger
>
>     [1] https://www.w3.org/2014/data-shapes/wiki/Shape_Selectors
>     [2] https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql
>     [3] http://w3c.github.io/data-shapes/shacl/#shape-selection
>     [4] http://w3c.github.io/data-shapes/shacl/#operation-validateNode
>
>