Re: Stand-alone Shapes and oslc:valueRange implemented in SPIN

On 12/4/2014 3:57, Eric Prud'hommeaux wrote:
> My understanding from the F2F is that one can provide multiple
> restrictions for a property and they'll be effectively treated as
> qualified cardinality constraints.

FWIW I believe we should not support qualified cardinality constraints 
for this key feature of the language. The same discussion already 
happened in the OWL community years ago. QCRs were left out of OWL 1 but 
then added in OWL 2. Yet there are few people in the world who actually 
use them, and from those only a sub-set has actually understood them. 
Real-world use cases are in our experience very rare. Such scenarios 
only create many follow up questions, e.g. do the multiple instances 
have to be disjoint, and what happens if more property dimensions are 
added (e.g. oslc:range).

> As a concrete example, HL7 RIM reuses a generic collection to capture
> e.g. a patient's given and family name name:
>
> ShExC:
>    start= <NameShape>
>    <NameShape> {
>      dt:COLL.item { err:person-name-family LITERAL },
>      dt:COLL.item { err:person-name-given LITERAL }+
>    }

The above basically states that family name must only be a LITERAL in 
the context of a NameShape. However, I would argue that all family names 
must be LITERALs, so this constraint should be globally enforced on the 
class "Item" (whatever that class is called). I guess if we take this 
out, then it becomes

ShExC:
   start= <NameShape>
   <NameShape> {
     dt:COLL.item { err:person-name-family },
     dt:COLL.item { err:person-name-given }+
   }

Anyway, to me the scenario above sounds very much like a corner case. 
Who would model a person shape like this, with two unrelated records for 
first and last names?!

If we have more common examples, I suggest framing them into a user 
story that we can discuss on the Wiki. The story above does not convince 
me that qualified shapes are needed. There will however always be corner 
cases (and those could be expressed with the fall-back mechanisms 
(SPARQL) instead of being the norm.

Thanks,
Holger

Received on Thursday, 4 December 2014 00:40:47 UTC