Revisiting RESOURCE_DESCRIPTION.details: Hash or List question

All,

I can’t seem to find the original posts on this subject, but in any case, am processing it now. I have written a CR (http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/231). I am in favour of changing the type of RESOURCE_DESCRIPTION.details from a List<> to a Hash<>. I seem also to remember that there were complaints about the language attribute in the class RESOURCE_DESCRIPTION_ITEM due to seemingly being a replication of the language key in the Hash. I would be against removing this for the following reasons:

  • an object which is language-dependent should contain an attribute giving the language

  • the same approach used elsewhere, e.g. in AUTHORED_RESOURCE.translations

  • the AOM has already been adopted by CEN. The List<> to Hash<> change will be accepted as an error correction, but I don’t think removing of RESOURCE_DESCRIPTION_ITEM.language would be seen this way.
    Was there a strong reason for wanting to remove RESOURCE_DESCRIPTION_ITEM.language?

  • thomas

I think this should go to ADL 1.5 as it will break current archetypes in XML (a hash is always difficult in XML anyway)
Cheers, Sam

Thomas Beale wrote:

All,

I can’t seem to find the original posts on this subject, but in any case, am processing it now. I have written a CR (http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/231 ). I am in favour of changing the type of RESOURCE_DESCRIPTION.details from a List<> to a Hash<>. I seem also to remember that there were complaints about the language attribute in the class RESOURCE_DESCRIPTION_ITEM due to seemingly being a replication of the language key in the Hash. I would be against removing this for the following reasons:

  • an object which is language-dependent should contain an attribute giving the language

  • the same approach used elsewhere, e.g. in AUTHORED_RESOURCE.translations

  • the AOM has already been adopted by CEN. The List<> to Hash<> change will be accepted as an error correction, but I don’t think removing of RESOURCE_DESCRIPTION_ITEM.language would be seen this way.
    Was there a strong reason for wanting to remove RESOURCE_DESCRIPTION_ITEM.language?

Thanks for raising this issue.

I can’t think of any strong reason to remove “language”.

Regards,
Rong

Sam Heard wrote:

I think this should go to ADL 1.5 as it will break current archetypes in XML (a hash is always difficult in XML anyway)
Cheers, Sam

No, this isn’t true - the archetypes do not change. If there will be a problem in XML, we need to fix it now. Hashes in ADL are ubiquitous, and are what you see when you have things like:

    original_author = <
        ["name"] = <"Sam Heard">
        ["organisation"] = <"Ocean Informatics">
        ["date"] = <"22/03/2006">
        ["email"] = <["sam.heard@oceaninformatics.biz"](mailto:sam.heard@oceaninformatics.biz)>
    >
    details = <
        ["en"] = <
            language = <"en">
            purpose = <"To record a score of dependency on help to undertake important activities of daily living. The total score is the sum of the ordinal scores for each attribute.">
            use = <"For scoring people's independence - often in a nursing home.">
            misuse = <"Not to be used to record individual features.">
        >
        ["nl"] = <
            language = <"nl">
            purpose = <"To record a score of dependency on help to undertake important activities of daily living. The total score is the sum of the ordinal scores for each attribute.">
            use = <"For scoring people's independence - often in a nursing home.">
            keywords = <"score", "index", "activities", "daily living", "dependency">
            misuse = <"Not to be used to record individual features.">
        >
    >

plus the ontology. All the [“xx”] are has keys. The change requested here is probably the one place where it isn’t due to me mistakenly specifying a list not a Hash.

How it gets modelled in XML doesn’t matter too much, but you must be already doing it Sam - I would imagine it is with the key as an XML attribute…in fact, section 3.5 of the 1.4 document - http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/am/adl.pdf already tels how to do this transformation.

  • thomas