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

* Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> [2014-12-04 09:36+0200]
> 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].

I'm guessing from context that we're talking about a property to
globally assert the datatype of the object of some property. Of
course, global assertions won't work where

  1 The property doesn't have a defined range, e.g. dc:creator or
    wikipathways identifiers for chemical complexes (either strings or
    URLs into other databases).

  2 The property has different object constraints depending on where
    it appears i.e. contextual constraints. This shows up a lot in
    date constraints where a medical record requires some sort of date
    and a clinical trial record further requires that to be an interval
    from the beginning of participation in a trial.


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

I've never personally had a need to model anything this way. This
comes out of they come out of big ontologies like O-RIM which use
generic containers.


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

-- 
-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, 4 December 2014 13:16:09 UTC