Re: ISSUE-140: Suggestion to close

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