Re: ISSUE-133 syntax simplifications & regularizations

On 5/10/16 4:44 PM, Holger Knublauch wrote:
>
>
> 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
>

I understood the reason for not doing domain and range inferencing 
wasn't the difficulty but that it means having access to the vocabulary 
namespace, and it was that aspect that complicated things. This would 
mean working with (at least) three graphs: shapes graph, data graph, 
vocabulary graph. That's the same reason why rdf:type declarations must 
be inline in the data graph - it's not that rdf:type is hard, it's that 
we didn't want to add the "go fetch vocabulary and add triples for 
domains and ranges" to SHACL. That could, of course, be a step that an 
application takes before engaging SHACL validation.

kc



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 11 May 2016 01:15:31 UTC