- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 17 Dec 2014 19:21:57 -0500
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-12-07 16:30-0800]
> Summary: ShEx doesn't provide qualified cardinality restrictions
>
> On 12/06/2014 01:28 AM, Eric Prud'hommeaux wrote:
> >* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-12-05 15:57-0800]
> >>Even if shape constraints on the same property are supposed to be
> >>unioned, I don't think that this provides qualified cardinality
> >>constraints.
> >>
> >>A qualified cardinality constraint is something like
> >>
> >>HappyParent <= [2-4] child Professional |
> >> [2-3] child (exists spouse)
> >
> >I wrote up this example below.
> >
> >>meaning that a happy parent either has between two and four children
> >>who belong to the class Professional or has between two and three
> >>children who have a spouse.
> >>
> >>This is different from having between two and four children and all
> >>of their children belonging to Professional OR having between two
> >>and three children and all of their children having a spouse.
> >
> >There are certainly multiple ways to interpret it;
>
> Umm. What I provided *is* the way that qualified cardinality
> restrictions are defined.
That was not intuitive to me from the syntax. I'd expect
[[
HappyParent <= [2-4] child Professional ∧ # ← note, not an '|'
[2-3] child (exists spouse)
]]
to be a simple example of a qualified cardinality constraint. Does the
'|' match anyone with (2-4 professional kids) inor (2-3 married kids)?
> >we just need to
> >find one which optimizes for some weighting of utility, generality
> >and intuitiveness.
>
> It is certainly possible to define other things, and they may
> perhaps be of more utility or intuitiveness, but they wouldn't
> necessarily cover qualified cardinality restrictions.
>
>
> >Let's start by assuming we want general algebraics
> >like ((N | (G & F)) & M)
> >
> >[[
> > <UserShape> { # A User has
> > (foaf:name xsd:string # either a foaf:name
> > | foaf:givenName xsd:string+, # or 1+ givenNames
> > foaf:familyName xsd:string), # and a family name
> > foaf:mbox IRI # and an mbox.
> > }
> >]]
> >
> >[[
> > PREFIX rs:<http://open-services.net/ns/core#>
> > PREFIX se:<http://www.w3.org/2013/ShEx/Definition#>
> >
> > <UserShape> a rs:ResourceShape ; # A User has
> > se:choice [
> > rs:property [ # either a foaf:name
> > rs:name "name" ;
> > rs:propertyDefinition foaf:name ;
> > rs:valueType xsd:string ;
> > rs:occurs rs:Exactly-one ;
> > ] ;
> > se:ruleGroup [
> > rs:property [ # or 1+ givenNames
> > rs:name "givenName" ;
> > rs:propertyDefinition foaf:givenName ;
> > rs:valueType xsd:string ;
> > rs:occurs rs:One-or-many ;
> > ] ;
> > rs:property [ # and a family name
> > rs:name "familyName" ;
> > rs:propertyDefinition foaf:familyName ;
> > rs:valueType xsd:string ;
> > rs:occurs rs:Exactly-one ;
> > ] ;
> > ] ;
> > ] ;
> > rs:property [ # and an mbox.
> > rs:name "mbox" ;
> > rs:propertyDefinition foaf:mbox ;
> > rs:valueType rs:Resource ;
> > rs:occurs rs:Exactly-one ;
> > ] .
> >]]
> >
> >If we have that, then also interpreting
> >
> > ex:child @<IsProfessional>{2,4},
> > ex:child @<HasSpouse>{2,3}
> >
> >as a disjunction is redundant against
> >
> > ex:child @<IsProfessional>{2,4} |
> > ex:child @<HasSpouse>{2,3}
>
> Well, sure, if there are general algebraics, then uniformly
> interpreting top-level sequences as conjunction is the way to go.
Well we already have AND. There are plenty of use cases motivating OR
(e.g. a foaf:name OR a foaf:givenName and a foaf:familyName).
> >. So what do we do with two rules with overlapping predicates? If we
> >want simplicity, we can say "don't do that".
>
> I don't think that that would gain simplicity at all. If you allow
> the use of named shapes, then forbidding overlapping predicates
> would become intuitive.
I'm confused. How would named shapes relate?
I should also clarify "if we want to make our lives simpler, we can
prohibit overlapping shapes." But maybe you believe that wouldn't make
our life easier. I don't believe that ruling things out of
expressivity can be motivated by making the users' life easier; if
they needed the feature, then removing it from them won't simplify
their user experience.
> >If we want to meet more
> >use cases, we can say that they are QCRs.
> >
> >
> ><http://w3.org/brief/NDIz> models your happy parent example:
> >
> > <HappyParent> {
> > ex:child { a (ex:Professional) }{2,4}
> > | ex:child { ex:spouse .+ }{2,3}
> > }
>
> Does it? My understanding is that the meaning this would be either
> between 2 and 4 children and all children are professionals OR
> between two and 3 children and all children have a spouse. This is
> not qualified cardinality restrictions.
Hmm, I was confused about why you chose this as an example of a QCR so
perhaps I don't understand what the '|' meant.
> >
> >In the validation messages (green-blue box), we see that <Bif> isn't a
> >happy parent 'cause he has too many kids.
>
> Sure, <Bob> ex:child [ a ex:Professional ], [ a ex:Professional ], [
> a ex:Student ].
> also satisfies the qualified cardinality restriction, but not the ShEx shape.
Well, I did say that overlapping predicates produce QCRs plus an all
values from on the union of the object constraints. I wouldn't expect
the above data to match (with UNA/CWA)
[[
<X>
rdfs:subClassOf
# 2 kids of type Professional
[ owl:onProperty ex:child ;
owl:cardinality 2 ;
owl:allValuesFrom
[ rdfs:subClassOf
[ owl:onProperty rdf:type ;
owl:cardinality 1 ;
owl:hasValue ex:Professional ] ] ],
# 2 married kids
[ owl:onProperty ex:child ;
owl:cardinality 2 ;
owl:allValuesFrom
[ rdfs:subClassOf
[ owl:onProperty ex:spouse ;
owl:cardinality 1 ] ] ],
# the promised UNION
[ owl:onProperty ex:child ;
owl:allValuesFrom
[ owl:unionOf (
[ rdfs:subClassOf
[ owl:onProperty rdf:type ;
owl:cardinality 1 ;
owl:hasValue ex:Professional ] ]
[ rdfs:subClassOf
[ owl:onProperty ex:spouse ;
owl:cardinality 1 ] ] ) ] ] .
]]
'cause [ a ex:Student ] isn't in the UNION
> >
> >Note also that the '|' in ShExC (se:choice in the RDF represention) is
> >*exclusive* like in XML Schema (or DTDs). That's another design choice
> >or another email.
> >
> >
> >>peter
> >>
> >>
>
> peter
>
> >>On 12/05/2014 01:53 PM, Eric Prud'hommeaux wrote:
> >>>* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-12-05 10:18-0800]
> >>>>Do ShEx or ShExC or Shape Expressions actually have qualified cardinalities?
> >>>>
> >>>>http://www.w3.org/Submission/shex-defn/ appears to indicate that a
> >>>>shape expression of the form <p1> @<foo> ? only matches when there
> >>>>are zero or one p1's *and* all of the p1's belong to foo.
> >>>
> >>>When drafting the Submission, the intent was to respect only
> >>>unqualified cardinalities (though arbitrary cardinalities, not just 0
> >>>or 1): <http://www.w3.org/Submission/shex-defn/#x1-9002x1>. It wasn't
> >>>until the F2F that I got the idea that intent for Resource Shapes was
> >>>that multiple rules about a particular predicate to be unioned.
> >>>
> >>>
> >>>>peter
> >>>>
> >>>>
> >>>>On 12/05/2014 07:39 AM, Eric Prud'hommeaux wrote:
> >>>>>* Holger Knublauch <holger@topquadrant.com> [2014-12-05 08:29+1000]
> >>>>>>On 12/5/2014 5:08, Arthur Ryman wrote:
> >>>>>>>All values must satisfy the shape pointed to by oslc:valueShape.
> >>>>>>>OSLC has no way to specify that some values must satisfy the
> >>>>>>>shape.
> >>>>>>
> >>>>>>Ok thanks Arthur for clarifying this. So Resource Shapes doesn't
> >>>>>>seem to have a notion of Qualified Cardinalities, while ShEx seems
> >>>>>>to have that (correct me if I am wrong, Eric).
> >>>>>
> >>>>>Yes, hmm, I guess. The story is this: I wasn't sure what the Resource
> >>>>>Shapes semantics were so I documented my best guess in the ShEx
> >>>>>Submission. I conservatively assumed that for any given shape, only
> >>>>>one oslc:Property could have a given oscl:propertyDefinition. The
> >>>>>Lille folks called this "single occurance" (Iovka, correct me if I'm
> >>>>>wrong). The semantics for ShExC were intended to expand Resource
> >>>>>Shapes in a few ways, but I'd intended to respect "single occurance".
> >>>>>
> >>>>>During the F2F, I asked what happens if more than one oslc:Property
> >>>>>has the same oslc:propertyDefinition and I recall Arthur saying that
> >>>>>all of the definitions would be permitted. I was kind of psyched
> >>>>>because it allowed me to meet a bunch of use cases around generic
> >>>>>containers. In OWL, these end up looking like QCRs which on their own
> >>>>>don't really help validation because nothing is invalid.
> >>>>>
> >>>>>In a closed world, one says "if I haven't explicitly allowed it, it's
> >>>>>not allowed." This makes QCRs useful again because something like
> >>>>>
> >>>>>ShExC:
> >>>>> <X> { <p1> @<Foo>? , <p1> @<Bar>* }
> >>>>>
> >>>>>Resource Shapes:
> >>>>> <X> a rs:ResourceShape ;
> >>>>> rs:property [
> >>>>> rs:name "<p1>" ;
> >>>>> rs:propertyDefinition <p1> ;
> >>>>> rs:valueShape <Foo> ;
> >>>>> rs:occurs rs:Zero-or-one ;
> >>>>> ] ;
> >>>>> rs:property [
> >>>>> rs:name "<p1>" ;
> >>>>> rs:propertyDefinition <p1> ; # <-- same property
> >>>>> rs:valueShape <Bar> ;
> >>>>> rs:occurs rs:Zero-or-many ;
> >>>>> ] .
> >>>>>
> >>>>>can mean "any <p1> that's neither a <Foo> nor a <Bar> is invalid."
> >>>>>I had assumed from what Arthur said during the F2F that this was his
> >>>>>intention, but we may have misunderstood each other.
> >>>>>
> >>>>>This introduces complexity but it opens up a lot of use cases where
> >>>>>folks have used generic properties or generic containers. It might
> >>>>>be worth the work.
> >>>>>
> >>>>>
> >>>>>>To create a solution that covers all use cases I believe it would be
> >>>>>>helpful to (explicitly) distinguish between
> >>>>>>
> >>>>>>a) structural declarations "which properties are relevant for a
> >>>>>>resource/class"
> >>>>>>b) arbitrary constraints "which additional conditions must be met"
> >>>>>>
> >>>>>>The information from a) would be easy to interpret to drive user
> >>>>>>interfaces, e.g. it would contain the general cardinality and the
> >>>>>>valueType so that suitable input widgets can be selected.
> >>>>>>
> >>>>>>The information from b) would be tested in the background, e.g. to
> >>>>>>validate an input form before it gets submitted.
> >>>>>>
> >>>>>>With this categorization, oslc:valueType would be a single value in
> >>>>>>category a) while there can be any number of valueShapes in category
> >>>>>>b).
> >>>>>>
> >>>>>>In my current prototyping, I have split spin:constraint into two
> >>>>>>different properties (:property and :constraint) to distinguish
> >>>>>>between those two categories. This also means that there would be
> >>>>>>something like
> >>>>>
> >>>>>(Holger's later text from
> >>>>> <http://www.w3.org/mid/54817076.2060803@topquadrant.com> is prefixed
> >>>>> with '+'s inline)
> >>>>>
> >>>>>>ex:Person
> >>>>>> :property [
> >>>>>> :predicate ex:parent ;
> >>>>>> :valueType ex:Person ;
> >>>>>> :minCount 2 ;
> >>>>>> :maxCount 2 ;
> >>>>>> ] ;
> >>>>>> :constraint [
> >>>>>> a :ShapeConstraint ;
> >>>>>+ :predicate ex:parent ;
> >>>>>> :shape ex:MalePerson ;
> >>>>>> :minCount 1 ;
> >>>>>> :maxCount 1 ;
> >>>>>> ] ;
> >>>>>> :constraint [
> >>>>>> a :ShapeConstraint ;
> >>>>>+ :predicate ex:parent ;
> >>>>>> :shape ex:FemalePerson ;
> >>>>>> :minCount 1 ;
> >>>>>> :maxCount 1 ;
> >>>>>> ] ;
> >>>>>>
> >>>>>>which means that every Person must have two (biological) parents,
> >>>>>>one male and one female. This distinction between the "global"
> >>>>>>cardinality of 2 from the local qualified cardinalities would allow
> >>>>>>us to represent QCRs in a relatively clean way.
> >>>>>>
> >>>>>>Eric, what do you think?
> >>>>>
> >>>>>That's effectively what I've implemented, with the added constraint
> >>>>>that any ex:parent that's neither an ex:MalePerson nor ex:FemalePerson
> >>>>>is invalid. <http://w3.org/brief/NDIy> If you change one of the
> >>>>>genders, it'll whine. If you plan to do much editing, unclick ☑
> >>>>>colorized (if you don't want to play "where's my cursor?").
> >>>>>
> >>>>>
> >>>>>>Holger
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >
--
-ericP
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Received on Thursday, 18 December 2014 00:22:08 UTC