dbooth-boston
commented
2 months ago To help drive discussion, I'm listing here some options, with pros/cons. Are there others I should add?
Option 1: Omit rdf:first elements from an RDF list ladder
This DICOM JSON:
"Value": [ "bar", null, "foo" ]would be this in Turtle:
[ rdf:first "bar" ;
rdf:rest [ # Note no rdf:first here
rdf:rest [ rdf:first "foo" ;
rdf:rest rdf:nil
]
] .
]PROS:
- Compact
CONS:
- Cannot use concise Turtle list notation ( "bar" ____ "foo" )
- Some would consider this a malformed RDF list.
Option 2: Use an RDF Sequence with a missing qlement
This DICOM JSON:
"Value": [ "bar", null, "foo" ]would be this in Turtle:
rdf:type rdf:Seq ;
rdf:_1 "1" ;
### Note no rdf:_2 triple here
rdf:_3 "3" .PROS:
- Compact
CONS:
- Cannot use concise Turtle list notation ( "bar" ____ "foo" )
- RDF sequences do not seem to be well accepted by the community
Option 3: Use a distinguished fhir:null value to represent null.
This DICOM JSON:
"Value": [ "bar", null, "foo" ]would be this in Turtle:
( "bar" fhir:null "foo" )PROS:
- Compact
- Concise Turtle list syntax can be used.
CONS:
- If _myList is expected to be all integers or floats, having a fhir:null value in the list might cause processing difficulties.
Option 4: Use explicit fhir:indexes , like in FHIR RDF R4
This DICOM JSON:
"Value": [ "bar", null, "foo" ]would be this in Turtle:
... [ [ fhir:v "bar ; fhir:index 0 ] ;
### Note no element with fhir:index 1
[ fhir:v "foo ; fhir:index 2 ] ;
PROS:
- Easy to query all elements and their indexes
CONS:
- Less concise
- No syntactic sugar for it
JervenBolleman
ebremer
gaurav
ericprud
Copying this issue description from Erich Bremer's email.
From: Erich Bremer Date: Mon, 25 Mar 2024 11:22:24 -0400
Let me re-state the two problems that I feel need to be resolved as far as I see in having a DICOM RDF for those not part of the original conversation.
For reference, here is a snippet of DICOM compliant JSON: { "00020002": { "vr": "UI", "Value": [ "1.2.840.10008.5.1.4.1.1.12.1"]}, "00020003": {"vr": "UI", "Value": ["1.3.12.2.1107.5.4.3.321890.19960124.162922.29"]}, "00020010": { "vr": "UI", "Value": ["1.2.840.10008.1.2.4.50"]}, "00020012": { "vr": "DS", "Value": [ "999.999"]}, ...
1) DICOM requires the "vr" property: https://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_F.2.3.html 2) DICOM handle value multiplicity by putting all values in ordered arrays: https://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_F.2.4.html 3) If an attribute is present but the missing (value length is 0), DICOM says leave off the "value" property but the rest must be there. https://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_F.2.5.html 4) For null entries in the arrays, DICOM says put null for that list element as the position itself may/may not be important.
Now to RDF ** a) It's easy to handle 1+2+3 with RDF using a blank nodes and RDF Lists:
[ dcm:00020002 [ dcm:vr: "UI", dcm:Value ("1.2.840.10008.5.1.4.1.1.12.1") ]; dcm:00020003 [ dcm:vr "UI", dcm:Value ("1.3.12.2.1107.5.4.3.321890.19960124.162922.29")]; dcm:00020010 [ dcm:vr: "UI", dcm:Value ("1.2.840.10008.1.2.4.50")]; dcm:00020012 [ dcm:vr: "DS", dcm:Value ( "999.999")]; ...
The problem arises with 4 - nulls
For 3, we leave off the dcm:Value triple as "null maps to no triple". The problem is in the RDF Lists.
( "1" "2" "3") is short-hand for: _:myList rdf:first "1" ; rdf:rest [ rdf:first "2" ; rdf:rest [ rdf:first "3" ; rdf:rest rdf:nil ] ] .
Following "no triple asserted is null", if I wanted to leave the second element out of the list, I would just remove rdf:first "2". No triplestore that I know would complain. I can SPARQL using the long list version and I can write the SPARQL with an optional {_:SecondPosition rdf:first ?second } or even a minus {}. In this fashion, the positional information is preserved as needed by elements like https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.11.7.html#table_C.8-74f or pixel spacing https://dicom.innolitics.com/ciods/rt-dose/image-plane/00280030 and would return an unbound value depending on the data.
This path falls apart as there is no support (an implicit rdf:first must always be present) for the missing rdf:first triple in the second position for the shorthand ( "1" "2" "3"). I can put a variable ( "1" ?second "3", but I cannot say the equivalent of ( "1" optional { ?second} "3") or even ( "1" minus { ?second} "3") JSON-LD will simply remove the second element if I say ( "1" null "3") with the thought that null is no triple asserted. But this stance is not the same as removing the rdf:first triple, it's removing multiple triples [ rdf:first "2" ; rdf:rest[] ] and then pointing :first to :third which takes out the positional information and changing the meaning of things as DICOM views their data. RDF List is a container construct with triples that express the various positions and relations and the associated positional values. What would be wrong (who would be put out) if we allow something that is already allowable in the RDF model? Honestly, I feel like RDF is not following its own rules here and needs to be fixed even with DICOM out of the picture. The same, I feel, applies to RDF Sequence containers:
ex:mySequence rdf:type rdf:Seq ; rdf:_1 "1" ; rdf:_2 "2" ; rdf:_3 "3" .
If I omitted rdf:_2, it should just now be: ex:mySequence rdf:type rdf:Seq ; rdf:_1 "1" ; rdf:_3 "3" .
If the current logic of RDF lists is applied it would become the below which is not the same: ex:mySequence rdf:type rdf:Seq ; rdf:_1 "1" ; rdf:_2 "3" .
Keeping the positional triples in RDF Lists and sequences seems to be an easier fix than introducing some type of null literal or typed "null"^^xsd:integer but it seems to be an implicit taboo due to the lack of the support in the syntactic sugar for lists and how JSON-LD compaction behaves with nulls. I appreciate and I think I understand the thinking of the elements as part of the schema, but it seems to be heading to more complex territory. RDF would allow us to deviate further from the DICOM JSON through using things like custom data types to reduce the number of triples: [ dcm:00020002 ("1.2.840.10008.5.1.4.1.1.12.1"^^dcm:UI); dcm:00020003 ("1.3.12.2.1107.5.4.3.321890.19960124.162922.29" ^^dcm:UI ); dcm:00020010 ("1.2.840.10008.1.2.4.50" ^^dcm:UI ); dcm:00020012 ( "999.999"^^dcm:DS); ... and even remove lists where DICOM value multiplicity is always 1 but it makes things a bit more complicated. I think a DICOM RDF needs to be very much bi-directional and keeping towards the DICOM JSON modeling makes it more familiar for the people in the DICOM domain. It reduces the tooling on both sides. Nothing stops a RDF person from making SPARQL update transforms to mutate the data back and forth to a different design (perhaps more performant) but I fear great becomes the enemy of the good. "a little semantics goes a long way" - Erich