I think there are several potential problems with this, and IMHO we are stepping too much on what should be done in a terminology service (We are literally talking about a 'public available UCUM service'). You can also ask the terminology service what kind of unit code you have. Your implementation could answer "arbitrary" for these new units.
In my opinion, saying "here comes a mass unit code" is not much different from "here comes a diagnosis code", and we say these in a completely different way (a better way, if you ask me). Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind of terminology code that is potentially dangerous as knowledge or terminology advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' all mixed up. That's why I also expect these properties to be as derived from the codes and not the other way around. 2018-01-26 9:21 GMT+01:00 Sebastian Garde < [email protected]>: > While I agree with the SPEC-95 rationale (once you have a unit, you should > be able to know what its property is), it is still convenient to have the > property for constraining. > Otherwise you don't have a way to say in an archetype: I don't care about > the exact unit here, but please let it be a "Mass". > > -----Ursprüngliche Nachricht----- > Von: openEHR-technical [mailto:[email protected]] > Im Auftrag von Thomas Beale > Gesendet: Freitag, 26. Januar 2018 09:13 > An: [email protected] > Betreff: Re: Quantities of arbitrary units in openEHR > > Right - at the moment, it is a 'fake' field in archetypes, enabled by > being in the BMM or other expression of the RM. It's convenient to do this > occasionally, since we don't think 'property' needs to be a field of > DV_QUANTITY - but maybe it should be, since for some of the more esoteric > units, it's not that clear what is being measured. > > This trick is also not mentioned in the ADL/AOM specs, and it either > should be, or we just don't allow it. I don't have a strong opinion either > way. > > - thomas > > > On 26/01/2018 07:51, Pieter Bos wrote: > > A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification, > > there is no property attribute or function present in dv_quantity, > > even though the text says it can be conveniently constrained. There is > > a reference to the spec-95 jira issue, which says it has been removed. > > So there’s no way to constrain it - unless the specification contains > > a mistake :) > > > > It is present in the BMM variants of the RM though, as a mandatory field. > > > > Regards, > > > > Pieter Bos > > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] <https://htmlsig.com/t/000001C4DPJG> [image: Maps] <https://htmlsig.com/t/000001BZTWS7> Diego Boscá Tomás / Senior developer [email protected] [email protected] VeraTech for Health SL +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023 <+34%20627%2001%2050%2023> www.veratech.es Su dirección de correo electrónico junto a sus datos personales forman parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999, usted puede ejercitar sus derechos de acceso, rectificación, cancelación y, en su caso oposición, enviando una solicitud por escrito a [email protected].
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
