Re: Proposal for ISSUE-1

On 5/23/2015 4:34, Arthur Ryman wrote:
> Holger,
>
> On Thu, May 21, 2015 at 7:20 PM, Holger Knublauch
> <holger@topquadrant.com> wrote:
>> I have updated the draft* to make a specific simple suggestion on how to
>> resolve this issue.
>>
>> 1) sh:valueType. This case was already handled.
> 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?

I believe constraints should only ever narrow down the constraints 
related to superclasses. The work-around would be to insert a 
pre-condition into the constraint attached at the superclass, to make 
sure that the scope of this constraint only includes direct instances of 
the class and not its subclasses. This is already doable, although I 
don't think this case is frequent enough to suggest its own keyword in 
the core language.

>
>> 3) Per-query entailment. I have added a section 12.4
>> Arthur, I have seen you suggested sh:assumes for the same job, but I believe
>> this is SPARQL-specificEntailment applies to RDF, not just SPARQL.
> It is true that SPARQL 1.1 defined a set of IRIs to define entailment
> regimes, but they make sense for any constraint language, including
> JS. The entailment regime determines what triples the constraint sees.

Consider you want to test the same example constraint as in [1], so that 
engines can either use SPARQL or JavaScript:

ex:EntailmentExampleShape
     a sh:Shape ;
     sh:constraint [
         sh:message "Labels must be in English" ;
         sh:sparqlEntailment <http://www.w3.org/ns/entailment/RDFS> ;
         sh:sparql """
             SELECT ?this
             WHERE {
                 ?this rdfs:label ?label .
                 FILTER (lang(?label) != "en")
             }""" ;
         shjs:jsonld """
                 (JavaScript code that finds all sub-properties of 
rdfs:label
                 and checks that all values of those are in english)
              """ ;
     ] .

This demonstrates that each language may have its own way of dealing 
with entailments. Each executable snippet (sh:sparql or shjs:jsonld) can 
do whatever it likes, and even if sh:sparql relied on triple-level RDFS 
entailment, JavaScript does not need to rely on that, and can walk 
through sub-properties manually. If JavaScript code indeed relied on 
entailments, then this should IMHO be specified using something like 
shjs:jsonldEntailment.

I hope this clarifies it.

Thanks,
Holger

[1] http://w3c.github.io/data-shapes/shacl/#sparql-entailment

Received on Monday, 25 May 2015 00:02:01 UTC