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

Re: ISSUE-110: Can we close this?

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Sat, 7 May 2016 15:23:22 +0300
Message-ID: <CA+u4+a2QfZHkUZ5xt7NmuqmS6KTxK=dy7Ka6+rg1BuHt4Tm7HA@mail.gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: Holger Knublauch <holger@topquadrant.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Thanks Peter

On Thu, Apr 28, 2016 at 9:11 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

>
>
> On 04/06/2016 01:07 AM, Holger Knublauch wrote:
> > I believe the recent clean up of sections 2 and 3 have improved the
> situation
> > and clarifies what constraint types can be used under which
> circumstances. I
> > suggest closing this ticket ISSUE-110. The larger question of the
> metamodel
> > remains open as a separate ticket, and I believe we should prune the
> number of
> > necessary tickets.
> >
> > https://www.w3.org/2014/data-shapes/track/issues/110
> >
> > Holger
> >
> >
>
>
> The example that I pointed out as not following the old guidelines has been
> fixed to conform with the old guidelines.
>
> However, the new guidelines in Section 2.3 are poorly stated.
>
> For example, what does it mean for a property constraint to apply to the
> object of triples?  This does not appear to allow sh:minCount in property
> constraints.
>
> What does it mean for a node constraint to apply directly to the focus
> node?
>  In some sense all constraints apply directly to the focus node.
>

I cleaned this up can you take a second look?
I used your feedback from a reply you made to issue-134


> Further on in Section 2.3 it says that sh:constraint cannot share objects
> with
> the other two constraint properties.  This is an unnecessary, and new,
> syntactic restriction.
>

This is indeed stricter than before and might disallow some valid cases but
I think it is necessary
There are cases where a constraint applies on a property constraint and not
on a node constraint or the other way around (e.g. sh:closed, sh:lessThan)
Also, when we mix inverse property constraints with node constraints we
might end up with the issues you had with PCs / IPCs
Finally, there is also the defaultValueType where we will not have a
deterministic way to define the default type for a constraint
For all these reasons we decided it was better to be a little stricter and
avoid future problems


> And then there is the complex constraint, constraint component, and
> constraint
> component parameter setup that Karen has already noticed.


>
> So, 110 can be closed, but there is still lots of work to be done to fix up
> how constraints, constraint components, constraint component parameters,
> and
> the shape-to-constraint properties work and are described.
>
> peter
>
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Saturday, 7 May 2016 12:26:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC