Re: ISSUE-133 syntax simplifications & regularizations

On 11/05/2016 9:38, Peter F. Patel-Schneider wrote:
>
> 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.

I thought we had closed that topic long ago. I don't want to reopen it.

Holger

Received on Wednesday, 11 May 2016 00:09:06 UTC