- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 31 Oct 2016 08:10:01 -0700
- To: public-data-shapes-wg@w3.org
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. 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 > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Monday, 31 October 2016 15:10:42 UTC