- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 5 Apr 2017 09:58:16 +1000
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, "public-rdf-sha." <public-rdf-shapes@w3.org>
- Message-ID: <1d373182-bf5b-395d-dd19-8dfdabe95a59@topquadrant.com>
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:NodeShapeShapea 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? >> >> 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. > > >> >> 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://rdfunit.aksw.org, >> http://aligned-project.eu >> Homepage: http://aksw.org/DimitrisKontokostas >> <http://aksw.org/DimitrisKontokostas> >> Research Group: AKSW/KILT http://aksw.org/Groups/KILT >> >> >> >> >> -- >> Dimitris Kontokostas >> Department of Computer Science, University of Leipzig & DBpedia >> Association >> Projects: http://dbpedia.org, http://rdfunit.aksw.org, >> http://aligned-project.eu >> Homepage: http://aksw.org/DimitrisKontokostas >> <http://aksw.org/DimitrisKontokostas> >> Research Group: AKSW/KILT http://aksw.org/Groups/KILT > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia > Association > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://aligned-project.eu > Homepage: http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Tuesday, 4 April 2017 23:58:58 UTC