- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 1 Nov 2016 09:29:07 +1000
- To: public-data-shapes-wg@w3.org
On 1/11/2016 1:10, Karen Coyle wrote: > > > On 10/31/16 6:46 AM, Dimitris Kontokostas wrote: >> I also feel that the core of Eric's issue is solved but if we go with >> this PR as is, we move from one edge to another. >> However, I also agree that targetNode can be an antipattern that we do >> not want to promote so much with the spec >> (binding shapes with specific nodes in advance) >> >> Maybe we could try a mix of different target schemes as well as some >> examples without targets. >> But we should somehow differentiate the target-based validation with the >> targetless/ShEx validation. > > I, too, think that we should have some examples without targets, but > for a different reason: I have use cases where a simple constraint on > a property is going to be not only sufficient but the only > possibility, either because the data does not specify classes, or > because I cannot know what classes it uses. It would make sense, > though, to actually address this in the document rather than slip it > into examples without an explanation. In those cases we could use sh:targetObjectsOf and/or sh:targetSubjectsOf. We don't have many examples on these properties anyway. Holger > > It does make sense to me that section 4 show examples without targets, > and that could be addressed in the intro to that section by saying > that targets and filters are optional, and that the constraints in the > section work equally well with shapes that contain targets and > filters. This section is about the constraints, and adding targets to > the examples, IMO, complicates the examples and makes them less clear. > (BTW, shapes without targets and filters make more sense than shapes > without constraints, and there are shapes without constraints in the > section on targets which are implied to be complete - I don't think > they are.) > > Note that the definition of shapes is: "A shape provides a set of zero > or more targets, filters, constraints and parameters of constraint > components that specify how a set of nodes from the data graph are > validated against the shape." Although it says "zero or more" there > were previously no examples with "zero" targets and filters. > > kc > >> >> On Mon, Oct 31, 2016 at 2:41 AM, Holger Knublauch >> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: >> >> >> >> On 31/10/2016 17:54, Eric Prud'hommeaux wrote: >> >> * Holger Knublauch <holger@topquadrant.com >> <mailto:holger@topquadrant.com>> [2016-10-31 09:29+1000] >> >> Thanks for your work on the results tables, Eric. I have >> seen your pull >> request but I disagree with deleting the sh:targetXY triples >> from the >> examples. These need to be restored IMHO. >> >> I think this gets to the heart of the issue. In earlier >> discussions, >> several of us said that dedicating a schema to a specific >> dataset is >> an antipattern. targetNode is particularly problematic in tha >> respect >> but even the rest of target* leave open questions. Most of your >> examples use targetClass which requires a specific type arc. >> If the >> data serves multiple purposes (e.g. an ex:SalesContact and an >> ex:User), you need discriminating type arcs for all the roles >> it may >> play. >> >> >> ISSUE-140 originally was about clarifying that *in addition to >> graph-based validation using targets* SHACL engines should support >> an interface to validate individual nodes by other means. Targets >> are part of SHACL. By leaving them out of the examples you may get >> closer to your (controversial) viewpoint, but it doesn't help to >> explain SHACL's graph-based mode of operation. The boxes are labeled >> "shapes graph" and "data graph", so it's fair to assume that these >> are meant to be consistently used as explained. We have various >> sections that explain how the targets are used. It's valuable to >> have consistency, and examples of targets have been requested >> multiple times. >> >> >> Is TopQuadrant's use case addressed by the target* section as it >> stands in my proposal? >> >> >> I don't think your branch has made changes to the target sections >> from the main branch? But yes, the current design addresses the use >> cases that we have for SHACL. >> >> Holger >> >> >> >> >> >> (See https://github.com/w3c/data-shapes/pull/22/files >> <https://github.com/w3c/data-shapes/pull/22/files>) >> >> Holger >> >> >> On 26/10/2016 22:01, Eric Prud'hommeaux wrote: >> >> * Holger Knublauch <holger@topquadrant.com >> <mailto:holger@topquadrant.com>> [2016-10-07 10:59+1000] >> >> We are down to 14 open issues right now, and I am >> keen on making further >> progress. My take is the sooner we have the formal >> list of open issues down, >> the earlier we can focus on the informal issues >> raised from the outside. >> >> ISSUE-140 was last discussed >> >> https://www.w3.org/2016/09/27-shapes-minutes.html#item08 >> <https://www.w3.org/2016/09/27-shapes-minutes.html#item08> >> >> but I have to confess I did not quite understand >> what problem Eric was >> referring to. It seems that Eric was merely pointing >> out that validation can >> be defined independently from specific node >> selection (i.e. target) >> mechanisms. I of course agree with that. Could you >> clarify? >> >> I've forked the spec and gone through about half of the >> examples (up >> to sh:and) and added tabular summaries: >> >> https://ericprud.github.io/data-shapes/shacl/ >> <https://ericprud.github.io/data-shapes/shacl/> >> >> I believe this helps readers and addresses this issue. >> >> >> Ted seemed to request some more detail in the spec >> about how the validation >> of individual nodes is supposed to happen. We >> already have one such >> interface, the sh:hasShape function, which can be >> invoked to trigger the >> validation of a given node against a given shape. We >> have no such interface >> for the case in which only a node is given. But we >> also don't formally >> define how the validation is triggered in the >> general, whole-graph case. We >> could potentially add a function >> sh:validateNode(?node) that validates the >> given node against all shapes with matching targets. >> But then people will >> likely complain that we are adding yet another >> SPARQL implementation >> requirement. Alternatively, Ted, could you clarify >> how else we can meet your >> requirement? >> >> Thanks, >> Holger >> >> >> >> >> On 23/09/2016 10:11, Holger Knublauch wrote: >> >> I had raised >> https://www.w3.org/2014/data-shapes/track/issues/140 >> <https://www.w3.org/2014/data-shapes/track/issues/140> >> myself, >> primarily as a reminder that validation of >> individual nodes should be >> mentioned in the spec. I have meanwhile added a >> sentence which IMHO >> addresses this need. >> >> PROPOSAL: Close ISSUE-140 as addressed by >> https://github.com/w3c/data-shapes/commit/2046305962be7cd47400e7a2b51cd2841dca398c >> <https://github.com/w3c/data-shapes/commit/2046305962be7cd47400e7a2b51cd2841dca398c> >> >> Holger >> >> >> >> >> >> >> >> -- >> 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 Monday, 31 October 2016 23:29:42 UTC