Re: Proposed RDF FHIR syntax feedback

I'm not sure that I undestand this discussion. Every Fhir structure
defintion and value set (and other definitional resource) already has an
IRI.- it's an inherent part of the design. So the IRI for the structural
definition of patient is http://hl7.org/FHIR/StructureDefinition/Patient.
All valuesets have a clearly defined IRI right in the valueset.

I don't understand why anything else is required. At least in terms of
linked data, I've always thought of FHIR as inherently linked data ready.

Operational data will be more of a challenge. The pseudo authoritative way
that identity is asserted without really thinking it through in most of the
linked data work I see is quickly exposed as wishful thinking for those of
us who deal with production healthcare data with its inherent
slipperiness. Still, we've done what we can - every FHIR resource has an
inherent IRI built right into it (if you know the server). The resource
address doesn't change, even If its not the same as the identity of the
thing it refers to.

So resource.id is the tail of the @id attribute for the resource from
json-ld. ResourceType is the same as @context, and if json-ld could infer
structure deeply, all we'd have to do is add @id (the full id), rename
resourceType to @context, and use the IRI for the resource instead of
its name (which is the tail anyway), then the FHIR format would be json-ld.
Well, if we also produced a json-ld format for the structure defintiion.
That, at least, looks like a fairly straight forward transform I could do
as part of publishing the spec.

However since it appears that json-ld doesn't dive into the type
definitions recursively, it seems as though a @context will be needed at
every level. The IRI for that is obvious too - [root]#path e,g.
Http://hl7.org/fhir/StructureDefinition/Patient#Patient.contact.identifier

Grahame

On Friday, March 6, 2015, Lloyd McKenzie <lloyd@lmckenzie.com> wrote:

> Hi Tony,
>
> I wouldn't treat structure definitions as distinct from any other.  The
> "vs" namespace is just for FHIR-defined valuesets.  There will be 100s of
> value set namespaces out in the real world once more people start
> profiling, so I wouldn't necessarily recommend giving prefixes to any of
> them.  They don't mean anything special.
>
>
> *Lloyd McKenzie*Consultant, Information Technology Services
> Gevity Consulting Inc.
>
>  E: lmckenzie@gevityinc.com
> <javascript:_e(%7B%7D,'cvml','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
>
> On Thu, Mar 5, 2015 at 9:25 AM, Anthony Mallia <amallia@edmondsci.com
> <javascript:_e(%7B%7D,'cvml','amallia@edmondsci.com');>> wrote:
>
>>  Marc,
>>
>> There is probably some right balance between having the prefix state the
>> namespace or to have the dot notation as in FHIR.
>>
>> However there are some base FHIR URIs which might deserve prefixes:
>>
>>
>>
>> http://hl7.org/fhir/structuredefinition/ (when the FHIR website moves
>> there)
>>
>> http://hl7.org/fhir/vs/ which supports the valuesets
>>
>>
>>
>> There may be more in FHIR that I have not yet discovered and Lloyd will
>> know what they are.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Tony
>>
>>
>>
>>
>>
>> *From:* Marc Twagirumukiza [mailto:marc.twagirumukiza@agfa.com
>> <javascript:_e(%7B%7D,'cvml','marc.twagirumukiza@agfa.com');>]
>> *Sent:* Thursday, March 05, 2015 3:42 AM
>> *To:* Lloyd McKenzie
>> *Cc:* David Booth; HL7 ITS; owner-its@lists.hl7.org
>> <javascript:_e(%7B%7D,'cvml','owner-its@lists.hl7.org');>; w3c semweb
>> HCLS
>> *Subject:* Re: Proposed RDF FHIR syntax feedback
>>
>>
>>
>> I fully support having a single "fhir" prefix. This will help at 'FHIR
>> ontology' development level with making reusable predicates.
>> Also at instance level it would help to include something that identifies
>> order for array elements
>> Kind Regards,
>>
>> * Marc Twagirumukiza | Agfa HealthCare*
>> Senior Clinical Researcher | HE/Advanced Clinical Applications Research
>> T  +32 3444 8188 | M  +32 499 713 300
>>
>> http://www.agfahealthcare.com
>> http://blog.agfahealthcare.com
>>  ------------------------------
>>
>> Click on link to read important disclaimer:
>> http://www.agfahealthcare.com/maildisclaimer
>>
>>
>>
>> From:        Lloyd McKenzie <lloyd@lmckenzie.com
>> <javascript:_e(%7B%7D,'cvml','lloyd@lmckenzie.com');>>
>> To:        David Booth <david@dbooth.org
>> <javascript:_e(%7B%7D,'cvml','david@dbooth.org');>>
>> Cc:        w3c semweb HCLS <public-semweb-lifesci@w3.org
>> <javascript:_e(%7B%7D,'cvml','public-semweb-lifesci@w3.org');>>, HL7 ITS
>> <its@lists.hl7.org <javascript:_e(%7B%7D,'cvml','its@lists.hl7.org');>>
>> Date:        04/03/2015 19:33
>> Subject:        Proposed RDF FHIR syntax feedback
>> Sent by:        owner-its@lists.hl7.org
>> <javascript:_e(%7B%7D,'cvml','owner-its@lists.hl7.org');>
>>  ------------------------------
>>
>>
>>
>>
>> Several comments:
>> 1. I'm not clear on the benefit of defining prefixes for every resource
>> and type.  The alternative is a single "fhir" prefix
>> 2. We need to include something in the instances that identifies order
>> for array elements
>> 3. Do we need to declare type everywhere?  Quite often, the type can be
>> inferred from the context and the property name by consulting the
>> resource/data type definition ontology.  Explicitly listing types
>> everywhere adds verbosity to the instances and also adds complexity to the
>> conversion process
>> 4. Not sure why we have nodes underneath "div".  Can't we just have "div"
>> be of type string for our purposes?
>>
>> Additional things to add to our example:
>> - a nested structure (e.g. DiagnosticReport.image)
>> - a reference to an external resource (outside the bundle) and reference
>> to something within the bundle (local, full reference-version independent,
>> full reference-version dependent)
>> - a codeable concept with multiple codings
>> - a coding with version declared
>> - a coding with valueset declared
>> - a coding with code but no system
>> - an instance of identifier
>> - an "id" attribute on an element
>> - a reference to the same id attribute (likely from an extension)
>> - an extension with a simple type
>> - an extension with a complex type
>> - an extension that repeats and has multiple values
>> - an element that is an instance a choice (element name is something[x])
>> - a reference to Questionnaire or one of the other resources that has
>> recursion.  Could just be added to the bundle
>>
>> *Lloyd McKenzie*
>> Consultant, Information Technology Services
>> Gevity Consulting Inc.
>>
>>  E: lmckenzie@gevityinc.com
>> <javascript:_e(%7B%7D,'cvml','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
>>
>>
>> On Tue, Mar 3, 2015 at 12:05 PM, <david@dbooth.org
>> <javascript:_e(%7B%7D,'cvml','david@dbooth.org');>> wrote:
>> David Booth <david@dbooth.org
>> <javascript:_e(%7B%7D,'cvml','david@dbooth.org');>> has invited you to
>> HL7/W3C FHIR RDF & Validation/Translation Task Force
>>
>>
>>
>> ***********************************************************************************
>> Manage subscriptions - http://www.HL7.org/listservice
>> <http://www.hl7.org/listservice>
>> View archives - http://lists.HL7.org/read/?forum=its
>> <http://lists.hl7.org/read/?forum=its>
>> Unsubscribe -
>> http://www.HL7.org/tools/unsubscribe.cfm?email=lloyd@lmckenzie.com&list=its
>> <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
>> <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=marc.twagirumukiza@agfa.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=grahame@healthintersections.com.au&list=its>
> | Terms of use
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>


-- 
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065