- From: Irene Polikoff <irene@topquadrant.com>
- Date: Sat, 07 May 2016 11:44:30 -0400
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- CC: Holger Knublauch <holger@topquadrant.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
<sh:PropertyConstraint is the class of all property constraints. Property constraints apply on the value of a property on the focus node.> I would say sh:PropertyConstraint is the class of constraints that specify conditions that must be met by the values of a particular property on the focus node. [To me, minCount = 1 can be understood as a condition that there must be at least 1 value for the property.] Or sh:PropertyConstraint is the class of constraints that specify conditions that must be met with respect to triples with the focus node as a subject and a particular property as a predicate. Irene On 5/7/16, 9:32 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote: >The wording in 2.3 is still problematic. From that section: > >sh:PropertyConstraint is the class of all property constraints. Property >constraints apply on the value of a property on the focus node. > >However, sh:minCount does not work this way, as it is about the set of >values >of a property. > >What does it mean to be a class of something? Even the new terminology >section does not help, as it just opens up the question of how a class >represents anything and how nodes can exist independent of any RDF graph. > >How do default value types interact with the terminology section? > > >What I am seeing here is a bunch of attempts to patch up something that >is a >poor design from the start. It is thus no surprise that each attempt only >exposes more and more problems and requires more and more machinery. > > >peter > > >On 05/07/2016 05:23 AM, Dimitris Kontokostas wrote: >> Thanks Peter >> >> On Thu, Apr 28, 2016 at 9:11 AM, Peter F. Patel-Schneider >> <pfpschneider@gmail.com <mailto: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 <http://aligned-project.eu/> >> Homepage:http://aksw.org/DimitrisKontokostas >> Research Group: AKSW/KILT http://aksw.org/Groups/KILT >> >
Received on Saturday, 7 May 2016 16:12:17 UTC