- From: Irene Polikoff <irene@topquadrant.com>
- Date: Wed, 5 Apr 2017 14:38:15 -0400
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Holger Knublauch <holger@topquadrant.com>, "public-rdf-sha." <public-rdf-shapes@w3.org>
- Message-Id: <9FAD0604-38C4-4D11-A26B-3444A2BF2253@topquadrant.com>
Do you mean that each shape would have to have a type triple so that in the SHACL for SHACL we could rely on something like:
>>>> shsh:ShapeShape a sh:NodeShape ;
>>>> sh:property [
>>>> sh:path sh:node ;
>>>> sh:class sh:NodeShape ;
>>>> ] ;
I thought about it as well, but we have lists and logical expressions, etc.
It is highly unlikely one would want to write
sh:or (
[ a sh:NodeShape ; sh:datatype xsd:string ]
[ a sh:NodeShape ; sh:datatype rdf:langString ]
)
instead of
sh:or ( [ sh:datatype xsd:string ] [ sh:datatype rdf:langString ] )
We could develop some software to post-process shapes to insert rdf:type triples, but this requires an additional step and additional work.
Probably the most critical case is the recursion in SHACL path expressions. Paths use lists and this means the rdf:type approach would not work there either.
Or did you mean something else?
Irene
> On Apr 5, 2017, at 2:20 PM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
>
>
>
> On Wed, Apr 5, 2017 at 1:58 AM, Holger Knublauch <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
> On 5/04/2017 6:48, Dimitris Kontokostas wrote:
>> Thanks Holger
>>
>> see inline
>>
>> On Tue, Apr 4, 2017 at 6:27 AM, Holger Knublauch <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>> Hi Dimitris,
>>
>>
>> On 4/04/2017 5:35, Dimitris Kontokostas wrote:
>>> Another comment
>>>
>>> there are also a few recursive shapes that by definition are undefined
>>>
>>> shsh:ShapeShape a sh:NodeShape ;
>>> sh:property [
>>> sh:path sh:node ;
>>> sh:node shsh:NodeShapeShape ; # node-node
>>> ] ;
>>> sh:property [
>>> sh:path ( sh:xone [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
>>> sh:node shsh:ShapeShape ; # xone-members-node
>>> ] ;
>>> sh:property [
>>> sh:path sh:not ;
>>> sh:node shsh:ShapeShape ; # not-node
>>> ] ;
>>> sh:property [
>>> sh:path ( sh:and [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
>>> sh:node shsh:ShapeShape ; # and-members-node
>>> ] ;
>>> sh:property [
>>> sh:path sh:property ;
>>> sh:node shsh:PropertyShapeShape ; # property-node
>>> ] ;
>>> .
>>>
>>> shsh:NodeShapeShape a sh:NodeShape ;
>>> sh:node shsh:ShapeShape ;
>>> .
>>>
>>> shsh:PropertyShapeShape a sh:NodeShape ;
>>> sh:node shsh:ShapeShape ;
>>> .
>>>
>>> shsh:PathShape
>>> sh:xone (
>>>
>>> [ sh:nodeKind sh:BlankNode ; # 2.3.1.5 <http://2.3.1.5/>: Zero-or-more path
>>> sh:closed true ;
>>> sh:property [
>>> sh:path sh:zeroOrMorePath ;
>>> sh:node shsh:PathShape ; # multiple similar cases in the same shape
>>> sh:minCount 1 ;
>>> sh:maxCount 1 ;
>>> ]
>>> ]
>>> [ sh:nodeKind sh:BlankNode ; # 2.3.1.3 <http://2.3.1.3/>: Alternative path
>>> sh:closed true ;
>>> sh:property [
>>> sh:path sh:alternativePath ;
>>> sh:node shsh:PathListWithAtLeast2Members ; # multiple similar cases in the same shape
>>> sh:minCount 1 ;
>>> sh:maxCount 1 ;
>>> ]
>>> ]
>>>
>>> shsh:PathListWithAtLeast2Members
>>> a sh:NodeShape ;
>>> sh:node shsh:ListShape ;
>>> sh:property [
>>> sh:path ( [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
>>> sh:node shsh:PathShape ;
>>> ] ;
>>
>> Ok thanks for reminding me of this. I have restructured a few shapes so that they avoid recursion and instead use path operations. I would appreciate if these change could be reviewed as it is easy to get things wrong at this level of complexity - e.g. writing meta-paths to traverse SHACL paths.
>>
>> https://github.com/w3c/data-shapes/commit/0c212df3674924b308223acdfdd78bba6c858eb4 <https://github.com/w3c/data-shapes/commit/0c212df3674924b308223acdfdd78bba6c858eb4>
>>
>> Note that I have avoided recursion by adding sh:targetXY statements, e.g. shsh:NodeShapeShape sh:targetObjectsOf sh:node. This work-arounds does work in our case, but I don't think this is a general design pattern that others can follow to avoid recursion too.
>>
>> Unfortunately this exercise confirms my long-held belief that the current work-around to avoid structural recursion leads to unmaintainable and redundant shape definitions. SHACL users will get negatively surprised by this. I believe we have made a mistake in SHACL by generally making structural recursion undefined. Instead we should have made runtime recursion undefined, i.e. the cases in which the same node is visited twice. We ended up with the current compromise after long long discussions, trying to reconcile a wide spectrum of viewpoints, including Peter's preference to completely disallow recursion.
>>
>> No recursion would be neded at all and the shapes would be much simpler if all the rdf:type statement were in the shacl graph
>
> Could you clarify: which rdf:type triples are you referring to? I
>
> I meant the sh:Shape (+ subclasses triples)
>
>
>>
>>>
>>> On Mon, Apr 3, 2017 at 6:26 PM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de <mailto:kontokostas@informatik.uni-leipzig.de>> wrote:
>>> Thanks Holger,
>>>
>>> Although I didn´t check the actual shapes in detail I have a couple of comments on some annotations
>>> We have the following triple:
>>> shsh: a owl:Ontology ;
>>>
>>> Do we need shsh to be an owl ontology?
>>
>> No, this is not needed. However several tools use the rdf:type owl:Ontology triple to find the graph URI if they find a local file. I see no costs in keeping the owl:Ontology triple.
>>
>> There was quite a discussion for decoupling SHACL from OWL and the spec was recently restrucuted based on that.
>
> The SHACL.ttl file also still has an owl:Ontology triple, and I am not aware that we decided to remove that. Like owl:imports this is IMHO really quite different from other OWL features. It would be better if we would have rdf:Graph and rdf:imports, but in the absence of this what can we do to fix gaps in underlying technologies...
>
> Anyway, as you seem to find this aspect important, I have removed the owl:Ontology and owl:imports triples. Re-running the tests did not indicate any changes in behavior, as expected. The triples were ever only meant as a convenience.
>
> In the shacl.ttl file it is not so irrelevant, it defines classes and properties, here the owl:Ontology can be confusing and since this is a normative document I suggested to be removed
> If the WG feels otherwise feel free to re-insert them .
>
> Thanks,
> Dimitris
>
>>
>>
>>
>>
>>>
>>> Do we also need to import the SHACL vocabulary?
>>> shsh: owl:imports sh: ;
>>> I think we only need a few subclass relations which we could duplicate to make it standalone
>>
>> I think it's a good practice to owl:import the namespace that shapes are about. I have not tested whether this owl:import is necessary.
>>
>> conformance to owl:imports is a SHOULD in the spec. If there is anything needed from that file it should be copied over to the document
>> since triples will be copied, the statement will be also redundant
>
> See above.
>
>>
>>
>>
>>>
>>> I am not sure if this is needed as well, we do not have SHACL-SPARQL constraints
>>> sh:declare [
>>> sh:prefix "shsh" ;
>>> sh:namespace "http://www.w3.org/ns/shacl-shacl# <http://www.w3.org/ns/shacl-shacl#>" ;
>>> ] .
>>
>> These are not needed either, but I believe we should try to establish and support a best practice in which each RDF file that defines a namespace also declares the prefix in a triple-ized form. This will make it easier to avoid clashes in the future and makes prefixes more explicit.
>>
>> I agree on the best practices but only where it makes sense.
>> even if a file defines another ns for shsh, this will have no neffect on this file, even if both files get merged
>
> I think in this case it makes sense to have the prefix declaration, and I will from now on also support this pattern with all other graphs that could be used in SHACL in the future.
>
> Regards,
> Holger
>
>
>
>>
>>
>>
>> Holger
>>
>>
>>
>>
>>>
>>> On Mon, Apr 3, 2017 at 10:45 AM, Holger Knublauch <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>> Thanks, good catch. Fixed.
>>>
>>> Holger
>>>
>>>
>>>
>>> On 3/04/2017 18:34, Olivier Corby wrote:
>>> Hi,
>>>
>>> On 04/03/2017 04:13 AM, Holger Knublauch wrote:
>>> ACTION: Everyone please review the SHACL file above, and/or try it against shape definitions - we should sign this off in the Wednesday meeting so that we can swiftly resubmit the CR request.
>>>
>>>
>>> I think there is a problem with the URIs shsh:PropertyShape and shsh:PropertyShapeShape, they should be the same URI :
>>>
>>>
>>> sh:property [
>>> sh:path sh:property ;
>>> sh:node shsh:PropertyShape ; # property-node
>>> ] ;
>>>
>>>
>>>
>>> shsh:PropertyShapeShape
>>> a sh:NodeShape ;
>>> sh:targetSubjectsOf sh:path ;
>>> sh:node shsh:ShapeShape ;
>>> sh:property [
>>> sh:path sh:path ;
>>> sh:maxCount 1 ; # path-maxCount
>>> sh:minCount 1 ; # PropertyShape-path-minCount
>>> sh:node shsh:PathShape ; # path-node
>>> ] ;
>>>
>>>
>>> The same problem occurs with shsh:NodeShapeShape and shsh:NodeShape
>>>
>>>
>>>
>>> Olivier
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Dimitris Kontokostas
>>> Department of Computer Science, University of Leipzig & DBpedia Association
>>> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
>>> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
>>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
>>>
>>>
>>> --
>>> Dimitris Kontokostas
>>> Department of Computer Science, University of Leipzig & DBpedia Association
>>> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
>>> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
>>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
>>
>>
>>
>> --
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig & DBpedia Association
>> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
>> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
>
>
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
Received on Wednesday, 5 April 2017 18:38:53 UTC