Re: ISSUE-133 syntax simplifications & regularizations

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.

peter

Received on Tuesday, 10 May 2016 23:29:20 UTC