Relationships by-reference (DICOM SR) - DICOM

This is a discussion on Relationships by-reference (DICOM SR) - DICOM ; Hello all, I've got a couple of questions concerning relationships by-reference in DICOM SR: 1.) Do the "relationship content constraints" tables given in PS 3.3, Annex A.35, apply to *both* by-value and by-reference relationships? As far as I understand, they ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Relationships by-reference (DICOM SR)

  1. Relationships by-reference (DICOM SR)

    Hello all,

    I've got a couple of questions concerning relationships by-reference in DICOM SR:

    1.) Do the "relationship content constraints" tables given in PS 3.3, Annex
    A.35, apply to *both* by-value and by-reference relationships? As far as I
    understand, they do? E.g., PS 3.3 A.35.5.3.1.3 Mammo-CAD relationship
    constraints, permits "INFERRED FROM", "HAS PROPERTIES" and "SELECTED FROM"
    relationships only. Does this mean, that only the relations specified by the
    last three rows of table A.35.5-2 are valid by-reference relations?
    [sorry for this "stupid" question, but I think the standard could be more
    specific in this aspect]

    2.) [another stupid one, stay patient]
    PS 3.3 A.35.8.3.1.3 (X-Ray Radiation Dose SR relation content constraints)
    does not mention explicitly that relationships by-reference are forbidden but
    uses the 'soft' phrase "Relationships between content items in the content of
    this IOD may be conveyed by-value."
    Does this mean, that by-reference relationships are uncommon or are they
    forbidden?
    In contrast: A.35.1.3.1.2, A.35.2.3.1.2, A.35.4.3.1.2 and A.35.7.3.1.4 feature
    a strict note:
    "Relationships by-reference are forbidden. Therefore, Referenced Content Item
    Identifier (0040,DB73) is not present in any of the Content Items within the
    SR Document Content Module."
    I propose to add this note to A.35.8.3.1.3, too (if applicable).

    3.) The Comprehensive SR IOD features an interesting phrase in PS 3.3
    A.35.3.3.1.2:
    "For relationships conveyed by-reference, Content Items with a Value Type of
    CONTAINER shall only be the target of relationships other than CONTAINS."
    I do understand this restriction and its rationale. My question is, whether it
    is safe to assume that this constraint will hold true for future SR IODs to
    come. I.e., in a generic DICOM SR editor, will it be safe to always prevent
    CONTAINS relationships by-reference with the target CONTAINER?

    4.) Another important phrase in the same chapter (p. 194, top):
    "Relationships by-reference to ancestor Content Items are forbidden in this
    IOD to prevent loops."
    As far as I understand, this fordbids by-reference relations with any target
    node on the path from the SR tree root to the source node of the relation.
    This sounds logical as a general rule but is not mentioned int the other IODs
    using by-reference relations (Mammo-CAD, Chest-CAD). What about these two?

    5.) There are a couple of statements in David Clunie's SR book that contradict
    the current DICOM 2008 standard:
    - p. 126: "[...] the SR framework allows for “pointers” or “references” to
    content items that are not *direct descendants*". (isn't a "descendant" the
    'opposite direction' of an "ancestor" mentioned in point 4. in this e-mail?)
    - p. 128: "It is important to remember that “contains” relationships may not
    be specified by reference, only by value." (contradicts A.35.3.3.1.2: "It is
    legal to have a CONTAINS relationship by-reference to a target that is not a
    CONTAINER, such as a TEXT or CODE [...].")
    Are these remarks outdated or is there a place I haven't looked at in the
    current standard?

    It would be great if someone could comment on these items.

    Thanks in advance and have a nice day,

    Winfried

  2. Re: Relationships by-reference (DICOM SR)

    Winfried Schoech wrote:

    > 1.) Do the "relationship content constraints" tables given in PS 3.3,
    > Annex A.35, apply to *both* by-value and by-reference relationships?


    Yes. At least this is how we understand the standard and how the SR module
    in DCMTK enforces the constraints. For most IODs permitting by-reference
    relationship there are additional restrictions in the text. So formally
    speaking, the set of possible
    (parent value type, relationship type, child value type)
    tuples for by-reference relationships is a true subset of that for by-value
    relationships.

    > PS 3.3 A.35.8.3.1.3 (X-Ray Radiation Dose SR relation content
    > constraints) does not mention explicitly that relationships by-reference
    > are forbidden but uses the 'soft' phrase "Relationships between content
    > items in the content of this IOD may be conveyed by-value."
    > Does this mean, that by-reference relationships are uncommon or are they
    > forbidden?


    The wording is not clear, be we interpret "may" as "shall" here, i.e.
    DCMTK permits by-value relationships only. In any case a CP might be appropriate here.

    > "For relationships conveyed by-reference, Content Items with a Value
    > Type of CONTAINER shall only be the target of relationships other than
    > CONTAINS."
    > I do understand this restriction and its rationale. My question is,
    > whether it is safe to assume that this constraint will hold true for
    > future SR IODs to come. I.e., in a generic DICOM SR editor, will it be
    > safe to always prevent CONTAINS relationships by-reference with the
    > target CONTAINER?


    I don't think you can safely assume that.

    > "Relationships by-reference to ancestor Content Items are forbidden in
    > this IOD to prevent loops."


    The original intent of this statement was most probably to ensure that
    the directed graph of a comprehensive SR document is acyclic, but the
    statement fails to achieve this - it is still very much possible to
    create cycles in the graph. Therefore, the rule has very little practical
    meaning and the fact that it explicitly applies to Comprehensive SR only
    and is not repeated for other IODs implies that no such rule exists in
    other IODs. You just have to make sure that your processing/visualization
    algorithms are able to cope with cycles in the graph.

    > 5.) There are a couple of statements in David Clunie's SR book that
    > contradict the current DICOM 2008 standard:
    > - p. 126: "[...] the SR framework allows for “pointers” or “references”
    > to content items that are not *direct descendants*". (isn't a
    > "descendant" the 'opposite direction' of an "ancestor" mentioned in
    > point 4. in this e-mail?)


    I don't see a contracdiction here. Basically the statement means that
    by-reference relationships can be used to refer to content items not
    contained by-value (in which case they would be direct descendants).

    > - p. 128: "It is important to remember that “contains” relationships
    > may not be specified by reference, only by value." (contradicts
    > A.35.3.3.1.2: "It is legal to have a CONTAINS relationship by-reference
    > to a target that is not a
    > CONTAINER, such as a TEXT or CODE [...].")
    > Are these remarks outdated or is there a place I haven't looked at in
    > the current standard?


    In that case the remark is probably outdated and only meant to apply
    to CONTAINERs, but David is certainly better able to answer that question.

    Regards
    Marco Eichelberg
    OFFIS

  3. Re: Relationships by-reference (DICOM SR)

    Hi Winfried

    Marco Eichelberg wrote:
    > Winfried Schoech wrote:
    >
    >> 1.) Do the "relationship content constraints" tables given in PS 3.3,
    >> Annex A.35, apply to *both* by-value and by-reference relationships?

    >
    > Yes. At least this is how we understand the standard and how the SR module
    > in DCMTK enforces the constraints. For most IODs permitting by-reference
    > relationship there are additional restrictions in the text. So formally
    > speaking, the set of possible
    > (parent value type, relationship type, child value type)
    > tuples for by-reference relationships is a true subset of that for by-value
    > relationships.


    The relationship constraints in the table able to both by-value and
    by-reference, except in so far as for some IODs by-reference is
    explicitly forbidden, and to the extent that further constraints
    are specified in text..

    >> PS 3.3 A.35.8.3.1.3 (X-Ray Radiation Dose SR relation content
    >> constraints) does not mention explicitly that relationships
    >> by-reference are forbidden but uses the 'soft' phrase "Relationships
    >> between content items in the content of this IOD may be conveyed
    >> by-value."
    >> Does this mean, that by-reference relationships are uncommon or are
    >> they forbidden?

    >
    > The wording is not clear, be we interpret "may" as "shall" here, i.e.
    > DCMTK permits by-value relationships only. In any case a CP might be
    > appropriate here.


    It is meant to be "shall" not "may"; I will put in a CP.

    >> "For relationships conveyed by-reference, Content Items with a Value
    >> Type of CONTAINER shall only be the target of relationships other than
    >> CONTAINS."
    >> I do understand this restriction and its rationale. My question is,
    >> whether it is safe to assume that this constraint will hold true for
    >> future SR IODs to come. I.e., in a generic DICOM SR editor, will it be
    >> safe to always prevent CONTAINS relationships by-reference with the
    >> target CONTAINER?

    >
    > I don't think you can safely assume that.


    I would agree with Marco; you should assume nothing, since we are fickle
    and unpredictable when it comes to what we might (need to) do in future
    IODs.

    Having said that, the CONTAINER relationship is pretty specially and I
    can see no reason why we would want to reverse this constraint, which
    was put in place to reliably build a tree of CONTAINERs (only).

    >> "Relationships by-reference to ancestor Content Items are forbidden in
    >> this IOD to prevent loops."

    >
    > The original intent of this statement was most probably to ensure that
    > the directed graph of a comprehensive SR document is acyclic, but the
    > statement fails to achieve this - it is still very much possible to
    > create cycles in the graph. Therefore, the rule has very little practical
    > meaning and the fact that it explicitly applies to Comprehensive SR only
    > and is not repeated for other IODs implies that no such rule exists in
    > other IODs. You just have to make sure that your processing/visualization
    > algorithms are able to cope with cycles in the graph.


    How do you create cycles if you can't reference an ancestor ? Depends
    on the definition of ancestor, I suppose, but yes, the intent was to
    make the structure acyclic.

    >> 5.) There are a couple of statements in David Clunie's SR book that
    >> contradict the current DICOM 2008 standard:


    The book is really old and predates much of the SR work and does not
    account for many recent Supplements and CPs, so the standard text
    always supersedes anything stated in the book that is contradictory.

    >> - p. 126: "[...] the SR framework allows for “pointers” or
    >> “references” to content items that are not *direct descendants*".
    >> (isn't a "descendant" the 'opposite direction' of an "ancestor"
    >> mentioned in point 4. in this e-mail?)

    >
    > I don't see a contradiction here. Basically the statement means that
    > by-reference relationships can be used to refer to content items not
    > contained by-value (in which case they would be direct descendants).


    That's what I meant.

    >> - p. 128: "It is important to remember that “contains” relationships
    >> may not be specified by reference, only by value." (contradicts
    >> A.35.3.3.1.2: "It is legal to have a CONTAINS relationship
    >> by-reference to a target that is not a
    >> CONTAINER, such as a TEXT or CODE [...].")
    >> Are these remarks outdated or is there a place I haven't looked at in
    >> the current standard?

    >
    > In that case the remark is probably outdated and only meant to apply
    > to CONTAINERs, but David is certainly better able to answer that question.


    All this containment and by-reference stuff was a source of considerable
    confusion (hence, for example CP 215), but I would agree with Marco
    that in this case the book is explicitly wrong in the general case,
    in that the prohibition applies only to contained CONTAINERS.

    Having said that, I cannot find a single R-CONTAINS relationship in
    any of the templates in PS 3.16. I suspect it is probably a bad idea.
    I will suggest the idea of a CP about this to WG 6.

    David

  4. Re: Relationships by-reference (DICOM SR)

    David Clunie wrote:
    >>> "Relationships by-reference to ancestor Content Items are forbidden
    >>> in this IOD to prevent loops."

    >>
    >> The original intent of this statement was most probably to ensure that
    >> the directed graph of a comprehensive SR document is acyclic, but the
    >> statement fails to achieve this - it is still very much possible to
    >> create cycles in the graph. Therefore, the rule has very little practical
    >> meaning and the fact that it explicitly applies to Comprehensive SR only
    >> and is not repeated for other IODs implies that no such rule exists in
    >> other IODs. You just have to make sure that your processing/visualization
    >> algorithms are able to cope with cycles in the graph.

    >
    > How do you create cycles if you can't reference an ancestor ? Depends
    > on the definition of ancestor, I suppose, but yes, the intent was to
    > make the structure acyclic.


    Let's assume you have the following structure

    CONTAINER_1
    |
    +--CONTAINER_2
    | |
    | +--TEXT_2
    |
    +--CONTAINER_3
    |
    +--TEXT_3

    The wonderful ASCII art describes the by-value relationships (I have omitted relationship types).
    Now TEXT_3 could have a by-reference relationship (inferred-from or the like) to TEXT_2 and TEXT_2
    could also have a by-reference relationship to TEXT_3 since neither node is ancestor of the other
    node, neither directly nor indirectly. And voilá - there is your cycle:

    CONTAINER_1 -> CONTAINER_2 -> TEXT_2 (by ref) -> TEXT_3 (by ref) -> TEXT_2 ... and so on.

    Any tool trying to recursively dump the content of the graph will be caught in an infinite loop
    unless it is able to cope with cycles in the graph. Not having links to ancestors is simply not
    a sufficient condition to guarantee that a directed graph is acyclic.

    Regards,
    Marco Eichelberg

  5. Re: Relationships by-reference (DICOM SR)

    > The wonderful ASCII art describes the by-value relationships (I have omitted relationship types).
    > Now TEXT_3 could have a by-reference relationship (inferred-from or the like) to TEXT_2 and TEXT_2
    > could also have a by-reference relationship to TEXT_3 since neither node is ancestor of the other
    > node, neither directly nor indirectly. And voil - there is your cycle:


    Btw, a sample document is part of the following package (file
    "reportlp.dcm"):
    ftp://dicom.offis.de/pub/dicom/offis...t/srdoc103.zip

    Regards,
    Joerg Riesmeier

+ Reply to Thread