Re: DICOM RDF: VR "OB or OW"

Hi Detlef,

"And it is not really a good idea to encode the pixel data in base64 and
put it into a string."

Agreed! It could come in handy in some instances, but yeah, not a good idea
in general.  There are some binary representations of RDF ( HDT-RDF, Apache
Jena's that is based on Thrift.  None that are official though).  There is
also interest in binary encodings for SPARQL results (
https://github.com/w3c/sparql-dev/issues/82)  Something to keep in mind.

"And WADO-RS allows us to retrieve the binary data directly."

Weirdly, I was combing through the DICOM specs and apparently the use of
offset and length as BulkDataURI query parameters isn't part of the DICOM
standard, like here in this fragment of DICOM JSON (produced by dcm4che's
dcm2json):

"50003000": {
"vr": "OW",
"BulkDataURI": "file:/mnt/d/dicom/sample/0003.DCM?offset=3264&length=2720"
}

The only official use of offset and length in HTTP is via the HTTP range
request header, but not DICOM.  It appears to be a matter of convention for
the WADO-RS implementations.  It could just as well be expressed as:

"50003000": {
"vr": "OW",
"offset": 3264,
"length": 2720,
"BulkDataURI": "file:/mnt/d/dicom/sample/0003.DCM"
}

Personally, I do like the
"file:/mnt/d/dicom/sample/0003.DCM?offset=3264&length=2720" convention.
The BulkDataURI also doesn't appear in the obligatory array "Value" field,
so the solution to differentiating the binary types may just be to keep the
VR for these field types:

<> dcm:50003000 [ dcm:vr "OW"; dcm:BulkDataURI
<file:/mnt/d/dicom/sample/0003.DCM?offset=3264&length=2720> ] .

dcm4che's dcm2json also produces
:
"7FE00010": {
"vr": "OB",
"DataFragment": [
{ "BulkDataURI": "file:/mnt/d/dicom/sample/0003.DCM?offset=6004&length=68"},
{ "BulkDataURI":
"file:/mnt/d/dicom/sample/0003.DCM?offset=6080&length=36357"},
{ "BulkDataURI":
"file:/mnt/d/dicom/sample/0003.DCM?offset=42445&length=34390"}  ...

which then could be case for an RDF list in this case to:

dcm:7FE00010 [
    dcm:vr "OB",
    dcm:BulkDataURI  (
"file:/mnt/d/dicom/sample/0003.DCM?offset=6004&length=68"
"file:/mnt/d/dicom/sample/0003.DCM?offset=6080&length=36357"
"file:/mnt/d/dicom/sample/0003.DCM?offset=42445&length=34390" )
 ] .

  - Erich

PS  - I also couldn't find an explicit reference to "DataFragment" in
DICOM, but only in dcm4che's dcm2json.
==========================================================
Erich Bremer, M.Sc.
Director, Applied Informatics
Department of Biomedical Informatics
Stony Brook Medicine
Tel. : 1-631-444-3560
Fax  : 1-631-444-8873
Cell : 1-631-681-6228
erich.bremer@stonybrook.edu
Office Location/Mailing Address
HSC, L3: Room 119
Stony Brook, NY 11794-8330



On Wed, Jul 17, 2024 at 5:39 AM Detlef Grittner <detlef.grittner@sohard.de>
wrote:

> Hi Erich,
>
> the VR in question is actually representing a stream of data, which is
> true for the VRs that start with an O, like OB, OW, OD, OF.
> The most common occurrence of OB or OW is actually the attribute Pixel
> Data (7FE0,0010).
> And it is not really a good idea to encode the pixel data in base64 and
> put it into a string.
>
> So for the already discussed DICOM JSON so called BulkDataURIs are
> introduced and these are WADO-RS URLs.
> (https://dicom.nema.org/dicom/2013/output/chtml/part18/sect_F.2.html)
> And WADO-RS allows us to retrieve the binary data directly. It is
> specified as a REST Service in the DICOM standard.
>
> We would need a representation for these "O" VRs that allows us to encode
> BulkDataURIs as well as the so called InlineBinary in RDF.
>
> Detlef
>
> --
> Detlef Grittner, MSc ISM, M.A.
> CTO
>
> SOHARD Software GmbH
> Würzburger Str. 197
> 90766 Fürth
>
> Phone: +49 (0) 911 97341-54
> Fax:   +49 (0) 911 97341-10
> E-Mail: detlef.grittner@sohard.de
>
> Geschäftsführer: Peter Feltens, Sebastian Schnitzenbaumer
> Sitz der Gesellschaft: Fürth
> Registergericht: Amtsgericht Fürth; HRB 11478
>
> On 12.07.24 18:04, Erich Bremer wrote:
>
> Hi Detlef,
>
> Yes, it would prevent us.  I looked through the data elements table
>
> https://dicom.nema.org/medical/dicom/current/output/html/part06.html#table_6-1
>
> and most are singular VR types.  There are quite a few ( US or SS ) but
> resolvable with xsd:short and xsd: unsignedShort.
> But, we have ChannelMinimumValue and ChannelMaximumValue (for example)
> which are both ( OB or OW ).
> We wouldn't have a way of figuring out what the original VR type was even
> with the ontology as it would be
> ambiguous.
>
> Which pushes us back to:
>
> 1) ?s dcm:someProperty [ dcm:vr "OW"; dcm:Value ( " DEADBEEF..."^^
> xsd:base64Binary ) ] .
> or
> 2) ?s dcm:someProperty ( "DEADBEEF..."^^dcm:OW ) .
>
> Perhaps we use the above as a fall back when there is ambiguity?
>
>    - Erich
>
>
> ==========================================================
> Erich Bremer, M.Sc.
> Director, Applied Informatics
> Department of Biomedical Informatics
> Stony Brook Medicine
> Tel. : 1-631-444-3560
> Fax  : 1-631-444-8873
> Cell : 1-631-681-6228
> erich.bremer@stonybrook.edu
> Office Location/Mailing Address
> HSC, L3: Room 119
> Stony Brook, NY 11794-8330
>
>
>
> On Thu, Jul 11, 2024 at 12:46 PM Detlef Grittner <
> detlef.grittner@sohard.de> wrote:
>
>> Hi Erich,
>>
>> I have to come back to this issue of "OB or OW".
>>
>> The VR OB is defined as follows in the DICOM standard:
>> "An octet-stream where the encoding of the contents is specified by the
>> negotiated Transfer Syntax. OB is a VR that is insensitive to byte
>> ordering (see Section 7.3). The octet-stream shall be padded with a
>> single trailing NULL byte value (00H) when necessary to achieve even
>> length."
>>
>> And the VR OW is defined as follows:
>> "A stream of 16-bit words where the encoding of the contents is
>> specified by the negotiated Transfer Syntax. OW is a VR that requires
>> byte swapping within each word when changing byte ordering (see Section
>> 7.3)."
>> (
>> https://dicom.nema.org/medical/dicom/current/output/html/part05.html#sect_6.2
>> )
>>
>> We can resolve the problem of the endianess of OW by strictly using
>> little endian and the DICOM standard supports it: "All nonretired
>> Transfer Syntaxes in DICOM require the use of Little Endian Byte
>> Ordering."
>> (
>> https://dicom.nema.org/medical/dicom/current/output/html/part05.html#sect_7.3
>> )
>>
>> But if we use xsd:base64Binary, we still have the problem if a single
>> value from the stream is a byte (8-Bit) for OB or 2 bytes (16-bit) for OW.
>>
>> Would this prevent us from relying solely on xsd datatypes and DICOM
>> standard/ontology for standard attributes?
>>
>> Regards,
>>
>> Detlef
>>
>> --
>> Detlef Grittner, MSc ISM, M.A.
>> CTO
>>
>> SOHARD Software GmbH
>> Würzburger Str. 197
>> 90766 Fürth
>>
>> Phone: +49 (0) 911 97341-54
>> Fax:   +49 (0) 911 97341-10
>> E-Mail: detlef.grittner@sohard.de
>>
>> Geschäftsführer: Peter Feltens, Sebastian Schnitzenbaumer
>> Sitz der Gesellschaft: Fürth
>> Registergericht: Amtsgericht Fürth; HRB 11478
>>
>>