- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 10 Mar 2015 21:50:57 +0100
- To: <public-linked-json@w3.org>
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