W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > November 2016

Re: ISSUE-140: Suggestion to close

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Mon, 31 Oct 2016 18:16:32 -0700
To: public-data-shapes-wg@w3.org
Message-ID: <33a41298-d4b7-cac2-0c5d-0ca728fe1ef7@kcoyle.net>


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? 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:17:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 November 2016 01:17:08 UTC