Re: ISSUE-133 syntax simplifications & regularizations

On 05/10/2016 04:24 PM, Holger Knublauch wrote:
> 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

What is bad about RDFS domain and range inferencing?  Why shouldn't SHACL do
it?  It's not that SHACL doesn't do inferencing already.  It's not that SHACL
doesn't do RDFS inferencing already.  It's not that RDFS domain and range
inferencing is hard.

peter

Received on Tuesday, 10 May 2016 23:38:56 UTC