Re: [FHIR JSON-LD] Different mappings for different nestings?

FYI, just to close the loop on this.  We decided not to use JSON-LD for 
FHIR, because the inability from a single @context to map a JSON element 
to different URIs depending on its place in the JSON object hierarchy 
felt like too big a limitation.  For example, we would want to map to a different URI than in this example 
from Grahame Grieve:

    "person" : {
      "dob" : "1975-01-01",
      "name" : {
       "family" : "Smith",
       "given" : "Joe"
    "organization" : {
       "name" : "Acme"

Thanks very much to those who kindly offered their help in this 
investigation.  FWIW, I think the above capability would be good to put 
on the short list for future enhancements to JSON-LD.

David Booth

On 03/17/2015 02:43 PM, David Booth wrote:
> Hi Josh,
> On 03/17/2015 01:11 PM, Josh Mandel wrote:
>> [ . . . ]
>> I think it would be a mistake to map both
>> <>
>> and
>> <> to
>> "fhir:code".
> I didn't call out that issue in my slides
> but we did discuss it a little on the teleconference.  My thinking is
> that it is definitely not ideal, and it is one of the glitches that
> differentiates what we called the "direct RDF" versus our "ideal RDF".
> But the reason this did not seem to me to be a complete show-stopper is
> that the fhir:code property could be viewed as a super-property that has
> different meanings in different contexts of use.  This is often done in
> RDF anyway, though admittedly it is normally done in cases where the
> grouping of properties into a single super-property is semantically
> sensible, rather than just being a result of the property having the
> same spelling.  An example that EricP gave is that a foaf:name can be
> applied either to a person or an organization, and those are arguably
> semantically different uses.  We wouldn't say that Acme Corporation has
> a family name and a given name, as we would for a person.
> In short, this is definitely an issue to consider when deciding whether
> this approach is acceptable.
> Thanks,
> David Booth

Received on Saturday, 18 April 2015 20:25:39 UTC