Re: Summary of today's teleconference: JSON-LD and FHIR Ontology requirements

Hi Paul,

I think the question comes down to whether the RDF instance can be
reconstituted exactly as it was from the JSON or XML syntax with no
external information added other than the resource and data type
information.  If it can, then no information is lost when converting RDF to
JSON XML.  If it can't, then information is being lost.  What kind of
information is lost is irrelevant.  If any information is lost, then that
means there's a price paid for conversion from RDF to a different form, and
that's not acceptable.  (That doesn't mean you can't do it, but it wouldn't
be considered a "conformant" FHIR instance.)


Lloyd

--------------------------------------
Lloyd McKenzie

+1-780-993-9501



Note: Unless explicitly stated otherwise, the opinions and positions
expressed in this e-mail do not necessarily reflect those of my clients nor
those of the organizations with whom I hold governance positions.

On Tue, Dec 30, 2014 at 10:17 PM, Paul Knapp <pknapp@pknapp.com> wrote:

> For the first point I think we need to consider why the Data was added,
> which may be what the phrase non-FHIR refers to. If the added information
> is not added content but is markup related then it should be removed as
> part of the conversion to JSON or xml. But if is content data then it
> should be retained when converted.
>
> For the second point, is a system is forwarding content to a reasoner, or
> any other process for that matter, it must consider that it is complete and
> appropriate for the task at hand and so it should proceed. If the reasoner,
> or any other process, finds that content is invalid or insufficient for its
> purposes then it should fail to process.
>
> Paul
>
> Sent from my iPhone
>
> On Dec 30, 2014, at 1:39 PM, Lloyd McKenzie <lloyd@lmckenzie.com> wrote:
>
> Hi David,
>
> I think the answer to the first should be as follows:
> - the extra information would be stripped
> - the original instance would not be considered a conformant FHIR instance
>
> In terms of the second, I think the answer would be the same as for a
> non-RDF instance.  The consumer is allowed to reject the instance, but is
> free to process it.  (And, as always, may choose to store or remove the
> profile tag.)
>
>
> Lloyd
>
>
>
> --------------------------------------
> Lloyd McKenzie
>
> +1-780-993-9501
>
>
>
> Note: Unless explicitly stated otherwise, the opinions and positions
> expressed in this e-mail do not necessarily reflect those of my clients nor
> those of the organizations with whom I hold governance positions.
>
> On Tue, Dec 30, 2014 at 12:33 PM, David Booth <david@dbooth.org> wrote:
>>
>> We might want to record a couple of issues around the points that were
>> raised on today's call, to ensure that we track and address them:
>> [[
>> ISSUE: If non-FHIR data is added to some FHIR RDF data, what should
>> happen to that extra information when converting back to FHIR XML/JSON?
>>
>> ISSUE: How should the FHIR RDF handle instance data that is invalid
>> according to a profile with which it is tagged, given that some recipients
>> may still choose to process that data?  (If it is merely treated as a
>> logical inconsistency by a reasoner then that may interfere with the
>> ability to usefully reason in other ways about the data.)
>> ]]
>>
>> David
>>
>> On 12/30/2014 02:30 PM, David Booth wrote:
>>
>>> On today's teleconference we briefly discussed the potential for using
>>> JSON-LD for FHIR instance data, so that the same serialization could be
>>> processed both as regular JSON and as RDF.  Lloyd believes that if we
>>> able to achieve this merely by the addition of an @context link, then it
>>> could become a part of the standard FHIR JSON serialization.  David
>>> Booth and Scott Marshall offered to investigate the potential use of
>>> JSON-LD for this purpose.  Others are invited also.
>>>
>>> We then discussed draft FHIR ontology requirements (#1 and #3)
>>> http://wiki.hl7.org/index.php?title=FHIR_Ontology_Requirements
>>> There was general agreement about #3 (the need for round tripping), but
>>> discussion about whether to merge #1 and #3, and whether and RDF
>>> representation could be allowed to carry more information than a FHIR
>>> XML/JSON representation.
>>>
>>> There was also discussion about what should happen if FHIR instance data
>>> is tagged with a profile, but that instance data is invalid according to
>>> that profile.  Lloyd remarked that it would be invalid, but a recipient
>>> may nonetheless choose to process it in some way, and this may
>>> complicate the desired treatment in the RDF semantics (rather than
>>> merely being treated as a logical inconsistency).
>>>
>>> David requested specific proposals for wording changes to the draft
>>> requirements, to help speed closure.
>>>
>>> The complete log of the meeting:
>>> http://www.w3.org/2014/12/30-hcls-minutes.html
>>>
>>> Next week Frederik Malfait will review the PhUSE work.
>>>
>>> David Booth
>>>
>>
>> ************************************************************
>> ***********************
>> 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=lloyd@
>> lmckenzie.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=pknapp@pknapp.com&list=its>
> | Terms of use
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>
>