- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Sat, 7 May 2016 15:23:22 +0300
- 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>
- Message-ID: <CA+u4+a2QfZHkUZ5xt7NmuqmS6KTxK=dy7Ka6+rg1BuHt4Tm7HA@mail.gmail.com>
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