[DDI-users] Documenting rates in the aggregate data extension

Wendy Thomas wlt at pop.umn.edu
Tue Mar 9 11:04:12 EST 2004


Sorry I didn't read this as fully as I should have before responding.
While we still do need the option of percent as an aggMeth, it does not
solve the additivity issue. In a one dimensional nCube percents can be
additive (assuming that they are a percent of the expressed universe),
some multidimensional nCubes expressed in percents are also additive. The
problem is multidimensional nCubes that are additive in one direction
only. The only way to express these as additive at the moment would to be
break them into their single dimension componants defining the universe as
the category of the other dimension. For example an AGE by SEX table where
the percents totalled 100 for each sex would be broken into two nCubes one
with the universe Males and one with the universe Females. If you use the
basic definition of an additive nCube that sums to its universe, you don't
have any option but to split them in definition and then "hinge" them in
display along the age dimension.

And definately, a means of expressing simple to complex formulas for
derivation purposes is needed in the DDI for both aggregate data and for
derived variables in microdata files.

Wendy Thomas


On Tue, 9 Mar 2004, Jostein Ryssevik wrote:

> Hi
>
> I am not sure if I understand you correctly, but why cant you use a
> none-additive nCube for this purpose? There will of course always be limits
> to what you can do (software-wise) with none-additive aggregates, but that
> will always be the case independent of the metadata specifications.
>
> If you could include the raw numbers that are used to calculate the rates
> in the cube you would of course be better off, but than you would need a
> way to specify the actual calculation formula. This is missing in the
> current DDI-spec. At least if this is going to provide generic solution a
> simple aggMeth=percent" would not help you much.
>
> Jostein Ryssevik/Nesstar
>
>
>
>
> At 14:50 09.03.2004 +0000, Humphrey Southall wrote:
> >The DDI aggregate data extension is very clearly designed to document
> >tables consisting mainly of frequency counts.  What should we do with
> >pre-computed percentages?
> >
> >My project is converting existing machine-readable transcriptions of
> >tables from British census reports to a structure which uses DDI-based
> >metadata, and most of the columns in those tables are just such counts of
> >numbers of people.
> >
> >They also contain columns which are pre-computed rates, generally
> >percentages.  Most of them can be derived directly from counts held in
> >other columns in the same table, and so far we have mostly ignored
> >them;  we are not discarding them, as the system will also hold
> >spreadsheet versions of the original tables, but they will not be easily
> >located, or accessible to our visualisation tools.
> >
> >However, there are some rates in the reports which contain information not
> >available in any other form.  The most immediate issue is with data in the
> >main parish-level table from the 1951 census for England and Wales.  This
> >includes population density, which can easily be computed from figures for
> >population and area, and "Persons per Room", computable from the number of
> >persons and the numbers of rooms in private households.  However, it also
> >includes "Percentage of persons at more than 2 per Room".  Although
> >another table gives plenty of information about numbers of people versus
> >numbers of room, by household, for c. 1,500 districts from which this rate
> >could be computed, no other information is available for the c. 15,000
> >parishes.  The micro-data are official secrets until 2052, and as far as
> >we can establish no unpublished intermediate calculations from pre-1971
> >censuses survive anywhere -- so this is really interesting data.
> >
> >How can we include these data values in our system?  I can see that just
> >about any number can be held in a non-additive nCube, but that greatly
> >limits what we can do with it.  Is there another structure we should be using?
> >
> >Best wishes,
> >
> >Humphrey Southall
> >
> >====================================
> >Humphrey Southall
> >Reader in Geography/Director,
> >Great Britain Historical GIS Project
> >Department of Geography, University of Portsmouth
> >Buckingham Building, Lion Terrace, Portsmouth PO1 3HE
> >
> >GIS Project Office: (023) 9284 2500
> >Home office:  (020) 8853 0396
> >
> >Web site:       http://www.VisionOfBritain.org.uk
> >About us:       http://www.gbhgis.org
> >
> >_______________________________________________
> >DDI-users mailing list
> >DDI-users at icpsr.umich.edu
> >http://www.icpsr.umich.edu/mailman/listinfo/ddi-users
>
> -------------------------------------------------------------------------------------------------------------------
> Jostein Ryssevik                                        Tel:  +47 5558 2654
> Director of Technology and Development                  Mobil: +47 9181 7197
> NESSTAR Ltd.                                            http://www.nesstar.com
> NESSTAR Ltd is a wholly owned subsidiary of the
> UK Data Archive and the Norwegian Social Science Data Services
> -------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> DDI-users mailing list
> DDI-users at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-users
>

Wendy L. Thomas                          Phone: +1 612.624.4389
Data Access Core Director		 Fax:   +1 612.626.8375
Minnesota Population Center              Email: wlt at pop.umn.edu
University of Minnesota
537 Heller Hall
271 19th Avenue South
Minneapolis, MN 55455



More information about the DDI-users mailing list