Hello c.p.d.,

browsing WG10 Meeting Minutes, I do not really see late progress of
modeling DICOM in XML - and evaluating different toolkits, I see
different views on the DICOM Data Model that all have limitations
compared with the standard itself.

Now, I am curious how the XML efforts are progressing and where "we" are
right now.

Analysing the PS3-2008 defined data Objects, I feel like there should be
a canonical formal description of the Object definitions independent of
re-writing DICOM in XML.

This would be a valuable start into formalizing DICOM into XML Schemas
or alike.

I have done something similar several times before for commercial
projects where the results are not shared with the community, and as you
might have guessed, I am feeling like re-inventing the wheel over and
over again...

Is this analysis done already with results shared with the community
somewhere I did not find it yet?

Or is someone willing to review my efforts so far in modeling the DICOM
Objects structure which I would love to share (and improve) with the
community?

Again, I am curious about your Opinions on this and I am appreciating
any comment.

Kind regards,


Peter

On Nov 25, 4:22=A0pm, Peter B Schmidt <n...@PBSchmidt.de> wrote:
> Hello c.p.d.,
>
> browsing WG10 Meeting Minutes, I do not really see late progress of
> modeling DICOM in XML - and evaluating different toolkits, I see
> different views on the DICOM Data Model that all have limitations
> compared with the standard itself.
>
> Now, I am curious how the XML efforts are progressing and where "we" are
> right now.
>
> Analysing the PS3-2008 defined data Objects, I feel like there should be
> a canonical formal description of the Object definitions independent of
> re-writing DICOM in XML.
>
> This would be a valuable start into formalizing DICOM into XML Schemas
> or alike.
>
> I have done something similar several times before for commercial
> projects where the results are not shared with the community, and as you
> might have guessed, I am feeling like re-inventing the wheel over and
> over again...
>
> Is this analysis done already with results shared with the community
> somewhere I did not find it yet?
>
> Or is someone willing to review my efforts so far in modeling the DICOM
> Objects structure which I would love to share (and improve) with the
> community?
>
> Again, I am curious about your Opinions on this and I am appreciating
> any comment.

This is how far I got:

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/InformationObjectDefinition=
/Part3.xml?view=3Dmarkup

I used XSLT directly on the Winword official PS 3.3-2008 to produce
this XML file. I have not checked it against anything else (neither
DVTk, nor dicom3tools / PixelMed).

I know that /someone/ from DCMTK has been playing with it a little :)

When I released this beast on the net, I was hoping to gets tons of
feedback to get it tweaked (it is hard to parse human sentences), but
it looks like validation is not very important in the open-source
community. Or I did not manage to get people involved in it. I could
not even get people to start using GDCM Part6.xml (*) :

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/Part6.xml?vi=
ew=3Dlog

Anyway I am /still/ hoping for some feedback on my approach (**).

BTW, I have also develop a way to keep in sync with private vendors
and there Private Dict. See for example:

http://gdcm.svn.sf.net/viewvc/gdcm/Sandbox/toshiba/miict0038ea.xml?view=3Dm=
arkup

which leads to the automatically generated private dict:

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/privatedicts=
..xml?view=3Dmarkup

Having a separate XML dict for each product allows to have something
maintanable in the long term, and I can always override an older
private dict with a new private dict, when the private vendor decide
that the DICOM Conformance Statement included too many typo in the
Private Dict.

Cheers
-Mathieu
(*) http://malatsblog.blogspot.com/2009/11/private-dicom-dictionary.html
(**) https://sourceforge.net/apps/mediawiki/gdcm/index.php?title=3DModule_A=
ttributes

The little information I found is from the WG-06 Short Term Goals
(http://medical.nema.org/dicom/geninfo/Strategy.pdf (Last Update:
November 26, 2007)):

=95 Develop mechanisms for publication of DICOM standard in XML. The
most recent effort using DocBook
  as the source format is promising.
=95 There is a proposal to issue the next official version of DICOM in
just an HTML format, due to the
  complexity of generating the PDF form (with consistent pagination,
illustration placement, cross
  references, etc.) from the DocBook form. The generation of high
quality HTML format (similar to the
  W3C standard format) is much simpler. The proposal is to try this to
determine whether the additional
  effort needed for PDF format is worthwhile. Feedback from the DICOM
committee is requested.

And WG-06 minutes (http://medical.nema.org/Dicom/minutes/
WG-06/2009/2009-08-24/WG-06_2009-08-24_Min.doc and again in
	http://medical.nema.org/Dicom/minutes/WG-06/2009/2009-10-26/WG-06_2009-10-=
26_Min_Rev1.doc):

Publishing DICOM in XML
Howard Clark presented a status report from Jim Rogers, who is under
contract to convert all figures in the DICOM Standard to =93.svg=94
format.  Mr. Rogers reported, =93I've been iteratively combing thru the
last 50-odd illustrations for PS3.17-2008 Explanatory Information.
I'd be done with PS3.17 sooner, but the SR Content Tree diagrams don't
follow the relationship and associations conventions defined elsewhere
in DICOM...While the original diagrams are 'clean', they've also co-
mingled information.  In the revised SVG files, I've separated the
relationships out. There are some other conventions that were not
followed in the original diagrams as well, such as Has Properties
applying to a Container; it can't =96 a Container can have Code,
Observations, etc., which then Has Properties, but not directly (for
example Figure I.1-1).  I'm cross-checking these to the other DICOM
standards, as well as internally to PS3.17, and making the corrections
and clarifications.  I need just a couple more days, and I'll be
ftp'ing the complete set of svg files (about 130 svg files total for
the standard) to you for review and comment.=94

Nils

Hello Mathieu,

thank you for your response. I checked the XML files, and I am very
pleased what I found by now. If you did not receive much feedback on
this, maybe because you did such a good job on it.

In fact, I did not yet really understand the schemas, but this is mainly
because a lack of time until now. However, I did not want to let you
wait too long for my answer ;o)

So let me provide some feedback:

The illustration regarding "Image Position (Patient) and "Image
Orientation (Patient)" comes out a bit funny. Probably the explanations
field should have a markup content (HTML, ...)? Some explanations are
hard to read as plain ASCII. Just a proposal to make something perfect
even more perfect ;o)

The method of introducing corrections is a bit quirky. I would suggest
to just enter the information from the CP or Supplement, and give an
extra attribute like changed="CP255" or changed="Supp23".

Also a valuable information of additions post baseline might be
introduced="Supp13", because sometimes this clarifies the clinical
context of the attribute.

Of course, with your method of extracting it from the documents it is
fine like this, the "versioning" would be rather for the "master"
database providing the source of documentation in some future to see.

Now, the files are licensed GPL in gdcm, so I would have to include the
whole gdcm if I wanted to use them - what is a bit of a downside if I
would prefer another Open Source toolkit and makes it impossible for
others that want to use it in a closed source implementation.

<science_fiction_mode>
If there was a pure "opdendicom-datadictionary" project, everybody could
benefit from the dictionary, and if the license is appropriate, I could
imagine a bright future where everybody uses only this dictionary, which
might by then be the canonical nema-approved repository for creating
software and documentation
</science_fiction_mode>


Thank you for your valuable proposal, and again thank you for sharing
gdcm with us!


Cheers,


Peter

Hello again,

one point slipped my mind:

Is it still okay from copyright issues to create a
"opdendicom-datadictionary" project which contains nothing like
drivative work from NEMA? I would doubt that....


Cheers,


Peter

Dear Peter,

On Nov 26, 1:58=A0pm, Peter B Schmidt <n...@PBSchmidt.de> wrote:
> Hello Mathieu,
>
> thank you for your response. I checked the XML files, and I am very
> pleased what I found by now. If you did not receive much feedback on
> this, maybe because you did such a good job on it.

lol

> In fact, I did not yet really understand the schemas, but this is mainly
> because a lack of time until now. However, I did not want to let you
> wait too long for my answer ;o)
>
> So let me provide some feedback:
>
> The illustration regarding "Image Position (Patient) and "Image
> Orientation (Patient)" comes out a bit funny. Probably the explanations
> field should have a markup content (HTML, ...)? Some explanations are
> hard to read as plain ASCII. Just a proposal to make something perfect
> even more perfect ;o)

That's exactly this kind of feedback I was wanting :)
I have logged this as a bug:
http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2904895&group_id=3D1378=
95&atid=3D739587

However the goal of Part3.xml is simply to provide the minimal input
for writing yet-another dciodvfy or dcmcheck. The whole PS 3.3-2008
does not need to be included.

> The method of introducing corrections is a bit quirky. I would suggest
> to just enter the information from the CP or Supplement, and give an
> extra attribute like changed=3D"CP255" or changed=3D"Supp23".

Long story short, CP/Supp will be too difficult (IMHO) to handle. I am
hoping to see the next edition of DICOM distributed as docbook
document. In which case a 'diff' (unix tool) will indeed be possible
(or some kinf of xml equivalent). I will not invest too much time in
handling Supp/CPs for now, and instead hope for a docbook edition.

> Also a valuable information of additions post baseline might be
> introduced=3D"Supp13", because sometimes this clarifies the clinical
> context of the attribute.
>
> Of course, with your method of extracting it from the documents it is
> fine like this, the "versioning" would be rather for the "master"
> database providing the source of documentation in some future to see.
>
> Now, the files are licensed GPL in gdcm, so I would have to include the

Where did you read that GDCM was GPL ? It was initially released as
LGPL, but converted to BSD in ~2003.
http://gdcm.sourceforge.net/Copyright.html

> whole gdcm if I wanted to use them - what is a bit of a downside if I
> would prefer another Open Source toolkit and makes it impossible for
> others that want to use it in a closed source implementation.

BSD is very flexible, for instance GDCM is used in VolView (a closed
source product).

> <science_fiction_mode>
> If there was a pure "opdendicom-datadictionary" project, everybody could
> benefit from the dictionary, and if the license is appropriate, I could
> imagine a bright future where everybody uses only this dictionary, which
> might by then be the canonical nema-approved repository for creating
> software and documentation
> </science_fiction_mode>

That is exactly the goal of Part3.xml as I hoped (license is really
flexible). I am really hoping to see the docbook edition of the
standard, and have Part3.xml be only a 'more' machine readable version
of PS 3.3.

<science_fiction_mode>I would also hope that the commitee provide
docbook template for private vendor, so that private dict will be
easier to parse in the future</science_fiction_mode>

> Thank you for your valuable proposal, and again thank you for sharing
> gdcm with us!

Thanks for your comments !

On Nov 26, 1:59=A0pm, Peter B Schmidt <n...@PBSchmidt.de> wrote:
> Hello again,
>
> one point slipped my mind:
>
> Is it still okay from copyright issues to create a
> "opdendicom-datadictionary" project which contains nothing like
> drivative work from NEMA? I would doubt that....

I'll leave that to D. Clunie. I think I raised the issue at some
point, but I do not remember what was the solution.

-M

Hi Peter, Mathieu

There are really two different questions here:

1. will there be a version of the text and tables of the DICOM
   standard in a machine-readable form like XML ?

2. will there be a formal DICOM information model in a
   machine-readable form (e.g, UML in XDI XML) ?

The answer to the first question, is yes, eventually, though
I have been too preoccupied lately to make much progress on
this myself, and the 2009/2010 edition of the standard may not
be in DocBook as originally planned.

The answer to the second question is more complicated, because
as you all well know, the structure of the various IODs is not
truly object-oriented, the various different IODs diverge and
use the same attributes within different entities, and much
important stuff is not formally represented but described in
prose, and very hard to deal with formally.

There is an NCI funded DICOM Ontology project, which is working
on the CT image object to start with, but their output may not
be a real answer to the need for a formal model, their
scope covers just the tip of the iceberg in terms of complexity.
and those working on it are very Protege-centric, which may
not be your cup of tea. See:

  "https://wiki.nci.nih.gov/display/Imaging/How+to+Protege+DICOM"
  "https://gforge.nci.nih.gov/projects/dicomontphase1/"

for details.

One day, some formal model of the standard might be the canonical
form from which the text of the normative standard is generated,
but this is rather optimistic at the current juncture.

As for the copyright question, there is no problem with including
tables for data dictionaries, IODs, etc., as far as NEMA or
DICOM are concerned; that is obviously necessary to create
toolkits in the first place. I have been doing this with my
open source code for years, for example, as has everyone
else.

Formally in this respect, the committee has been working on
revised language for royalty-free permission is granted to copy,
use, and publish "excerpts", with the definition of the latter
left unspecified ... the Committee actually wanted to say
"all or part", but NEMA's counsel preferred that in the "all"
case, formal written permission be obtained first; such
permission will certainly be forthcoming though, as far as
the committee is concerned. The revised procedures incorporating
this policy have not yet been balloted, but you will
find discussion and approval of this in recent Committee meeting
minutes at:

  "http://medical.nema.org/Dicom/minutes/Committee/2009/".

Finally, though DICOM itself would certainly not publish a list
of private dictionary elements, that would not prevent NEMA
creating a private element and/or conformance statement registry,
from which such a dictionary could be obtained. Whether the vendors
would contribute or not is another question.

David