In my mind, this should be done not by fixing a property but by defining a constraint reference pointing to the service/set of codes that can provide you with all mass units
2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland < [email protected]>: > Deriving the properties from the codes makes sense when you actually > specify the codes, but what do you do when you want to specify “this is a > concentration, but I don’t care about the exact units”? > > > > “Arbitrary unit” has a quite specific meaning, it’s not just a catch-all > for “new units for which we haven’t got the property defined in the > terminology yet”: https://en.wikipedia.org/wiki/Arbitrary_unit > > I see that IUPAC and IFCC has decided to use the term “procedure defined > unit” instead of “arbitrary unit”. > > > > Also, does leaving the “property” field out mean that we can have one > Quantity element with the units Cel, m, kg, ml and [arb'U]? > > > > Regards, > > *Silje* > > > > *Fra:* openEHR-technical [mailto:openehr-technical- > [email protected]] *På vegne av* Diego Boscá > *Sendt:* fredag 26. januar 2018 09:42 > *Til:* For openEHR technical discussions <openehr-technical@lists. > openehr.org> > *Emne:* Re: Quantities of arbitrary units in openEHR > > > > 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 <sebastian.garde@ > oceaninformatics.com>: > > 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 > -- [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
