Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Reply by Dan Gillman

Thank you for clearly describing this problem.  When we were modeling GSIM, I knew we didn't really have Units right, but I figured we would get back to it later.  I guess later is now.

As you point out, there are 3 ideas in use, and we have modeled 2 of them.  Those 3 are

  1. the units being observed
  2. the population the units belong to (which as you say has time and space attributes)
  3. the type of units being observed

#1 and #2 are already modeled in GSIM.  As for #3, Sundgren and others refer to this as an Object Type.  Given that we are already using the term Unit to mean something else (#1), then I propose we use Object Type or possibly Unit Type to refer to #3.

I am afraid there is no good, direct way to account for all 3 classes with the 2 we have.  Your example where Dan Gillman (#1, a Unit) is both an employee (#3, Object Type) and person (#3, another Object Type) is exactly right.  Likewise, some Unit (Dan Gillman) might be a member of many Populations (#2), such as US Federal Employees in 2013 or Persons in the US in 2013.  Finally, the Object Type is related to Population in the obvious way by seeing that Object Types are constituents, just as time (e.g., 2013) and space (e.g., US) are.  Object Types may be specialized, e.g., going from Employee to Federal Employee.

It looks like Object Type should replace Poulation as a role for a Concept, and Population becomes an intersection of Object Type, Time, and Space.  How this is done isn't clear right now, we may have to reconvene a group to think it through.  In any case, I think your Option 3 is the way to go.  Option 2 will work, but I like the purer approach in Option 3, and we don't know right now if having Object Types as a class in its own right will simplify other problems that crop up.  Option 2 is much more constraining.

Stats Can put together good lists for Object Types (called Object Classes as they are in 11179) about 10 years ago.  They should be incorporated.  The basic kinds are consistent with work Sundgren did to help make the creation of SDMX DSDs easier.


ABS Problem Statement

The ABS (Australian Bureau of Statistics) is currently developing a Metadata Registry and Repository (MRR) aligned with GSIM.  While aligned with GSIM, the definition of objects for the ABS MRR will requires attributes additional to those which are defined in GSIM as a generic model.


I think that adding a new object tends to add more complexity to the 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 be considered instead, or would you recommend one of the options listed above instead of the others?