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

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 00:42:51 UTC