- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 31 Oct 2016 18:53:57 -0700
- To: public-data-shapes-wg@w3.org
On 10/31/16 6:30 PM, Holger Knublauch wrote: > > > On 1/11/2016 11:16, Karen Coyle wrote: >> >> >> On 10/31/16 4:29 PM, Holger Knublauch wrote: >>> >>> >>> 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 >> >> Are you saying that the examples as edited by Eric that do not have >> targets are invalid SHACL? > > No, I never said this. > > Holger So then I guess I don't see the problem. - kc > > >> If so, then could you give an example of a valid shape with zero targets? >> >> To be more specific, this is the example for 4.2.2: >> >> ex:DatatypeExampleShape >> a sh:Shape ; >> sh:property [ >> sh:predicate ex:age ; >> sh:datatype xsd:integer ; >> ] . >> >> from Eric's version at: >> https://ericprud.github.io/data-shapes/shacl/ >> >> kc >> >>> >>> >>>> >>>> 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 Tuesday, 1 November 2016 01:54:33 UTC