Re: ISSUE-133 syntax simplifications & regularizations

I also do not want to re-open the rdfs inferencing issue on the data graph
For the shapes graph things are more in our control  but I think it is
still problematic when one uses the same graph for shapes and data.

If this continues to be a problem I would be also fine to force the
explicit typing of each constraint in the spec and make implementations
more lenient on this

On Wed, May 11, 2016 at 4:15 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:

>
>
> 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
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT