Re: ISSUE-110: Can we close this?

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 13:32:57 UTC