Re: Question on FHIR references - relative and absolute URIs

 >> "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 &ndash; 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

>

>

Received on Wednesday, 27 April 2016 08:19:39 UTC