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

On Thu, Dec 4, 2014 at 2:37 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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 }+
>   }
>

+1
I also think that something like rdfs:range is needed. Of course we could
rename it to e.g. shapes:propertyRange but the idea is the same.
For this we could optionally re-use the existing ontology definitions or
part of them [1].

Dimitris

[1] http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Jul/0208.html


> 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
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas