W3C home > Mailing lists > Public > public-linked-json@w3.org > March 2015

RE: [FHIR JSON-LD] How best to handle or avoid blank nodes?

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 10 Mar 2015 21:50:57 +0100
To: <public-linked-json@w3.org>
Message-ID: <014b01d05b73$e8f98e20$baecaa60$@gmx.net>
On 27 Feb 2015 at 22:09, David Booth wrote:
> Hi Markus,
> 
> On 02/27/2015 03:23 AM, Markus Lanthaler wrote:
>> On 26 Feb 2015 at 21:35, David Booth wrote:
>>> On 02/25/2015 10:11 AM, Manu Sporny wrote:
>>>> So, count us in - send the questions to the mailing list and it looks
>>>> like you have multiple community members that would be willing to help out.
>>> 
>>> Thanks Manu (and Markus and Jim and any others)!   Okay, my first
>>> question regards blank nodes.
>>> 
>>> Here is an except of a FHIR JSON data:
>>> 
>>> {
>>>     "dob": "1972-11-30",
>>>     "_dob": {
>>>       "id": "314159",
>>>       "extension": [{
>>>          "url" : "http://example.org/fhir/extensions#text",
>>>          "valueString" : "Easter 1970"
>>>       }]
>>> }
>> 
>> Have you considered expanding dob and _dob to the same URL? Something like:
>> 
>>    {
>>        "@context": {
>>            "@vocab": "http://example/fhir/vocab#",
>>            "xsd": "http://www.w3.org/2001/XMLSchema#",
>>            "dob": { "@type": "xsd:date" },
>>            "_dob": { "@id": "dob", "@type": "@id" },
>>            "extension": { "@container": "@list" }
>>        },
>>        "dob": "1972-11-30",
>>        "_dob": {
>>            "id": "314159",
>>            "extension": [
>>                {
>>                    "url": "http://example.org/fhir/extensions#text",
>>                    "valueString": "Easter 1970"
>>                }
>>            ]
>>        }
>>    }
>> This yields (please note extension is a list):
>> 
>>    _:b0 <http://example/fhir/vocab#dob> "1972-11-
>>    30"^^<http://www.w3.org/2001/XMLSchema#date> . _:b0
>>    <http://example/fhir/vocab#dob> _:b1 . _:b1
>>    <http://example/fhir/vocab#extension> _:b3 . _:b3
>>    <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> _:b2 . _:b3
>>    <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest>
>>    <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> . _:b1
>>    <http://example/fhir/vocab#id> "314159" . _:b2
>>    <http://example/fhir/vocab#url>
>>    "http://example.org/fhir/extensions#text" . _:b2
>>    <http://example/fhir/vocab#valueString> "Easter 1970" .
> 
> Interesting.  No, I had not considered that idea.  It looks like it has
> the advantage of making JSON properties "dob" and "_dob" (the
> extensions) more explicitly connected to each other, because their
> values are now attached to the same RDF property
> <http://example/fhir/vocab#dob>. 

Exactly.. that was my reasoning behind this "proposal".

> But it also has the disadvantage of
> overloading the <http://example/fhir/vocab#dob> property in RDF so that
> its range includes both xsd:date and rdf:List , which would complicate
> RDF inference.

Yes


> I had been thinking that the lack of explicit relationship between "dob"
> and "_dob" properties could be a problem for RDF, but I am now convinced
> that it will not be a problem.  FHIR uses a closed content model, so
> extensions cannot introduce new properties.  This means that all of the
> FHIR properties can be declared in a standard FHIR ontology, including
> the relationship between "dob" and "_dob", like this:
> 
>    fhir:_dob fhir:extends fhir:dob .

Oh OK. I assumed that wouldn't be possible.


>> You can transform these triples back to
>> 
>>    {
>>        "@context": ...
>>        "@graph": [
>>            {
>>                "@id": "_:b0",
>>                "dob": "1972-11-30"m
>>                "_dob": {
>>                    "@id": "_:b1",
>>                    "id": "314159",
>>                    "extension": [
>>                        {
>>                            "@id": "_:b2",
>>                            "url": "http://example.org/fhir/extensions#text",
>>                            "valueString": "Easter 1970"
>>                        }
>>                    ],
>>                }
>>            }
>>        ]
>>    }
>> with the following frame:
>> 
>>    {
>>        "@context": {
>>            "@vocab": "http://example/fhir/vocab#",
>>            "xsd": "http://www.w3.org/2001/XMLSchema#",
>>            "dob": { "@type": "xsd:date" },
>>            "_dob": { "@id": "dob", "@type": "@id" },
>>            "extension": { "@container": "@list" }
>>        },
>>        "dob": {}
>>    }
> 
> Wow, interesting technique!   I didn't realize that the @context could
> un-overload a property like that, when serializing back to JSON-LD.  In

There's a reason why the algorithms look so complex :-)


> general I haven't yet thought much about how to do the serialization
> back to JSON-LD from RDF, except to observe that it looks it will
> require a FHIR-specific JSON-LD serializer.  So it's good to know that a
> technique like that is possible.

Having a FHIR-specific JSON-LD serializer is of course the simplest (but most expensive) solution.


--
Markus Lanthaler
@markuslanthaler
Received on Tuesday, 10 March 2015 20:51:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:44 UTC