Re: Proposal for ISSUE-1

Holger,

Thx. We seem to have two threads going for this issue. In my other
response I indicated a preferred for core-language vocabulary terms,
but also long as OSLC can define a template library to achieve
equivalent behavior then we should be OK. The OSLC Core WG will need
to review this and other aspects of SHACL before adopting it.

-- Arthur

On Wed, Jun 10, 2015 at 7:21 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> On 6/11/15 8:49 AM, Arthur Ryman wrote:
>>
>> On Sun, May 24, 2015 at 8:00 PM, Holger Knublauch
>> <holger@topquadrant.com> wrote:
>>>>
>>>> I think we need to let user decide is they want the rdfs:subClassOf*
>>>> expression added to the property path. That is why I suggested we have
>>>> two properties sh:valueType and sh:valueClass. Your current behaviour
>>>> corresponds to what I called sh:valueClass. For the case of matching
>>>> against just rdf:type, we have the escape hatch of treating rdf:type
>>>> as just another property, and constraining it's allowed value to be
>>>> just the desired type. However, we'd need a way to do that for what
>>>> you call validateNode.
>>>
>>>
>>> Can you back this up with requirements, i.e. do you have a use case in
>>> which
>>> a constraint applies to a specific class, but not its subclasses?
>>>
>> Holger, Yes. OSLC Resource Shapes do not add in the rdfs:subClassOf*
>> path. Therefore, they will in general produce different results if
>> SHACL always adds refs:subClassOf*. It is a goal of OSLC to adopt a
>> W3C standard (e.g. as evidenced by LDP). If there is no way to
>> reproduce the OSLC behaviour, then this is slow adoption. I see no
>> compelling reason to introduce a breaking change in behaviour given
>> that there is a simple alternative as I have outlined.
>
>
> Thanks for the details. I believe SHACL already has solutions to your
> scenario (see also my recent emails on this thread). In the following, I use
> the term "direct instance" for lack of a better term, but I'd be happy to
> change this:
> - for scoping, use sh:nodeShape or a scope template sh:DirectInstancesScope
> - for valueType, we could introduce sh:directValueType (if you think it's
> important enough) or leave this to a custom template in your own namespace -
> that's why we have the extension mechanism after all.
>
> Now that I know how important this seems to be for your users, I would be
> happy to support something like sh:directValueType, but I think it is
> sufficient to cover the scoping case with a template instead of a hard-coded
> keyword. That, however, depends on a resolution of the parallel issue on
> scoping.
>
> In any case, your use cases *can* be expressed with SHACL already, so I
> don't think any of these details should block a resolution of the more
> general ISSUE-1.
>
> Thanks,
> Holger
>
>

Received on Thursday, 18 June 2015 17:49:21 UTC