>> "One is "having the same bytes". �That's a strict interpretation.
�Another is "having the same digital signature". That's looser"
�
I'd disagree with that statement, David.
�
To have the same digital signature it would have to have the same
bytes, and in fact if even a single bit is different then it won't produce the
same digital signature.
�
So I don't agree that those are different "definitions" of "the same
thing", or that the digital signature interpretation is "looser".
�
TJL
�
---------------------------- Original Message ----------------------------
Subject: Re: Question on FHIR references - relative and absolute URIs
From: "David Booth" <da...@dbooth.org>
Date: Wed, April 27, 2016 9:48 am
To: tluka...@exnihilum.com
"Robert Hausam" <rrhau...@gmail.com>
Cc: "Lloyd McKenzie" <ll...@lmckenzie.com>
"Grahame Grieve" <grah...@healthintersections.com.au>
"i...@lists.hl7.org" <i...@lists.hl7.org>
"w3c semweb HCLS" <public-semweb-lifesci@w3.org>
--------------------------------------------------------------------------
> On 04/27/2016 01:33 AM, tluka...@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" <rrhau...@gmail.com>
>> Date: Tue, April 26, 2016 11:54 pm
>> To: tluka...@exnihilum.com
>> Cc: "David Booth" <da...@dbooth.org>
>> "Lloyd McKenzie" <ll...@lmckenzie.com>
>> "Grahame Grieve" <grah...@healthintersections.com.au>
>> "i...@lists.hl7.org" <i...@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, <tluka...@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" <da...@dbooth.org>
>> >> Date: Tue, April 26, 2016 4:05 pm
>> >> To: tluka...@exnihilum.com
>> >> Cc: "Lloyd McKenzie" <ll...@lmckenzie.com>
>> >> "Grahame Grieve" <grah...@healthintersections.com.au>
>> >>
>> >> "i...@lists.hl7.org" <i...@lists.hl7.org>
>> >> "w3c semweb HCLS" <public-semweb-lifesci@w3.org>
>> >>
>> --------------------------------------------------------------------------
>> >>
>> >> > On 04/26/2016 03:44 PM, tluka...@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" <ll...@lmckenzie.com>
>> >> >> Date: Tue, April 26, 2016 3:00 pm
>> >> >> To: "Grahame Grieve" <grah...@healthintersections.com.au>
>> >> >> Cc: "David Booth" <da...@dbooth.org>
>> >> >> "i...@lists.hl7.org" <i...@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 <
>> >> >> > grah...@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 <da...@dbooth.org
>> >> >> >> <javascript:_e(%7B%7D,'cvml','da...@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 /
>> >> >> grah...@healthintersections.com.au
>> >> >> >>
>> <javascript:_e(%7B%7D,'cvml','grah...@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=ll...@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: lmcken...@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=tluka...@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=tluka...@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=rrhau...@gmail.com&list=its>
>> >> | Terms of use
>> >> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>> >>
>> >
>> >
>> >
>> > --
>> > Robert Hausam, MD
>> > +1 (801) 949-1556
>> > rrhau...@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=tluka...@exnihilum.com&list=its
>> > Terms of use -
>> http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
>>
>
