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

Re: ISSUE-110: Can we close this?

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>
Message-ID: <D3538151.9D61D%irene@topquadrant.com>
<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

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