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

On Thu, Dec 4, 2014 at 3:16 PM, Eric Prud'hommeaux <eric@w3.org> wrote:

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

Yes, this is the case.
I am not saying that all property range constraints should be global, I
know this cannot work, but some of them could be.


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


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