- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 16 Feb 2016 09:49:01 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
(I assume Arthur accidentally forgot to copy the WG, so I have brought them back into the thread). On 16/02/2016 3:01, Arthur Ryman wrote: > Holger, > > 1). sh:QCC is an acronym for Qualified Cardinality Constraint which we > use in the spec, so I don't think this is very cryptic. However, I am > open to better names, provided they are appropriate. I disagree with > using the name sh:Partition because a partition is not a single > subset, rather it is a set of mutually disjoint subsets. We could call > each of these subsets a node group, i.e. a partition divided a node > set into disjoint node groups. The the rule for each node group in a > partition would be sh:GroupRule. My English is not as good as yours :) and I was using Partition in the sense of how hard discs are partitioned, and some tools use to display each part as "a partition". This may indeed not be the formally correct term. The term Rule doesn't work for me, because rules have other meaning too. What about sh:PartitionConstraint? > > 2) I disagree that these resources are subclasses of sh:NodeConstraint > but that takes us back into the metamodel discussion. One main > difference is that a sh:QCC resource never reports violations. It is > more similar to a sh:Filter. However it does use the same validators > as sh:NodeConstraint, which is why it is useful to identify the > concept of a node validator. Well yes, they never report violations but the sh:partition constraint uses them to create violations. In your own example, filters never report violations either, yet they consist of constraints (and shapes). My thinking is along the lines that all constraint properties for sh:NodeConstraint also apply to those partition constraints, and putting them into an inheritance makes it natural to reuse their declaration. But you are right, this is related to the metamodel discussion. > > 3 I agree that it might be useful to have different terms for the > allowed min and max size of a node group, but this is a very similar > concept to minCount and maxCount so perhaps we could generalize the > definitions of those rather than duplicate the terms? That feels largely like a matter of taste and I have no strong preference. I do think it's worth bringing in front of the group before finalizing though. Holger > > -- Arthur > > On Thu, Feb 11, 2016 at 7:06 PM, Holger Knublauch > <holger@topquadrant.com> wrote: >> Hi Arthur, >> >> I would suggest to rename the class sh:QCC (which is cryptic) to >> sh:Partition. >> >> I also believe it is simply a subclass of sh:NodeConstraint. >> sh:NodeConstraint already supports all these kinds of constraints such as >> sh:pattern so we don't need to reinvent the wheel here. The only properties >> that are mixed in are sh:minCount and sh:maxCount. I am not sure that >> reusing those property URIs is the right way to go, as they really have a >> different meaning here compared to in property constraints. >> >> To summarize, what about: >> >> sh:partition >> a rdf:Property ; >> rdfs:range rdf:List ; # of sh:Partition >> . >> >> sh:Partition >> a rdfs:Class ; >> rdfs:subClassOf sh:NodeConstraint . >> >> sh:minOccurs >> a rdf:Property ; >> rdfs:domain sh:Partition ; >> rdfs:range xsd:integer . >> >> sh:maxOccurs >> a rdf:Property ; >> rdfs:domain sh:Partition ; >> rdfs:range xsd:integer . >> >> Holger >> >> >> On 11/02/2016 13:31, Arthur Ryman wrote: >>> As we discussed at the last telecon, I've added the sh:partition >>> constraint to resolve ISSUE-92. See [1]. >>> >>> -- Arthur >>> >>> [1] http://w3c.github.io/data-shapes/shacl/#PartitionConstraint >>> >>
Received on Monday, 15 February 2016 23:49:40 UTC