Re: DICOM RDF: VR "OB or OW"

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
>