Re: Proposal for ISSUE-1

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 Wednesday, 10 June 2015 23:22:29 UTC