# PartyIdentity -> Purpose

**Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154)
**Created:** 2007-12-07 14:40 UTC
**Views:** 2
**Replies:** 10
**URL:** https://discourse.openehr.org/t/partyidentity-purpose/16013

---

## Post #1 by @system

Maybe Rong, has some time to answer this, but I am very glad with
anyone's answer\.

I have a question about the ref\_java\_impl\. I checked the latest TRUNK
version, there is something that is not clear to me\.

I looked in the document: Demographic Information Model, version
Revision: 2\.0\.1, which is, I believe, the latest published version\.

I look at PartyIdentity and see the required attribute "purpose"\.
But it is not in the rm\-domain\-object PartyIdentity in the constructor\.
This an annotated constructor, the annotations are used by the
rm\-builder\. So there is no way, by using the rm\-builder, to assign the
attribute "purpose"

I found a few similar situations, and have about the same question\.

thanks in advance
Bert Verhees

---

## Post #2 by @Sergio_M_Freire

Hi Bert,

purpose is a function that returns the value of the  inherited name
attribute\. It is implemented in the method purpose\(\)

Cheers,

Sergio

---

## Post #3 by @system

Sergio Miranda Freire schreef:
> Hi Bert,
>
> purpose is a function that returns the value of the  inherited name
> attribute\. It is implemented in the method purpose\(\)
>
> Cheers,
>
> Sergio
>

Thanks Sergio,

But there is no setter for it\. It returns this\.name, which is set in the
constructor\.
But this seems wrong to me, because in the rm\-builder the name of
property is demanded, that is why it is an annotated constructor\.
In archetypes the attributename also is "purpose"

So there should be a mapping then from "purpose" to "name"

I do not understand why this is, also because in the eiffel reference
code, the attribute "purpose" is defined

Bert

---

## Post #4 by @Sergio_M_Freire

Hi Bert,

> Sergio Miranda Freire schreef:
>>
>> purpose is a function that returns the value of the  inherited name
>> attribute\. It is implemented in the method purpose\(\)

> But there is no setter for it\. It returns this\.name, which is set in the
> constructor\.
> But this seems wrong to me, because in the rm\-builder the name of
> property is demanded, that is why it is an annotated constructor\.

I do not know if I understood what you meant\. Why should we have a setter
for purpose if it is not an attribute of PartyIdentity, but is derived
from name which is set in the constructor of Locatable? Besides, purpose
is not a parameter of the constructor\.

> In archetypes the attributename also is "purpose"
>
> So there should be a mapping then from "purpose" to "name"
>
I guess we are using the openehr\-demographic\-person\.person\.draft archetype\.
I have the same question\. The archetype suggests that purpose is an
attribute of PartyIdentity\. Here I think that instead of having a purpose
attribute, there should be a constraint on the values of the name
attribute, and there would be no need of a mapping\. Also it would be
consistent with the reference model\.

We are here in Brazil designing a set of archetypes that could be used to
build a demographic service\. Although the openehr archetypes could be
inspiring, they are, as you said in a previous message, incomplete\. As
soon as we have a draft version of them I will send them to you and would
very much appreciate your comments\.

> I do not understand why this is, also because in the eiffel reference
> code, the attribute "purpose" is defined
>
I guess the java implementation is following the reference model
specification\.

Best regards,

Sergio

---

## Post #5 by @system

sergio@lampada\.uerj\.br schreef:
> Hi Bert,
>
>> Sergio Miranda Freire schreef:
>>    
>>> purpose is a function that returns the value of the  inherited name
>>> attribute\. It is implemented in the method purpose\(\)
>>>      
>> But there is no setter for it\. It returns this\.name, which is set in the
>> constructor\.
>> But this seems wrong to me, because in the rm\-builder the name of
>> property is demanded, that is why it is an annotated constructor\.
>>    
> I do not know if I understood what you meant\. Why should we have a setter
> for purpose if it is not an attribute of PartyIdentity, but is derived
> from name which is set in the constructor of Locatable? Besides, purpose
> is not a parameter of the constructor\.
>  

Thanks, Sergio, for thinking with me,

I think it should be in the constructor, because, reading the specs, it
is a required attribute, please take a look in
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/rm/demographic_im.pdf
It must be the same as "name", you are right, and "name" is an annotated
parameter in the constructor\.

But the way it is now, we have a required attribute, which is with
another name \(which is "name"\) in the constructor, this makes it
difficult to interpret ADL\. Because people will use in ADL "purpose",
because they read the specs, and when the reference java kernel is used,
"purpose" in ADL must be mapped to "name"
Anyway, this must be in the rm\-builder, which is also a part of the
ref\_java\_impl, because the rm\-builder, maybe you did not take a look at
the code, simply said, uses archetype\-input and data to construct an
RM\-object \(that why it is called the RM\-builder\)\. I would have called it
"rm\-factory", but that is not important\.

If you look at the code, you'll see it uses the annotated constructors
from the openehr\-rm to  get a definition of the rm\-objects to build, and
it maps these constructors to the data given to the rm\-builder\. These
data are mapped to attributes in the archetypes, and in the archetype,
"purpose" is used, instead of "name"

It is a fine piece of code, and I use it as a base, but this is a problem\.

Besides that, what is the use of a required attribute, when it will be
called differently in the constructor?

Confusing\!

I would like to have more clearity on this, because as it is now, this
will lead to stupid code in the rm\-builder

thanks
Bert

---

## Post #6 by @Sergio_M_Freire

Hi Bert,

I think we are speaking of openehr\-demographic\-person\.person\.draft\.adl
archetype\. I think it should be designed like this:

PERSON\[at0000\] matches \{	\-\- person demographics
    identities matches \{
     PARTY\_IDENTITY\[at0001\] matches \{	\-\- legal name
      name matches \{
        CODED\_TEXT matches \{
          code matches \{\[ac0001\]\}	\-\- legal name
        \}
      \}
      details matches \{
         \.\.\.

instead of

PERSON\[at0000\] matches \{	\-\- person demographics
    identities matches \{
     PARTY\_IDENTITY\[at0001\] matches \{	\-\- legal name
      purpose matches \{
        CODED\_TEXT matches \{
          code matches \{\[ac0001\]\}	\-\- legal name
        \}
      \}
      details matches \{
        \.\.\.

because, as far as I understood, purpose is a function, not an attribute,
according to the rm specification\.
Therefore, it is not in the list of attributes of PARTY\_IDENTITY that
could be constrained by an archetype\.

If you think it is the archetype that is wrong, then everything else seems
to be consistent for me, doesn't it?
On the other hand, if the archetype is to be kept like it is now, then I
agree with you that several changes must be done, the rm specification
included\.

By the way, I reviewed the rm\-builder code and I have two comments:
1\) In method loadTypeMap, in line 67, DvQuantityRatio should be replaced
by DvProportion, according to the 1\.0\.1 specification, right?;
2\) For the sake of clarity, the local variable typeMap in method construct
\(line 241\) could be renamed to something like attributeTypeMap in order to
not be confounded with the typeMap class attribute \.

Thanks for the discussion\.

Sergio

---

## Post #7 by @system

Sergio M\. Freire schreef:
> Hi Bert,
>
> I think we are speaking of openehr\-demographic\-person\.person\.draft\.adl
>  

Thanks for being persevering, you are right, I checked again the docs,
and it is a function\. It was indeed this archetype, which confused me,
this happens sometimes, the changes in specs, leaving old traces of
previous specs behind

Thanks
Bert

---

## Post #8 by @system

Sergio M\. Freire schreef:
> Hi Bert,
>
> I think we are speaking of openehr\-demographic\-person\.person\.draft\.adl
> archetype\. I think it should be designed like this:
>
>  PERSON\[at0000\] matches \{	\-\- person demographics
>     identities matches \{
>      PARTY\_IDENTITY\[at0001\] matches \{	\-\- legal name
>       name matches \{
>         CODED\_TEXT matches \{
>           code matches \{\[ac0001\]\}	\-\- legal name
>         \}
>       \}
>       details matches \{
>          \.\.\.
>
> instead of
>
>  PERSON\[at0000\] matches \{	\-\- person demographics
>     identities matches \{
>      PARTY\_IDENTITY\[at0001\] matches \{	\-\- legal name
>       purpose matches \{
>         CODED\_TEXT matches \{
>           code matches \{\[ac0001\]\}	\-\- legal name
>         \}
>       \}
>       details matches \{
>         \.\.\.
>
> because, as far as I understood, purpose is a function, not an attribute,
> according to the rm specification\.
> Therefore, it is not in the list of attributes of PARTY\_IDENTITY that
> could be constrained by an archetype\.
>
> If you think it is the archetype that is wrong, then everything else seems
> to be consistent for me, doesn't it?
> On the other hand, if the archetype is to be kept like it is now, then I
> agree with you that several changes must be done, the rm specification
> included\.
>
> By the way, I reviewed the rm\-builder code and I have two comments:
> 1\) In method loadTypeMap, in line 67, DvQuantityRatio should be replaced
> by DvProportion, according to the 1\.0\.1 specification, right?;
> 2\) For the sake of clarity, the local variable typeMap in method construct
> \(line 241\) could be renamed to something like attributeTypeMap in order to
> not be confounded with the typeMap class attribute \.
>  

Sorry, I didn't read the second part of your writing\. I must say, that I
don't work with the latest version of the specs, I am somewhere between
0\.95 and 1\.0\.1\. This is because, I am almost ready with a working
kernel, also persistence, and archetype\-interpretation, and rm\-builder\.
I have my own code, but heavily based on the work of Rong\.
When I am ready, and it is stable, I will fully migrate to 1\.0\.1 which
is not that hard to do\.

Your suggestions concerning the rm\-builder, I leave them for Rong to
reply on, because he is the java\-kernel\-maintainer\.

Just for interest, what are you doing with the java\-kernel? Are you
working on a product?

Bert

---

## Post #9 by @system

> Hi Bert,
>
> I think we are speaking of openehr-demographic-person.person.draft.adl
> archetype. I think it should be designed like this:
>
> PERSON[at0000] matches { -- person demographics
> identities matches {
> PARTY_IDENTITY[at0001] matches { -- legal name
> name matches {
> CODED_TEXT matches {
> code matches {[ac0001]} -- legal name
> }
> }
> details matches {
> ...
>
> instead of
>
> PERSON[at0000] matches { -- person demographics
> identities matches {
> PARTY_IDENTITY[at0001] matches { -- legal name
> purpose matches {
> CODED_TEXT matches {
> code matches {[ac0001]} -- legal name
> }
> }
> details matches {
> ...
>
> because, as far as I understood, purpose is a function, not an attribute,
> according to the rm specification.
> Therefore, it is not in the list of attributes of PARTY_IDENTITY that
> could be constrained by an archetype.
>
> If you think it is the archetype that is wrong, then everything else seems
> to be consistent for me, doesn't it?
> On the other hand, if the archetype is to be kept like it is now, then I
> agree with you that several changes must be done, the rm specification
> included.
>
> By the way, I reviewed the rm-builder code and I have two comments:
> 1) In method loadTypeMap, in line 67, DvQuantityRatio should be replaced
> by DvProportion, according to the 1.0.1 specification, right?;
> 2) For the sake of clarity, the local variable typeMap in method construct
> (line 241) could be renamed to something like attributeTypeMap in order to
> not be confounded with the typeMap class attribute .

Thanks, Sergio!
The rm-builder is still stuck on the 0.95 branch and needs to be migrated to the trunk. We need to keep a todo list for this task and probably put it in the wiki.
/Rong

---

## Post #10 by @system

> Hi Bert,
>
> I think we are speaking of openehr-demographic-person.person.draft.adl
> archetype. I think it should be designed like this:
>
> PERSON[at0000] matches { -- person demographics
> identities matches {
> PARTY_IDENTITY[at0001] matches { -- legal name
> name matches {
> CODED_TEXT matches {
> code matches {[ac0001]} -- legal name
> }
> }
> details matches {
> ...
>
> instead of
>
> PERSON[at0000] matches { -- person demographics
> identities matches {
> PARTY_IDENTITY[at0001] matches { -- legal name
> purpose matches {
> CODED_TEXT matches {
> code matches {[ac0001]} -- legal name
> }
> }
> details matches {
> ...
>
> because, as far as I understood, purpose is a function, not an attribute,
> according to the rm specification.
> Therefore, it is not in the list of attributes of PARTY_IDENTITY that
> could be constrained by an archetype.
>
> If you think it is the archetype that is wrong, then everything else seems
> to be consistent for me, doesn't it?

Hi Bert, Sergio

I think the same way as Sergio. It's the archetype that needs to be updated according to the specification. If we would have an archetype validator that checks archetypes against RM class and attribute names/types, this archetype wouldn't pass validation. This is not difficult to do and will be very useful to have. It's good to catch this type of errors early on.

Cheers,
Rong

---

## Post #11 by @Sergio_M_Freire

Hello Bert,

> I must say, that I
> don't work with the latest version of the specs, I am somewhere between
> 0\.95 and 1\.0\.1\. This is because, I am almost ready with a working
> kernel, also persistence, and archetype\-interpretation, and rm\-builder\.
> I have my own code, but heavily based on the work of Rong\.
> When I am ready, and it is stable, I will fully migrate to 1\.0\.1 which
> is not that hard to do\.
>
> Just for interest, what are you doing with the java\-kernel? Are you
> working on a product?
>
Thanks for the interest\. I work as an assistant professor at the State
University of Rio de Janeiro\.
I intend to do some research about the openehr approach and maybe develop
some information systems to be used at our hospital\.
Right now, I am studying the specifications and their corresponding
implementations\. Until I get some software running, I envisage going
through the same path as yours and raising the same issues as you do\.
That´s why I read your messages with great interest\.

Regards,

Sergio

---


**Canonical:** https://discourse.openehr.org/t/partyidentity-purpose/16013
**Original content:** https://discourse.openehr.org/t/partyidentity-purpose/16013