dbooth-boston
commented
4 years ago REJECTED: Extension option 1a: Map underscore attributes to non-underscore (non-tree version). See https://github.com/fhircat/fhir_rdf_validator/blob/master/tutorial/FHIRR5.md#primitive-type-and-id-extensions---extensions-option-1-map-underscore-attributes-to-non-underscore
NOTE: This option was eliminated on 9/9/21
Example JSON:
{
"resourceType": "Patient",
"id": "example",
"birthDate": "1974-12-25",
"_birthDate": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/patient-birthTime",
"valueDateTime": "1974-12-25T14:35:45-05:00"
}
]
}
}Corresponding Turtle 1a:
@prefix fhir: <http://hl7.org/fhir/> .
@prefix pt: <http://build.fhir.org/Patient/> .
pt:example a fhir:Patient ;
fhir:Patient.birthDate "1974-12-25" ;
fhir:Patient.birthDate [
fhir:DomainResource.extension _:b1 ;
fhir:DomainResource.extension [
fhir:ordered ( _:b1 ) .
] ;
] ;
fhir:Resource.id "example" ;
fhir:nodeRole "fhir:treeRoot" .
_:b1 fhir:Extension.url "http://hl7.org/fhir/StructureDefinition/patient-birthTime" ;
fhir:Extension.valueDateTime "1974-12-25T14:35:45-05:00" .Pros:
- Allows direct access to primitive value -- no intervening bnode.
- Extensions are attached to the property
foorather than to_fooor something else.
Cons:
- Query for property value returns the wrong number of items.
- When accessing a primitive value, any extension bnodes must be FILTERed out.
- Will make OWL unhappy, because the same property would be both datatype and object type property.
- Uses a non-tree graph to indicate the relative ordering of multiple extensions, thus requiring an explicit bnode
REJECTED: Extension option 1b: Map underscore attributes to non-underscore (tree version). Similar to 1a, but simplified to use a tree structure (to eliminate explicit blank nodes), and to use the same extension structure that R4 used, in addition to directly indicating the primitive value.
NOTE: This option was eliminated on 9/9/21
Turtle 1b:
pt:example a fhir:Patient ;
fhir:Patient.birthDate "1974-12-25" ;
fhir:Patient.birthDate [
fhir:value "1974-12-25"^^xsd:date;
fhir:Element.extension [
fhir:index 0;
fhir:Extension.url [ fhir:value "http://hl7.org/fhir/StructureDefinition/patient-birthTime" ];
fhir:Extension.valueDateTime [ fhir:value "1974-12-25T14:35:45-05:00"^^xsd:dateTime ]
]
];Pros:
- Compatible with R4
- Allows direct access to primitive value -- no intervening bnode.
- Extensions are attached to the property
foorather than to_fooor something else.
Cons:
- Query for property value returns the wrong number of items.
- When accessing a primitive value, any extension bnodes must be FILTERed out.
- Will make OWL unhappy, because the same property would be both datatype and object type property.
gaurav
ericprud
The problem is that when we designed FHIR RDF R4 (the initial version of FHIR RDF), we introduced an extra blank node and fhir:value property on primitive properties. For example, fhir:gender is represented like this:
instead of simply being:
We designed it this way intentionally, because FHIR allows any property to be extended, so the extra blank node provides a place to attach the extension (if needed). (See example below.) However, in the years since that design, after accumulating some practical experience using FHIR RDF, it has become clear that the extra blank node and fhir:value property makes it significantly more difficult to access and query those simple properties, which usually are not extended anyway. In other words, we made every use of a primitive property more difficult, just to accommodate the rare case in which someone wants to add a FHIR extension to it. This violates the general design guidance of making the common use cases easy, and the rare use cases possible. Hence, the point of this issue is to reconsider this design choice, to see if we can make the common use case easy -- without requiring the extra blank node and property -- while still somehow enabling the property to have a FHIR extension if needed.
[Sub-issue: How should modifying extensions be represented? NOTE: Discussion of modifier extensions has now been moved to issue #93 .]
Option 0: Do nothing. Keep the R4 approach of everything being an object property
JSON example of non-modifying extension, from R4:
Turtle equivalent in R4: