Re: ISSUE-133 syntax simplifications & regularizations

On 11/05/2016 9:22, Peter F. Patel-Schneider wrote:
> On 05/10/2016 03:58 PM, Holger Knublauch wrote:
>> 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:
>>>>       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
> SHACL is already inferrring subclass relationships from the transitive
> closure of rdfs:subClassOf and typing from subclass relationships and
> rdf:type triples.  This is RDFS inferencing, and it includes RDF
> inferencing.  Calling it "type derivation" or "SHACL instance
> classification" doesn't make it something else.

Yes it's a subset of RDFS inferencing, but does not include things like 
rdfs:domain and rdfs:range. In other places you complained that we are 
using terms like "instance" and "subclass" although they only mean a 
subset of what they mean in RDFS. Why should we treat the term 
"inferencing" any different?

Holger

Received on Tuesday, 10 May 2016 23:25:28 UTC