Message-ID: <769119011.70426.1448780930163.JavaMail.confluence@ece-vmapps> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_70425_2086326061.1448780930163" ------=_Part_70425_2086326061.1448780930163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The ABS (Australian Bureau of Statistics) is currently developing a= Metadata Registry and Repository (MRR) aligned with GSIM. While alig= ned with GSIM, the definition of objects for the ABS MRR wil= l requires attributes additional to those which are defined = in GSIM as a generic model.
A question has arisen in this regard when it comes to the modelling of <= em>Unit in the GSIM V1.0 specification.
The three examples given all relate to indivudal people, companies etc.&= nbsp; Being able to identify a specific unit in this way is important when,= eg, populating a register/frame or the unit identifier fiel= d in a unit record file.
It is very common also, however, to talk about "types" of= statistical units (eg persons, families, enterprises, regis= trations, transactions)
While related, the concept of an indivudal unit and the concept of a typ= e of unit don't seem equivalent. It seems unlikely, therefo= re, that "persons" is simply a Unit in the same way= as an individual person.
The alternative of saying "persons" is a Population a= lso seems awkward. A Population will usually have at least s= ome form of temporal and spatial scope. In theory "persons"= as a unit type refers to all persons ever born, or yet to be born in the f= uture. This seems different in concept to the population, eg,&nb= sp;of persons on Planet Earth (which would typically only include= people who were alive at a particular time).
A couple of possibilities come to mind for capturing "uni= t type" as an attribute. The attribute might be, eg, popula= ted from an extensible controlled vocabulary of recognised unit types = (at an agency specific or international level).
The attribute could be applied to Unit. This might (= or might not) imply the list of unit types should be limited to&n= bsp;mutually exclusive "base types". (At the conceptual lev= el, are Dan Gillman as a Person and as an Employee referring to two differe= nt Units?)
Perhaps it would be more appropriate to attach the attribute to Population to describe the "type" of Units (which = would be subject to more detailed scoping in the definition of the Popu= lation) from which the Population is composed. For= example US persons and Australian persons are
Unit Type could be added as an object in its own right. This would= allow Unit Type to have attributes and relationships of its own -= including with other Unit Types. For example, it would be p= ossible to define "Employee" as a specialisation of the &quo= t;Person" Unit Type. (If "Legal Entity" = were ever a Unit Type it might be a specialisation applicable= to either "Person" or "Corporation"?)
I think that adding a new object tends to add more complexity to th= e model than adding a new attrribute to an existing object. Option 3 = would need to add significant advantages over Option 1 or Option2= in order to justify the extra complexity?
Would you recommend other options b= e considered instead, or would you recommend one of the options listed= above instead of the others?