W3C home > Mailing lists > Public > public-shex-dev@w3.org > March 2016

working out ShExMap algorithm

From: Eric Prud'hommeaux <eric@w3.org>
Date: Tue, 1 Mar 2016 05:54:54 -0500
To: public-shex-dev@w3.org
Cc: Iovka Boneva <iovka.boneva@univ-lille1.fr>
Message-ID: <20160301105452.GB19144@w3.org>
I've been using ShExMap by instantiating a target shape exactly once
for every match of a source shape. This keeps the variable bindings
1:1 but requires breaking n-ary connections in the schema
(i.e. removing property constraints). Specifically, I had a source
patient record that had n observations (say blood pressures). I needed
to create a target patient record with no refs to observations, and n
target observation records which had links back to the patient.

<idealSourcePatient> {
  :name LITERAL %map:{ x:patientName %},
  :id LITERAL %map:{ x:patientId %},
  :obs @<idealObsShape>
}

<idealObsShape> {
  :code LITERAL %map:{ x:obscode %},
  :value LITERAL %map:{ x:value %}
}

I ended up breaking the ref to obs:

<modifiedSourcePatient> {
  :name LITERAL %map:{ x:patientName %},
  :id LITERAL %map:{ x:patientId %},
}

and adding an inverse obs to get back to the patient ID which I needed
to materialize the target observations:

<idealObsShape> {
  ^obs { :id LITERAL %map:{ x:patientId %} },
  :code LITERAL %map:{ x:obscode %},
  :value LITERAL %map:{ x:value %}
}

I described this in <http://shex.io/extensions/Map/#Multiplicity> and
I'm looking for collaboration on how to not:

  1 break n-ary links like :obs
  2 instatiate the mapping function n times for n observations but
    instead once for the patient record.

thoughts?
-- 
-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 Tuesday, 1 March 2016 10:55:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 11:00:16 UTC