W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

Re: ISSUE-133 syntax simplifications & regularizations

From: Holger Knublauch <holger@topquadrant.com>
Date: Wed, 11 May 2016 08:58:15 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <cb1146e2-0e5f-b2e6-9b0b-fd852ebcb3d0@topquadrant.com>
On 11/05/2016 6:51, Peter F. Patel-Schneider wrote:
>
> On 05/10/2016 01:16 PM, Dimitris Kontokostas wrote:
>>
>> On Tue, May 10, 2016 at 6:55 PM, Peter F. Patel-Schneider
>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>
>>      OK, no more sh:defaultValueType.  Good.
>>
>>      How does the syntax of constraints work now?
>>
>>
>>      Can any triples be removed from the following RDF graph without changing
>>      its validation behaviour?  If so, which ones?
>>
>>      @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>      @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>>      @prefix sh: <http://www.w3.org/ns/shacl#> .
>>      @prefix ex: <http://example.com/ns#> .
>>
>>      ex:s1 a sh:Shape ;
>>       sh:scopeClass ex:Foo ;
>>       sh:node [ a sh:NodeConstraint ;
>>                 sh:nodeKind sh:IRI ] ;
>>       sh:property [ a sh:PropertyConstraint ;
>>                     sh:predicate ex:p ;
>>                     sh:class ex:Bar ] .
>>
>>
>> imo this shapes graph is valid and  both type triple can be removed
> If the type triples can be removed then what happens to
> "sh:PropertyConstraint is the class of all property constraints"?   The object
> of sh:property is a property constraint but then doesn't seem to belong to the
> class sh:PropertyConstraint.
>
>>      Does the following RDF graph contain a syntactically-valid SHACL shape?  If
>>      not, why not?
>>
>>      @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>      @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>>      @prefix sh: <http://www.w3.org/ns/shacl#> .
>>      @prefix ex: <http://example.com/ns#> .
>>
>>      ex:NodeConstraint rdfs:subClassOf sh:NodeConstraint .
>>      ex:subClassOf rdfs:subPropertyOf rdfs:subClassOf .
>>      ex:PropertyConstraint ex:subClassOf sh:PropertyConstraint .
>>
>>      ex:s2 a sh:Shape ;
>>       sh:scopeClass ex:Foo ;
>>       sh:node [ a ex:NodeConstraint ;
>>                 sh:nodeKind sh:IRI ] ;
>>       sh:property [ a ex:PropertyConstraint ;
>>                     sh:predicate ex:p ;
>>                     sh:class ex:Bar ] .
>>
>>
>> I think this shapes graph is valid as well but other may correct me if I am
>> wrong but let me explain why first
>>   - I believe  we still need to say that (sh:NodeConstraint,
>> sh:PropertyConstraint, sh:InversePropertyConstraint, sh:SparqlConstraint) are
>> pairwise disjoint.
>>   - As long as the above rule is not violated we are fine
>>   - we do not say that values of sh:node / sh:property must not be instances of
>> other classes only that they must be instances of sh:NodeConstraint /
>> sh:PropertyConstraint, so a shacl engine can assign the proper types even
>> without any inferencing at all
> But determining that the object of sh:property above is an instance of
> sh:PropertyConstraint *is* inferencing!
>
>> if on the other hand you stated
>> ex:PropertyConstraint ex:subClassOf sh:InversePropertyConstraint .
>> this would be problematic but I think we should avoid such (edge) cases
> Without inferencing how could this problem be detected?

I think all of these issues are rather minor problems that can be 
written up. The concept of default value types was providing one 
solution, and if you prefer to call this an "inference" I don't care as 
long as we remain sure that this doesn't mean the same as "RDF 
inferencing". Maybe we should come up with a different term to avoid 
confusion, such as "type derivation" or even "SHACL instance 
classification".

Holger
Received on Tuesday, 10 May 2016 22:58:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC