- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Wed, 5 Apr 2017 20:20:44 +0200
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: "public-rdf-sha." <public-rdf-shapes@w3.org>
- Message-ID: <CA+u4+a2HjevwJkWOuF7k1MmM0BgL54taC9Of5pTt91uhh4q5fA@mail.gmail.com>
On Wed, Apr 5, 2017 at 1:58 AM, Holger Knublauch <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> > 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: 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: 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/0c212df3674924b308 >> 223acdfdd78bba6c858eb4 >> >> 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> 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#" ; >>>> ] . >>> >>> >> 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> 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 >>> 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 >> >> >> > > > -- > 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 > > > -- 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 Wednesday, 5 April 2017 18:21:59 UTC