- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 1 Nov 2016 11:30:35 +1000
- To: public-data-shapes-wg@w3.org
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 > 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 >>>> >>> >> >> >> >
Received on Tuesday, 1 November 2016 01:31:10 UTC