W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

clinical data value set example [Was: Re: question about ShEx values]

From: Eric Prud'hommeaux <eric@w3.org>
Date: Fri, 18 Jul 2014 16:26:51 -0400
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: Jose Emilio Labra Gayo <jelabra@gmail.com>, "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Message-ID: <20140718202649.GA16722@w3.org>
* Eric Prud'hommeaux <eric@w3.org> [2014-07-18 12:50-0400]
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-07-18 05:49-0700]
> > That seems truly bizarre.
> > 
> > Does anyone know whether this is a desired behaviour?
> 
> It was certainly intentional that one be able to specify or verify compliance with value sets. I understand that this a bit of an anathema to OWL but it's the sort of functionality we need to provide if we want RDF to be taken seriously in most industries. For example, a substantial fraction of medical informatics concearns with specification and enforcement of value sets.

I apologize for sounding snippy.

I was suggested that I provide more detail regarding the fact that
*all* utterances of a constrained property must match that property.

One of the goals of Shape Expressions and Resource Shapes is to state
(and verify conformance with) value sets (and, by extension, required
values). Resource Shapes expresses required values and value sets
differently, using oslc:allowedValue and oslc:allowedValues (note the
's') respectively.

  ex: http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#ex_change_req

In Shape Expressions, required values are simply a degenerate form of
value sets, expressed as: (RDF-term). In the common clinical scenario,
one must assert/verify that a lab test be identified by one of a set
of codes and the coding system be LOINC. In ShExC, that looks like:

ra:RheumatoidFactorObservation {
  hl7:Coding {
    dt:CDCoding.code ("30231-5" "14034-3" "13634-1"),
    dt:CDCoding.codeSystem ("2.16.840.1.113883.6.1")
  }
}

The ShEx demo page uses an example state of assigned or unassigned:

  … ex:state (ex:unassigned ex:assigned), …

(presuming that the issues in the interface it's describing could not
yet have proceeded to the coveted ex:resolved state).

Regardless of whether the object is a required value or a member
of a value set, and irrespective of cardinality, the desired user
experience is a message like "you supplied the wrong value". Peter
is (as we'd expect from him) correctly reading the semantics as
saying that any occurance of the predicate must validate (and of
course, the count should match the cardinality constraints). ShEx
expressivity does not include qualified cardinality constraints.


> > peter
> > 
> > 
> > On 07/18/2014 04:28 AM, Jose Emilio Labra Gayo wrote:
> > >Yes. it is.
> > >
> > >I checked it here: http://goo.gl/s5kevB
> > >
> > >Best regards, Jose Labra
> > >
> > >
> > >On Fri, Jul 18, 2014 at 11:33 AM, Peter F. Patel-Schneider
> > ><pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> > >
> > >    I've been trying to dig through the ShEx definition.
> > >
> > >    It appears to me that for
> > >
> > >    <foo>
> > >    { ex:bar1 (ex:val1) ? }
> > >
> > >    with graph
> > >
> > >    ex:a ex:bar1 ex:val1 .
> > >    ex:b ex:bar1 ex:val2 .
> > >
> > >    that ex:a matches <foo> but that ex:b does not.
> > >
> > >    Is this correct?
> > >
> > >    peter
> > >
> > >
> > >
> > >
> > >
> > >--
> > >Saludos, Labra
> > 
> 
> -- 
> -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.

-- 
-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 Friday, 18 July 2014 20:26:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC