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

Holger,

I disagree with your argument that this requirement is an
implementation burden since the vocabulary terms that do not compute
rdfs:subClassOf* are simpler than those that do compute it. So the
same code can be re-used, just by adding a boolean flag to control
rdfs:subClassOf. Also, in the OSLC experience there is no reliance on
graph-level inferencing. This discussion boils down to adding two
vocabulary terms that match the OSLC semantics.

My main concern is that there is a natural migration path from OSLC
Resource Shapes to SHACL. Ideally, we should be able to automatically
convert an OSLC Resource Shape document into a SHACL document and they
should produce the same validation results and all input graphs.
Furthermore, the resulting SHACL document should be as readable as the
OSLC Resource Shape document. In particular, we do not want SPARQL to
be evident in the SHACL document. I believe these are important
considerations if we want SHACL to be adopted by OSLC.

That being said, we can achieve this in two ways. 1) we can provide
built-in high level SHACL vocabulary that matches the OSLC semantics,
2) OSLC can provide a standard library of SPARQL templates. If prefer
1), but as long as 2) is possible we are OK.

-- Arthur



On Tue, Jun 9, 2015 at 10:34 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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 Thursday, 18 June 2015 17:22:48 UTC