Re: shapes-ACTION-26: Draft a proposal for issue-1 (with holger)

Arthur, on the second part of your proposal (scope), I believe there is 
also a fairly clean solution based on the new sh:scope scoping mechanism 
(assuming it gets approved). One could say

ex:MyShape
     sh:scope [
         a sh:DirectTypeScope .
         sh:type ex:Person .
     ] ;
     sh:constraint ...

which is equivalent to

ex:MyShape
     sh:scope [
         sh:sparql "?this rdf:type ex:Person"
     ] ;
     sh:constraint ...

I could live better with such a generic, soft-coded solution than a new 
keyword that needs to be hard-coded into all engines.

If that's acceptable to you, this would leave the question of 
sh:valueType vs. sh:valueClass. I'd be happy to be convinced there - I 
just haven't seen such cases in practice. I would again be OK with a 
soft-coded solution, e.g. based on sh:valueShape / sh:hasValue instead 
of requiring a new keyword.

Holger


On 6/10/2015 10:40, Holger Knublauch wrote:
> Thanks for responding.
>
> On 6/10/2015 10:23, Arthur Ryman wrote:
>> Holger,
>>
>> Sorry for the delay. I've been away. Peter and I discussed this issue
>> last month in this thread: [1]. Your summary aligns well with that
>> discussion, except for one omitted point which I'll summarize here.
>>
>> I feel that it is important to give the user control over when
>> rdfs:subClassOf* is used.
>
> I am unconvinced that the distinction that you point out is important 
> enough to warrant new core language keywords (with the corresponding 
> overhead for implementers, documentation and users). I believe it 
> violates the assumptions of most users if we do not by default apply 
> subclass inferencing here. Furthermore, once graph-level inferencing 
> is activated, the system can no longer distinguish those cases anyway, 
> and your new properties would behave exactly like the other pair. 
> Also, the work-around to avoid class inheritance in scopes is to use 
> sh:nodeShape instead of relying on rdf:type, so I believe sh:scopeType 
> is unnecessary.
>
> I would like to understand why you believe this distinction is so 
> important. Do you have cases where only a direct instance is allowed 
> but none of the subclasses? How common are those cases that they 
> require a core language construct?
>
> Thanks
> Holger
>
>
>> We could do this by providing matched pairs
>> of properties. I proposed the following:
>>
>> 1. No inferencing - match rdf:type directly
>> sh:valueType
>> sh:scopeType
>
>>
>> 2. Follow rdfs:subClassOf triples (match the SPARQL property path
>> rdf:type/rdfs:subClassOf*)
>> sh:valueClass
>> sh:scopeClass
>>
>> This proposal has the advantage of using the suffixes "Type" and
>> "Class" consistently. We use "Type" to mean exactly matching rdf:type.
>> We use "Class" to mean matching rdf:type/rdfs:subClassOf*.
>>
>> People who want subclass inferencing will use the pair sh:valueClass
>> and sh:scopeClass. People who want exact rdf:type matching will use
>> the pair sh:valueType and sh:valueClass.
>>
>> [1] 
>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0109.html
>>
>> -- Arthur
>>
>> On Thu, Jun 4, 2015 at 8:37 PM, Holger Knublauch 
>> <holger@topquadrant.com> wrote:
>>> Arthur and I had this action, which somehow fell through the cracks 
>>> although
>>> I had included my proposal below already into the draft:
>>>
>>> My proposal (not coordinated with Arthur yet) would be:
>>>
>>> 1) SHACL cannot consistently rely on any graph-level inferencing to be
>>> available for the given graphs (for various technical reasons).
>>>
>>> 2) SHACL should rely on engine-level inferencing that walks the
>>> rdfs:subClassOf triples where needed, e.g. by generating appropriate 
>>> SPARQL
>>> queries:
>>> a) sh:valueType must also accept subclasses of the given class (e.g. 
>>> via
>>> rdfs:subClassOf*) [1]
>>> b) sh:scopeClass also applies to subclasses (i.e. constraints 
>>> defined for a
>>> superclass also apply to instances of the subclass) [2]
>>>
>>> 3) SPARQL queries can be annotated with sh:sparqlEntailment to 
>>> assert the
>>> presence of a given SPARQL entailment regime [3]
>>>
>>> Given that my task here was just to write down a proposal, I 
>>> consider the
>>> ACTION-26 done unless Arthur disagrees.
>>>
>>> Thanks,
>>> Holger
>>>
>>> [1]
>>> http://w3c.github.io/data-shapes/shacl/#sparql-AbstractValueTypePropertyConstraint 
>>>
>>> [2] http://w3c.github.io/data-shapes/shacl/#operation-validateNode
>>> [3] http://w3c.github.io/data-shapes/shacl/#sparql-entailment
>>>
>>>
>>> On 5/21/2015 4:12, RDF Data Shapes Working Group Issue Tracker wrote:
>>>> shapes-ACTION-26: Draft a proposal for issue-1 (with holger)
>>>>
>>>> http://www.w3.org/2014/data-shapes/track/actions/26
>>>>
>>>> Assigned to: Arthur Ryman
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>

Received on Wednesday, 10 June 2015 02:36:46 UTC