W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > April 2016

Re: Question on FHIR references - relative and absolute URIs

From: David Booth <david@dbooth.org>
Date: Wed, 27 Apr 2016 09:48:11 -0400
To: tlukasik@exnihilum.com, Robert Hausam <rrhausam@gmail.com>
Cc: Lloyd McKenzie <lloyd@lmckenzie.com>, Grahame Grieve <grahame@healthintersections.com.au>, "its@lists.hl7.org" <its@lists.hl7.org>, w3c semweb HCLS <public-semweb-lifesci@w3.org>
Message-ID: <5720C31B.30000@dbooth.org>
On 04/27/2016 01:33 AM, tlukasik@exnihilum.com wrote:
>  >> "We always had stated that we must be able to get back "the same
> thing"."
> That's true, Rob.. we've always included round-tripability in our
> conversations, but (and again, please correct me if I seem to be missing
> or misunderstanding something), "the same thing" does not always mean
> the same thing.
> It might mean "equality" or it might mean "equivalence". That's the
> reason that we have both an "==" and an "===" operator in many
> programmimg languages.
> So getting back to the original question that David asked and Lloyd
> offered some insight into, it sounds to me like the answer is that
> messing with the URI's might be OK if we're only required to make sure
> that they're "the same thing" in the sense that they're equivalent
> (meaning that "they point to the same thing"), but it wouldn't be OK if
> they have to be "the same thing" in the stricter sense of not altering
> the digital signature.

Right now we essentially have two well-defined interpretations of what 
"the same thing" might mean.  One is "having the same bytes".  That's a 
strict interpretation.  Another is "having the same digital signature". 
  That's looser, but it is still a clear definition that we do not need 
to invent.  If we were to invent a third interpretation that is even 
looser then we would have to clearly define it and describe the problem 
that it is intended to solve.  Such a definition could have some utility 
but I am doubtful that it would be enough to justify the work and the 
confusion that would be added by having one more notion of equivalence.

David Booth

> TJL
>
> ---------------------------- Original Message ----------------------------
> Subject: Re: Question on FHIR references - relative and absolute URIs
> From: "Robert Hausam" <rrhausam@gmail.com>
> Date: Tue, April 26, 2016 11:54 pm
> To: tlukasik@exnihilum.com
> Cc: "David Booth" <david@dbooth.org>
> "Lloyd McKenzie" <lloyd@lmckenzie.com>
> "Grahame Grieve" <grahame@healthintersections.com.au>
> "its@lists.hl7.org" <its@lists.hl7.org>
> "w3c semweb HCLS" <public-semweb-lifesci@w3.org>
> --------------------------------------------------------------------------
>
>  > Right. We always had stated that we must be able to get back "the same
>  > thing". And signature is a means to verify that.
>  >
>  > Rob
>  >
>  > On Tue, Apr 26, 2016 at 6:05 PM, <tlukasik@exnihilum.com> wrote:
>  >
>  >> >> "It has been mentioned before, as a way to clarify what qualifies as
>  >> successful round tripping."
>  >>
>  >> David..
>  >>
>  >> I wasn't doubting that it was ever mentioned. My concern was that we may
>  >> not be keeping the additional challenge that signing introduces in mind
>  >> when evaluating and testing the round tripping of our prototype RDF
>  >> instances.
>  >>
>  >> I think that if we *were* doing that, we would have been aware of what
>  >> Lloyd pointed out, and have been able to answer our own question RE the
>  >> preservation of absolute and relative URIs.
>  >>
>  >> TJL
>  >>
>  >> ---------------------------- Original Message
> ----------------------------
>  >>
>  >> Subject: Re: Question on FHIR references - relative and absolute URIs
>  >>
> From: "David Booth" <david@dbooth.org>
>  >> Date: Tue, April 26, 2016 4:05 pm
>  >> To: tlukasik@exnihilum.com
>  >> Cc: "Lloyd McKenzie" <lloyd@lmckenzie.com>
>  >> "Grahame Grieve" <grahame@healthintersections.com.au>
>  >>
>  >> "its@lists.hl7.org" <its@lists.hl7.org>
>  >> "w3c semweb HCLS" <public-semweb-lifesci@w3.org>
>  >>
> --------------------------------------------------------------------------
>  >>
>  >> > On 04/26/2016 03:44 PM, tlukasik@exnihilum.com wrote:
>  >> >> >> "If we want the RDF to be an equal sibling to xml and JSON then
>  >> >> round tripping needs to be signature safe."
>  >> >> David..
>  >> >> Lloyd's comment points out the need for a significant and non-trivial
>  >> >> "uptick" in the level of care that will have to be taken when
> generating
>  >> >> RDF.
>  >> >> I certainly haven't been to every single FHIR RDF meeting (so please
>  >> >> correct me if I'm wrong), but I don't recall "signature safety" being
>  >> >> discussed much (if at all) when we've discussed aspects of round
>  >> tripping.
>  >> >
>  >> > It has been mentioned before, as a way to clarify what qualifies as
>  >> > successful round tripping. Successful round tripping means getting
> back
>  >> > "the same thing" if you convert from one FHIR serialization to another
>  >> > and back again. But in deciding what we mean by "the same thing" one
>  >> > might not expect something like whitespace differences to count as
>  >> > consequential differences, whereas other changes definitely should be
>  >> > considered important. The digital signature criteria provide a way to
>  >> > arbitrate between important and unimportant differences.
>  >> >
>  >> > David
>  >> >
>  >> >> TJL
>  >> >>
>  >> >> ---------------------------- Original Message
>  >> ----------------------------
>  >> >> Subject: Re: Question on FHIR references - relative and absolute URIs
>  >> >>
>  >>
> From: "Lloyd McKenzie" <lloyd@lmckenzie.com>
>  >> >> Date: Tue, April 26, 2016 3:00 pm
>  >> >> To: "Grahame Grieve" <grahame@healthintersections.com.au>
>  >> >> Cc: "David Booth" <david@dbooth.org>
>  >> >> "its@lists.hl7.org" <its@lists.hl7.org>
>  >> >> "w3c semweb HCLS" <public-semweb-lifesci@w3.org>
>  >> >>
>  >>
> --------------------------------------------------------------------------
>  >> >>
>  >> >> > If we want the RDF to be an equal sibling to xml and JSON then
> round
>  >> >> > tripping needs to be signature safe. At the moment, that means
>  >> retaining
>  >> >> > absolute vs. relative references.
>  >> >> >
>  >> >> > On Tuesday, April 26, 2016, Grahame Grieve <
>  >> >> > grahame@healthintersections.com.au> wrote:
>  >> >> >
>  >> >> >> well, this is tricky. technically, it's not strictly required, but
>  >> >> it's a
>  >> >> >> lossy transform (lossy in both ways, in fact). One of the
>  >> attractions of
>  >> >> >> fhir;reference for me is that you can have an absolute
> reference for
>  >> RDF
>  >> >> >> and preserve the original fhir url
>  >> >> >>
>  >> >> >> Grahame
>  >> >> >>
>  >> >> >>
>  >> >> >> On Wed, Apr 27, 2016 at 3:01 AM, David Booth <david@dbooth.org
>  >> >> >> <javascript:_e(%7B%7D,'cvml','david@dbooth.org');>> wrote:
>  >> >> >>
>  >> >> >>> Grahame and/or Lloyd,
>  >> >> >>>
>  >> >> >>> In today's FHIR RDF teleconference, a question came up about
>  >> >> relative and
>  >> >> >>> absolute URIs in FHIR references.
>  >> >> >>>
>  >> >> >>> Must absolute and relative references be round tripped as is?
> I.e.,
>  >> do
>  >> >> >>> we need to maintain the distinction between relative and absolute
>  >> >> >>> references when round tripping, or can relative URIs be
> turned into
>  >> >> >>> absolute URIs and vice versa?
>  >> >> >>>
>  >> >> >>> I did not see any mention of normalizing references in the
>  >> >> discussion of
>  >> >> >>> Canonical JSON:
>  >> >> >>> https://hl7-fhir.github.io/json.html
>  >> >> >>>
>  >> >> >>> Thanks,
>  >> >> >>> David Booth
>  >> >> >>>
>  >> >> >>>
>  >> >> >>
>  >> >> >>
>  >> >> >> --
>  >> >> >> -----
>  >> >> >> http://www.healthintersections.com.au /
>  >> >> grahame@healthintersections.com.au
>  >> >> >>
> <javascript:_e(%7B%7D,'cvml','grahame@healthintersections.com.au');>
>  >> /
>  >> >> >> +61 411 867 065
>  >> >> >>
>  >> >> >>
>  >> >> >>
>  >> >>
>  >>
> ***********************************************************************************
>  >> >> >> Manage your subscriptions <http://www.HL7.org/listservice> | View
>  >> the
>  >> >> >> archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe
>  >> >> >>
>  >> >> <
>  >>
> http://www.HL7.org/tools/unsubscribe.cfm?email=lloyd@lmckenzie.com&list=its
>  >> >
>  >> >> >> | Terms of use
>  >> >> >> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>  >> >> >>
>  >> >> >
>  >> >> >
>  >> >> > --
>  >> >> >
>  >> >> > *Lloyd McKenzie*, P.Eng.
>  >> >> > Senior Consultant, Information Technology Services
>  >> >> > Gevity Consulting Inc.
>  >> >> >
>  >> >> > E: lmckenzie@gevityinc.com
>  >> >> > M: +1 587-334-1110 <1-587-334-1110>
>  >> >> > W: gevityinc.com
>  >> >> >
>  >> >> >
>  >> >> > *GEVITY**Informatics for a healthier world *
>  >> >> >
>  >> >> > CONFIDENTIALITY – This communication is confidential and for the
>  >> >> exclusive
>  >> >> > use of its intended recipients. If you have received this
>  >> >> communication by
>  >> >> > error, please notify the sender and delete the message without
>  >> copying or
>  >> >> > disclosing it*.*
>  >> >> >
>  >> >> > NOTE: Unless explicitly stated otherwise, the opinions and
> positions
>  >> >> > expressed in this e-mail do not necessarily reflect those of my
>  >> employer,
>  >> >> > my clients nor the organizations with whom I hold governance
> positions
>  >> >> >
>  >> >> >
>  >> >>
>  >>
> ***********************************************************************************
>  >> >> > Manage subscriptions - http://www.HL7.org/listservice
>  >> >> > View archives - http://lists.HL7.org/read/?forum=its
>  >> >> > Unsubscribe -
>  >> >>
>  >>
> http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its
>  >> >> > Terms of use -
>  >> >> http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
>  >> >>
>  >> >
>  >> >
>  >>
> ***********************************************************************************
>  >> > Manage subscriptions - http://www.HL7.org/listservice
>  >> > View archives - http://lists.HL7.org/read/?forum=its
>  >> > Unsubscribe -
>  >>
> http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its
>  >> > Terms of use -
>  >> http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
>  >> >
>  >> >
>  >>
>  >>
>  >>
> ***********************************************************************************
>  >> Manage your subscriptions <http://www.HL7.org/listservice> | View the
>  >> archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe
>  >>
> <http://www.HL7.org/tools/unsubscribe.cfm?email=rrhausam@gmail.com&list=its>
>  >> | Terms of use
>  >> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>  >>
>  >
>  >
>  >
>  > --
>  > Robert Hausam, MD
>  > +1 (801) 949-1556
>  > rrhausam@gmail.com
>  >
>  >
> ***********************************************************************************
>  > Manage subscriptions - http://www.HL7.org/listservice
>  > View archives - http://lists.HL7.org/read/?forum=its
>  > Unsubscribe -
> http://www.HL7.org/tools/unsubscribe.cfm?email=tlukasik@exnihilum.com&list=its
>  > Terms of use -
> http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
>
Received on Wednesday, 27 April 2016 13:48:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:21:57 UTC