ŠĻą”±į > ž’ Ä Ę ž’’’ Ā Ć ’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’ģ„Į [ šæ w¬ bjbjā ā "ž j j ž§ x ’’ ’’ ’’ l Ŗ |: |: |: 8 “: Š: Ŗ .^ ¬ ų; ų; : 2< 2< 2< C C C ] Æ] Æ] Æ] Æ] Æ] Æ] $ Ś_ śa ` Ó] C mA Ø C C C Ó] ŃC 2< 2< ; č] ŃC ŃC ŃC C ^ 2< 2< ] ŃC C ] ŃC
ŃC ŪF Ŗ V | X 2< ģ; `
#\»ĀŖ Ņ8 |: sC ^
W X ¤ ž] 0 .^ W ź Zb ŃC Zb X ŃC Ŗ Ŗ Ł Ive reread all of the documents available and the e-mail from both groups prior to the September meeting when they were combined. There is some overlap in these groups because at least a few of the issues in how we describe aggregate data are used for describing geographic features of aggregate data. The following discussion covers the following:
Theoretical base
Definitions
Goals for the February Meeting
Issues
Possible solutions
Theoretical Base:
Josteins paper and the recent e-mails from Ann, Peter, and Cavan, keep bringing us back to some basic questions:
What is the coverage intent of the DDI?
How rigid are the structural divisions?
What belongs in an individual DDI XML instance and what should go into accompanying pieces that can be pointed to from a number of XML instances, and what belongs in proprietary or applications based systems?
How do we coordinate with other groups with a common interest in social science data description (ex. Mediera) or with related groups (ex. Geographers dealing with FGDC and related structures)? In particular, how do we make sure that we are not creating a structure intimately linked or driven by a specific project?
Please note that these are my thoughts on these topics. I wont even say that it necessarily reflects any form of consensus; simply that it is the base that I work from and may help others understand my position on definitions, goals, issues and solutions.
Coverage Intent of DDI
The DDI covers:
Descriptions (in bibliographic terms) of the DDI XML instance itself (1.1) and its source materials (1.2).
Description of how the data file came into existence including the intent, coverage, process and primary study output (files, support files, methodology reports, preliminary analysis) (2.0). Much of this information, particularly lengthy text or materials related to multiple data sets is housed outside of the XML instance and is pointed to from elements/attributes within the instance. In combination, these two sections house the majority of elements common to the DDI and other systems used for DISCOVERY. [Note that the only element noted in the DDI and FGDC Mapping is 3.1.5 fileType and the attribute URL (located in a variety of places) which provide digital transfer information rather than content discovery information.]
Gross description of the physical files comprising the dataset [3.1]. This covers the number and size of files, the number of records, how files relate to one another and how records within or between files relate to one another. More detailed information on the structure of individual records and pointers to their content description (variable or nCube coordinates) is now found in locMap [3.2]. While this information is still currently found in 4.2 var under location in many microdata sets, these were retained only to maintain backward validity.
Description of the logical content of the variables and nCubes, in the case of aggregate data, is found in 4.0.
Other related materials related to the data are found in 5.0.
While these reflect the contents of the traditional codebook and related materials, there seems to be an underlying intent to provide the information needed to work with the data sets and not prescribe presentation of data or to provide application specific processing instructions. Some may argue that this is because the DDI was originally written for microdata and we could not control how the data was analyzed, only provide sufficient information to support the intelligent and appropriate use of the data. I feel this is equally true of aggregate data. I am not saying that presentation information should never be provided or that information that allows the replication of the original layout. I am stating, however, that the current structure does not support this and that any effort to incorporate this into the DDI should be done in a separate and new section. In terms of application specific information, I think this is beyond the scope of the DDI.
Structural Divisions
The structural divisions noted above were reinforced with the creation of the locMap. Prior to this recommendation section 4.0 contained both physical and logical content information. locMap helps to clarify this division. However, it does not address the issues of 2- or 3-dimentional storage systems, nor does it adequately address how to locate specific records in a file [unique units of analysis]. This is true of both hierarchical files where the information related to an individual respondent may be in multiple records of multiple types (Segment 1, Segment 2, etc. OR Household, Family, Person), and of aggregate files where unique analysis units are often geographic polygons identified by geographic codes in which the variable required to make a unique identification vary by the value of a particular variable. This is the case of U.S. Census data where the unique identification of an area is a combination of the summary level [SUMLEV] and one or more of over 15 geographic coding fields.
I think the current structural divisions are important for another reason. They assist outside groups using other descriptive standards to understand exactly how deep they need to go in the DDI structure on order to obtain various levels of access to the data described in the DDI specification. Very general discovery information is found in sections 1.0 and 2.0. Physical information for obtaining full-files (size, format) or record subsets (instructions for identifying complete logical records and unique respondents) would be in section 3.0 and very specific content information (variable and category level) is found in section 4.0. Thinking about how external search engines (non-DDI specific) search for discovery and access information helps us to enhance the DDI contents in such a way that needed information is easier for them to find.
Contents of a Single DDI XML Instance
My basic rule is that whatever is shared by multiple data sets and is in a common structure should be outside the DDI XML instance. This includes methodology information shared by all the data sets created from a specific years Census or series of surveys such as the Current Population Survey or the Eurobarometer. Standardized codes also fall into this category. Listing the full set of occupation codes, industrial codes or geographic codes in each XML instance is not only consumes space, but also make it difficult to correct errors or to match categories between data sets. Of course this rule should not be taken to extremes (5 year age cohorts, sex/gender etc.). However, extensive standardized listings or those where it is difficult to create a unique category value and associated label (county codes with states) should be prime candidates for standCat pointers.
This said, to be effective, standard categories need to be stored in well-defined structures and accessible in predictable ways. Where it was functional to refer a person to an image file or ASCII file of occupation codes, it doesnt work for a computer. If we are going to make effective use of standard categories we need a prescribed storage structure and authority site OR a means of describing the storage structure of the category values and labels and the relationship between categories and hierarchies.
Finally, informational contents of DDI elements need to be in a format that a computer can consistently understand and process. This is particularly true of derivation formulas. We have not included a structured means of explaining how derived variables are formulated. Free ASCII text is inadequate for relating often complex mathematical formulas. This is particularly true if the description is a processing statement for a proprietary data processing tool that the user may not be familiar with or can change with new versions of the software. We should be recording information at its base level and letting the processor/programmer to translate it to an individual system.
The other category of information that belongs outside of a specific DDI XML instance is information detailing the relationship of variables or categories between two or more DDI XML instances. For example, given the variety of way that five-year age cohorts are listed in various data sets (under 5, 5 9 years, 10 14 years
OR less than 5 years of age, 5 to 9 years of age, 10 to 14 years of age,
the possibilities are infinite). How do these relate to each other and how are they constructed from single-year or non-standard range categories? This is an issue we need to address in the NHGIS project, but we hope to do so in a way that can be shared by other data processors outside of this project. Im sure there are other similar situations. This should not be taken to an extreme, for example if a data set is part of a larger series or is routinely used in conjunction with another data set and inclusion of the information aids the user directly.
Coordination with Other Specifications Both Inside and Outside of Social Science Data
There is no easy answer to this in terms of ensuring exhaustive coverage. We need to be particularly concerned that we stay aware of and make contacts with other groups who either use social science data extensively or as specific auxiliary files for their primary work. For example, globally there are not strong connections between empirical data users and statistical file data users. Data that can be used to look-up a specific piece of information has a broader group of users with a greater range of knowledge and expertise. This could affect both element content and possibly the type of information that needs to be recorded. For those who use data as auxiliary files (geographers who work extensively with map or shape files), we need to incorporate their needs into the information we record and note how their systems expect to find it. A good example is geographic search systems that search by point coordinates and prune search space using bounding boxes. They then match data for specific geographic areas (polygons, points, or lines) using standardized geographic codes or standard coordinate systems. This means they have specific informational needs that may not be met by DDI information or may be recorded in a way that is not discrete enough for their needs.
Making sure developments are not driven by particular systems is more difficult. There are only a small number of projects utilizing DDI for a variety of purposes (discovery, extraction and manipulation). Because of this they tend to discover problems of existing elements (content, specificity, consistency) as well as information needs not addressed by the DDI in its current format. For those groups already involved in the DDI it is a matter of making these issues known to the full group, determining if others have similar problems or have a possible means of dealing with the information need within the current DDI structure. In short, getting the discussion started about the problem and its specifications rather than on a possible solution for a problem that has not been sufficiently explored. A process of problem/issue identification, fully described problem/issue specifications, possible solutions, structured testing of solutions and recommendations to the committee for changes should be followed. We need to work more cooperatively and in less isolation
easier said than done. Specialists should be sought both inside of DDI and outside for specific issues, particularly if they involve overlap with other specifications. However, the development of final recommendations for changes to the DDI need to be crafted by people who have a deep understanding of the DDI structure and underlying concepts.
Definitions
nCube: An nCube is the description of the logical structure of a matrix. Each cell of an nCube has one and only one intersect point with each and every dimension. In a non-nested category nCube, if the cells are additive, the sum of all the cells equals the universe. An nCube is defined by its dimensions, universe, measurement unit, and scale of measurement. The following basic examples show what constitutes the logical nCubes in three common presentations of aggregate data.
Presentation with sub-totals and totals:
< 18 years of age18 years of age and overTOTAL by SexMale20 3050Female104050TOTAL by Age3070100
nCube 1 = Total Population [gray]
nCube 2 = Population by Age [blue]
nCube 3 = Population by Sex [pink]
nCube 4 = Age by Sex [yellow]
Presentation with hinged nCubes
WhiteNon-White< 18 years of age18 years of age and overMale35152030Female40101040
nCube 1 = Sex by Race [yellow]
nCube 2 = Sex by Age [blue]
Because both nCube descriptions refer to the variable SEX, which appears only once in the XML instance, the computer can infer that these two nCubes can be hinged for display purposes.
Presentation with two different measurement units and/or scale:
Male:Female:CountPercentCountPercent< 18 years1020%612%18 to 64 years1020%1428%65+ years510%1020%
nCube 1 = Age by Sex (measure: count) [blue]
nCube 2 = Age by Sex (measure: percent) [yellow]
Because the dimension description of each is identical (and assuming the universe is also), the two nCubes can be displayed together in an interlaced fashion by adding the unique measurement information where appropriate.
Geographic Data Files: Geographic data files are those that describe geographic areas and are typically maps of various types, shape files (that define the boarders of polygons), line or point files that are used to define and describe geographic space. These files may or may not have related statistical data associated with them. The geographic data files area described using various standards (ISO, FGDC and others). The files use identifiers for points (coordinates), lines (coordinate pairs), and polygons (unique codes and/or names) to link statistical data to the appropriate geographic feature.
Geographic elements in social science data: These are the fields used to identify the overall geographic coverage of the data set, lowest geographic level represented within the data set, and the elements used in defining and/or identifying specific geographies (the links to the geographic areas).
Bounding Box: A bounding box is a geographic means of defining a coverage area in its simplest form. It consists of the coordinate pairs for each corner of the minimum box required to enclose the geographic area in question along the lines of latitude and longitude. Bounding boxes may overlap. They are used to prune search space on a global search.
Goals for the February Meeting
Finalize the core structure of the aggregate data descriptions (nCube, dimensions, coordinates, measure, locMap)
Make a recommendation on nesting categories in var
Add elements and attributes that will improve our ability and the ability of external search engines to identify geographic coverage and features
Propose a test model for describing concatenated variables
Propose a test model for describing unique record identification strings (particularly in the area of geographic coding schemes)
Propose a test model for accurately describing the relationship between categories and category groups within a single variable and between variables
Propose topics for future work: rendering mathematical formulas, structure for standard category information external to the DDI XML instance, others(?)
All proposed models, elements and attributes should include a schema drawing, XML DTD section and Tag Library, plus examples and best practice recommendations.
Issues
I have tried to break these out into topical groups and then into specific areas of the DTD.
Aggregate data structures:
Essentially we are still struggling with the details of how to apply the proposed Voorburg Compromise model. Some of the issues raised were due to typographical errors in the original DTD or model submission or the lack of a Tag Library to work from. Some are the result of trying to apply the various approaches provided within the model and then creating programs to process the information constantly. Others are areas where more structure is needed or earlier recommendations for additional structure require approval.
var
Identifying temporal (time) variables or dimensions
Identifying geographic variables or dimensions
Recording hierarchical nature of categories within variables and the hierarchical nature of some related variables
Use of other and total attributes on the catgry element
Ability to create "virtual variables" based on concatenating non-adjacent strings/variables
Describing how to identify unique records when the unique string changes by either record type or by the value of a variable within the record (a particular problem with geography but not exclusive to geography)
Describing mathematical formulas for defining cell contents or category contents (derivation of a variable and its categories)
nCube
Application and repeatable nature of cohort element
Assigning sub-set dimensions to a cube (application of cohort element)
Application of measure element (specifying aggregation methods, nature, additivity)
Geography:
The geographic component is really trying to address the needs of two constituencies, the social science data user and the geographic data user who needs to locate and link social science data to geographic data files for mapping and spatial analysis. Social science data users need to 1) know what geographic levels and areas are available, and 2) have sufficiently detailed information to be able to select data for specific locations. Geographic data users need to be able to identify overall coverage, the type and codification of geographic variables (point, line, polygon), specific levels of data availability, and the availability of specific locations.
Ability of geographic search engines to discover:
coverage
geographic type (point, line polygon)
availability of geographic levels (state, city, tract, block etc)
availability of data for a specific location
Ability to reference maps
Storage structures:
As noted earlier, an attempt was made to describe multidimensional storage structures in the Voorburg Comprise. These were not accepted because they required further testing. To date, no further testing has been done.
Storage specifications for 2 and 3 dimensional data stores such as cubes, spread sheets, layered spread sheets
Ability to describe multicubes (multidimensional construction formed from several nCubes sharing one or more dimensions) storage relationships
Presentation structures:
Presentation structures are not currently addressed by the DDI.
Lack of presentation layer information
Ability to describe mulitcubes (multidimensional construction formed from several nCubes sharing one or more dimensions) presentation relationships
Possible Solutions:
Identification of temporal (time) and geographic variables and dimensions
The following solution was raised at the June 2002 meeting, but no action was taken. Recommendation: remove the timesDmns [4.3.12] from the nCube description and add two attributes to the element var [4.2] as follows:
temporal Y|N default N
geog Y|N default N
This allows for easy identification of multiple temporal and geographic variables in both aggregate and microdata datasets.
Describing the hierarchical nature of categories within a variable or between variables (categories of one variable being the equivalent of the category groups of another variable).
The Voorburg Compromise model attempted to address this through the use of nested categories. From the comments provided by Jostein, my experience with the NHGIS project and discussions with ICPSR and the California Counts group, it would seem that nested categories create more processing problems than they solve.
Recommendation: remove the nested category feature in var [4.2.18.5]
Note that this negates the need for attributes "total" and "other" that were added to var and these should be removed.
[Does this also eliminate the need for the Completeness and Exclusiveness attributes suggested by Jostein's paper?]
This leaves us with the standard catgyGrp element to create nested categories where the categories themselves represent only the smallest units. Jostein's example of the nesting patterns of communes and sub-communes shows this usage. If a stored table of information contained sub-totals for the 3 counties and for Norway as a whole, then it would be described by 3 nCubes each containing one of the following three variables:
1Norway
Norway
1Aust-Agder
2Rogalnd
3Hordaland
Regional Classification
Norway
Aust-Agder
Rogalnd
Hordaland
Bergen
102Commune 2
201Commune 4
203Commune 6
302Commune 8
312Sub-Commune 2
Jostein has noted that he does not think the catgryGrp nesting is clear without addition level numbers and level names. The description above, without the additional information, is laid out as follows:
Commune 1Aust-AgderCommune 2Commune 3Commune 4NorwayRogalndCommune 5Commune 6Commune 7HordalandCommune 8BergenSub-Commune 1Sub-Commune 2
While the groupings are clear there is no indication of names for the levels.
Recommendation: Add the attributes Levelno and Levelnm to the element catgryGrp [4.2.17]
The use of catgryGrp is effective in instances where no sub-totals are provided and where the sub-totals can be derived from the contents of the units comprising the sub-totals. For example, population figures with no suppression. Difficulties arise when the data in the smallest units is suppressed due to confidentiality or other concerns. It is also a problem when more than one category group structure could apply to the categories within a variable.
What is missing is a means of relating the following pairs:
var COUNTRY catgry C1 WITH var V1 catgryGrp G0
var CNTY catgry C01 WITH var V1 catgryGrp G01
var CNTY catgry C02 WITH var V1 catgryGrp G02
var CNTY catgry C03 WITH var V1 catgryGrp G03
If the relational information is housed in the var then this limits the number of category links that can be relayed in the documentation. Is there an alternative using the varGrp? At best we could probably only prepare a concept for testing at this point. Another alternative is to recommend that this be a specific item for a working group to consider.
Defining "virtual" variables or set variable combinations for linking or selecting records when the variables involved are not contiguous and/or where the combination changes based on the value of another variable.
Examples:
Unique geographic code for Tract 1.01 in Hennepin County in Minnesota for the 1990 Census
SUMLEV.STATEFP.CNTY.TRACTBNA
where SUMLEV = 140
STATEFP = 27
CNTY = 053
TRACTBNA = 000101
14027053000101
Unique identification code for RECORD TYPE = REC-3 in a hierarchical file where each logical record has multiple parts (one logical record definition for household records consisting of 2 physical records and one logical record definition for person records consisting of 3 physical records) resulting in:
REC-1 = Household physical segment 1
REC-2 = Household physical segment 2
REC-3 = Person physical segment 1
REC-4 = Person physical segment 2
REC-5 = Person physical segment 3
element TYPE = H or P
element PART = 1, 2 or 3
unique identifier for each record segment would be TYPE.PART:
RECTYPE TYPE PART Unique string
REC-1 H 1 H1
REC-2 H 2 H2
REC-3 P 1 P1
REC-4 P 2 P2
REC-5 P 3 P3
Application:
Current link allows only a single IDRef to a variable that serves as the link between two record types; creation of a derived variable defined by the concatenation of 2 or more existing variables allows for nested or hierarchical links involving multiple variables in a set pattern.
In the US Census, and other files with complex geographies, the unique identification string for a specific area will vary by the type geographic area (tract, city, county, metropolitan area, etc.). In addition, more than one unique geographic string may exist. This is true in 1980 and 1990 census files that provide both FIPS codes and Census codes for many area types. Each value of an area type could have its unique string or strings identified in a manner that would allow for computer processing of the information.
SUGGESTED SOLUTION:
Borrow the following elements from MathML* to create a single definitional string from defined variables.
[other presentation structures and elements from MathML may be introduced in order to expand functionality for other purposes]
mrow mrow is a wrapper containing presentation expression mi. It creates a single string without spaces consisting of the individual elements described within it.mi identifier [for the purposes of DDI the attributes must include varRef in addition to base attributes]
Examples:
The unique identification string for a full tract is:
SUMLEV.STATEFP.CNTY.TRACTBNA
where the var ID's are as follows:
ID = VU01SUMLEVID = VU41STATEFPID = VU22CNTYID = VU15TRACTBNA
SUMLEV
STATEFP
CNTY
TRACTBNA
The result is a single string composed of these identifiers.
where SUMLEV = 140
STATEFP = 27
CNTY = 053
TRACTBNA = 000101
The final string would be:
14027053000101
*MathML is designed to facilitate layout of mathematical formula in print or displayed documents by describing the single formula string as a composition of component parts.
Describing mathematical formulas for defining cell contents of category contents (derivation of a variable and its categories).
I have made an exploratory look at MathML and OpenMath but am not prepared to put together a recommendation right now. MathML is designed to accurately layout out a mathematical formula including superscripts, subscripts, vertical relationships (above and below a line for example) and so forth. A brief example of how this could work in the DDI follows:
Examples:
Borrow the following elements from MathML* to create a single definitional string from defined variables.
[other presentation structures and elements from MathML may be introduced in order to expand functionality for other purposes]
mrow mrow is a wrapper containing presentation expression mi. It creates a single string without spaces consisting of the individual elements described within it.mi identifier [for the purposes of DDI the attributes must include varRef in addition to base attributes]mn number mo operator
We would need to look more carefully at how subscripts, superscripts, other bounding symbols are incorporated (see section 2 and section 3 of MathML).
Examples:
Average household income where:
AVEHHINC = average household income
AGGHHINC = aggregate household income
HHCOUNT = number of households
AVEHHINC = AGGHHINC / HHCOUNT
where the var ID's are as follows:
ID = V01AVEHHINCID = V02AGGHHINCID = V03HHCOUNT
AVEHHINC
=
AGGHHINC
/
HHCOUNT
The result is a single string composed of these identifiers.
where SUMLEV = 140
STATEFP = 27
CNTY = 053
TRACTBNA = 000101
The final string would be:
14027053000101
Recommendation: Incorporate the minimum needed to create concatenated variables within the element var [4.2] so that we can identify strings for linking or selection. Further that we explore the elements of MathML and OpenMath (and others if they are more commonly used) and determine what would be needed to allow us to include mathematical formula in a structured way. This is one area where we can borrow from other sources and increase our interoperability with other systems.
Application of the element cohort [4.3.13.1]
The questions in Jostein's paper regarding cohort may stem from the errors in the first publication of the proposed DTD. Both cohort [4.3.13.1] and range [4.3.13.1.1] are repeatable allowing multiple cohorts or cohort ranges to be included. The attribute catRef was supposed to be singular allowing for a new value to be attached to confer order within a specific nCube coordinate pattern. One example of this could be the use of only a selected number of categories from the variable STATES, where the selection criteria was region membership and the order did not match that found in the original variable. Range would be used for contiguous subsets such as just the clerical occupations in a full listing of detailed occupation codes.
One point brought up was that the element cohort implied inclusion of the category and that there may be instances where a number of categories were excluded. This could be addressed with the use of ranges for those categories surrounding the excluded categories. Should an attribute clusion be added as follows to cohort?
clusion I|E default I
Does this address the problem noted in Jostein's paper?
The purpose and application of measure [4.3.14] and its attributes.
The current description of measure in the Tag Library for locMap and nCube under version 1.03 appears to address the issue. What other changes need to be made?
Accurate and complete discovery access to geographic coverage, geogrpahic type, availability of data at specific geographic levels, and the availability of data for a specific location.
Geography is identified in a number of different ways and each has its difficulties:
name space: names can change over time, include varient spellings, and refer to one or more physical spaces over time. Often specific names are located within the data set itself rather than the metadata, or is located in an auxiliary system such as a gazeteer.
coding schemes: coding schemes provide unique identities not possible with names. However, a number of different coding schemes are in place and data sets use a variety of them and sometimes use more than one coding scheme within a single data set. Unique identification of an area often relys on a string of codes (for example: State--County--County Subdivision where the county subdivision code is unique within a given country and the county code is unique within a given state), Once again the complete list of codes is often available only within the data set or in an auxiliary system.
grid coordinates: these can be single point, lines, or polygons of 3 or more points used to define the bounds (or complete boundaries) of polygons.
The geographic areas for which data is collected and reported may also vary by type of geograhic unit (point, line, polygon), completeness of coverage (all levels from smallest to largest, selected levels only, specified subsets of level such as cities of over 10,000). Currently the DDI provides only the following indicators for geography.
geogCover: The definition of this element matches the Dublin Core definition using free text to convey the overall coverage and intervening levels included in the dataset. FGDC limits this field to the overall coverage area.
nation: providing the name space and ISO code.
geogUnit: The lowest level of geography available in the data set.
At an earlier point a recommendation was made to include a temporal and geog attribute to var [4.2] to identify these specific types of variables. This is the bare minimum that is needed to improve geographic identification. The earlier Geographic Working Group met with members of the Center for Spatially Integrated Social Science (CSISS) and the Alexandria Project (gazeteer work) to discuss the levels of overlap required between social science data files and geographic files. It was recognized that social science data files often contain on minimal geographic identification, but that in general, these brief geographic items provide the link or access to a link to match social science and geographic data files. In particular the CSISS noted that it always asked the following questions of social science data sets:
Do the geographic identifiers refer to points, lines or polygons?
Can I identify the overall coverage area by coordinate points, name or standard code?
For polygons, what levels are available (this is particularly important because the availability of intermediate levels is not always clear and cannot always be constructed from lower level data)?
Do you have data for a specific location?
If we approach the problem of geography like peeling an onion we may be able to begin to address the needs of both geographers and social science data users.
Recommendation: Incorporate the following elements and attributes. The suggestion for this minimum set and verification of their usefulness was confirmed by the CSISS staff, one of whom now works for ESRI.
The following is a tag library for incorporating the elements from the Geography Markup Language (GML) into the DDI DTD. The reason is that these elements make up elementary geometry for which should be recognized in almost every discipline. That is, it is a least common denominator when dealing with space.
Recommendation: Add the attribute vocab to geogCover [2.2.3.4] and geogUnit [2.2.3.5] to permit th euse of different controlled vocabularies like FIPS codes, Census designations, etc.
Recommendation: Incorporate the ability to create concatonated variables as described earlier using the minimal number of elements from MathML.
This should be available for use in drvcmd [4.2.22.2] when describing the creation of an entire variable and also under catgry [4.2.18]. The use of these elements under catgry allow for the definition of a catgry with a specific value to have its content derived from different strings of variables.
Recommendation: Include an attribute geoID (IDRef) in geogUnit [2.2.3.5] that points to variable that provides a listing of the geographic levels available in the dataset (as well as thier unique value representations if the MathML elements are incorporated here. There is also a recommendation that this go in anlyUnit [2.2.3.6]. However, microdata sets also have geographic level information when the unit of analysis is an individual and having geoID in 2.2.3.6 may be confusing.
This still leaves specifics about instructions for identifying specific places (through sending a query to the data owner) divided between sections 2.0 and 4.0. Ideally this information should be in section 2.0
Recommendation: Further discussion and testing of the following approach.
Examples:
Currently (even with suggested additions), section 2 provides only the overall geographic coverage and the smallest geographic unit in a format that can be processed and understood by a computer. For example coverage is US and smallest geographic unit is a census tract. Not only does this not provide structured information regarding the variety of available geographies frequently found in aggregate data files, the availability of data for a specific geographic area cannot be determined through the metadata.
If the file contains data for "Places of 10,000 or more population"
Is there data for Edina, Minnesota?
Two pieces of information are needed here. First, a listing of all the available geographies and the variable that identifies a geographic area type. Second, one or more unique strings for identifying a specific area (geographic polygon).
SUGGESTED SOLUTION:
Add a sublevel to sumDscr (2.2.3) between geogUnit (2.2.3.5) and anlyUnit (2.2.3.6)
ELEMENT geogAvail* (mrow*;)
ATTRIBUTES ID, xml:lang, source
varRef [variable: geographic type identifier]
value [catagory value of var]
ELEMENT mrow* (mi*;)
ATTRIBITES ID, xml:lang, source
ELEMENT mi* (PCDATA;)
ATTIBUTES ID, xml:lang, source
varRef [variable of identifier]
Examples:
1990 Census file with State, County and Tract level records only. There are both Census and FIPS codes for States.
STATEFP
STATECE
STATEFP
CNTY
STATECE
CNTY
STATEFP
CNTY
TRACTBNA
STATECE
CNTY
TRACTBNA
Availability of Maps
Jostein's paper suggests a solution to this problem as follows:
The actual reference to the map that corresponds to the geographical identification should in both situations be made from the geoId-variable. This can be done in several ways, but given the existence of hierarchical geographical dimension, we will need a more complex structure. We will propose the following:
Add an element under 4.2.7 (or directly under 4.2) that is called geoMap and let this be a repeatable element to allow for several levels in the geographical hierarchy. The geoMap-element should then have a mapId-attribute that points to the external map that can be used to display the data (using a URL) and a level levelNo-attribute that indicates the relevant level in the geographical hierarchy (corresponding to the levelNo-attribute that propose for description of hierarchies). A format-attribute might also be needed in order to indicate the format of the map (with a controlled vocabulary pointing to standard map formats)
A simple example with only one level might look like this:
human readable info
A more complex example with several levels in the hierarchy might look like this:
human readable info
human readable info
I think this needs further discussion. It is not clear if these refer only to pre-created output formats (static maps), files that would allow for spatial analysis of the data or mapping of the data in some way or something else.
Description of multi-dimensional storage structures and presentation structures.
Neither of these areas has been addressed and there does not seem to be a proposal put forward that addresses these to areas in a comprehensive manner. I think that some of the map references noted above are matters of presentation (although I could be very wrong about that).
Recommendation: Both of these areas be addressed by separate working groups with a priority on multi-dimensional storage structures.
DDI Aggregate and Geographic Working Group
AUTHOR Wendy Thomas Page PAGE 1 DATE \@ "M/d/yyyy" 1/13/2003
· É ” ø ² Ē -
' c' ō1 2 2 2 K4 T4 W4 _4 e4 h4 v4 |4 4 5 5 5 5 5 5 7 "7 &7 (7 ,7 <7 ?7 C7 F7 J7 U7 W7 [7 ^7 b7 ®8 Ä8 ; 7; 8< E< = ŗ= A A ēA B
D D ĪF ŌF £G ®G DJ /K CK L M 4M tM 0N CN N åN õN (P ŻP ÷ ń ń ń ń ÷ ļ ķė ķė éē ķé ķé éķéķ éķéķ éķéķ ļ ļ ļ ÷ ÷ ąÜŲ Ų ąÜ ąÜ ąÜ ĢÅ Ą ÅOJ QJ OJ QJ ^J 5CJ OJ QJ \^J 5\ 6] 56\] * * * *5 5CJ aJ CJ OJ QJ aJ L ^ _ p | £ ¶ · É Ź < = e ` ” ø ¹ É 4
; « é ż ż ų ų ų ų ų ż ż ż ż ż ó ó ó ó ż ż ż ż ż ż ī ī ī ī ī
& F
& F
& F ž« v¬ žž é ź ° ² Ē Č “ µ - . E# F# '
' c' d' g, h, ó1 ō1 2 2 į3
4 ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż
4 4 4
4 4 84 E4 F4 K4 Q4 T4 ż ÷ ÷ ÷ ÷ ÷ \H ÷ ÷ ÷ $$If l Ö Ö\ ’:ą," ¦ ¦ ¦ ¦
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö Ö ’ ’ ’ ’Ö ’ ’ ’ ’ Ö ’ ’ ’ ’ Ö ’ ’ ’ ’4Ö 4Ö
l aö $If
T4 W4 X4 _4 b4 e4 h4 i4 v4 y4 |4 ł ^D ł ł ł ł ^` ł ł ł $$If l Ö Ö\ ’:ą," ¦ ¦ ¦ ¦
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö Ö ’ ’ ’ ’Ö ’ ’ ’ ’ Ö ’ ’ ’ ’ Ö ’ ’ ’ ’4Ö 4Ö
l aö $If
|4 4 4 4 ©4 Š4 ų4 5 5 =5 >5 ł ^ \ \ \ \ \ \ \ \ $$If l Ö Ö\ ’:ą," ¦ ¦ ¦ ¦
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö Ö ’ ’ ’ ’Ö ’ ’ ’ ’ Ö ’ ’ ’ ’ Ö ’ ’ ’ ’4Ö 4Ö
l aö $If
>5 ?5 E5 O5 a5 z5 {5 5 5 ł ł ł ł ł KH ł ł ® $$If l Ö Ör ’j
U@," ė ė ė ė ģ
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö Ö ’ ’ ’ ’ ’Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’4Ö 4Ö
l aö $If 5 5 5 5 5 5 5 5 5 ł ł ł KP ł ł ł ł ® $$If l Ö Ör ’j
U@," ė ė ė ė ģ
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö Ö ’ ’ ’ ’ ’Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’4Ö 4Ö
l aö $If 5 5 ”5 ¢5 Å5 ę5 ē5 ¢6 £6 ł K I I I I I I ® $$If l Ö Ör ’j
U@," ė ė ė ė ģ
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö Ö ’ ’ ’ ’ ’Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’4Ö 4Ö
l aö $If £6 ć6 ä6 å6 ė6 ģ6 ō6 õ6 ö6 ż ż ÷ ÷ ÷ ÷ ÷ Fx ° $$If l Ö Ör ’j
U@," ė ė ’’’’ ė ’’’’ ė ’’’’ ģ ’’’’
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö ö Ö ’ ’ ’ ’ ’Ö ’ ’’’’’ ’’’’’ Ö ’ ’ ’ ’ ’ Ö ’’’’’ ’’’’’ ’4Ö 4Ö
l aö $If ö6 ÷6 ż6 7 7 7 7 7 "7 ł ł ł ł ł Hd ł ł ° $$If l Ö Ör ’j
U@," ė ė ė ė ģ
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö ö Ö ’ ’ ’ ’ ’Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’4Ö 4Ö
l aö $If "7 &7 (7 ,7 -7 <7 ?7 C7 F7 ł ł ł Hx ł ł ł ł ° $$If l Ö Ör ’j
U@," ė ė ė ė ģ
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö ö Ö ’ ’ ’ ’ ’Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’4Ö 4Ö
l aö $If F7 J7 K7 U7 W7 [7 ^7 b7 c7 ł H` ł ł ł ł ł H ° $$If l Ö Ör ’j
U@," ė ė ė ė ģ
t ąÖ0 ’ ’ ’ ’ ’ ’ ö 6ö ö Ö ’ ’ ’ ’ ’Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’ Ö ’ ’ ’ ’ ’4Ö 4Ö
l aö $If c7 d7 7 Ė7 Ģ7 8 ®8 ; ; 7< 8< = = ŗ= »= ,> _> ń> -? ®? D@ Ż@ Ž@ ~A A A A ęA ēA ż ż ż ż ż ż ż ż ż ż ż ż ż ż ų ų ų ų ų ų ų ż ż ņ ņ ņ ņ ņ
Ę
& F ēA B
D D ED tD ēD E {E OF ĪF ŌF G OG £G ®G DJ vJ J „J ēJ K /K CK L L M ł ł ł š š š š š š š ł š š š ł ł š ē ē ē ē š ł ł š š
& F
Ę
& F
Ę
Ę M 4M tM M 0N DN EN N N kO lO O ©O ŖO 'P (P ŽP ßP R R cR ŪR ÜR PS QS üT żT U ^U ł ł š š ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł
& F
Ę
Ę ŻP R +R żT [ _\ `\ m\ n\ o\ q\ \ \ Ŗ\ ¬\ ³\ µ\ Ż\ Ž\ ģ\ ī\ ] ] ] ] Ł] Ś] (b žb c c f f Āi Öi åj éj k "k k k ÷k l Ŗn )o p p §q «q āq äq Lr Nr ør ŗr År Ēr ¹t Ćt w w ģx y } Ż} ~ ; ¦ č ś Ō ß ¶
¾
å
ī
Z ū ų ė ė ė ė ė ė ė ė ė ū ų ä ą ą Ś Ó Ó Ó ą ä ą Ó Ó Ó Ó Ó ą ū ä ä ä Ó Ó Ó Ó Ó Ó ū 56\]
6CJ ] 6] OJ QJ ^J j CJ UmH nH u CJ OJ QJ Q^U nU ĮU V RV ”V ÆV ŁV &W ~W ÓW 2X X ĪX Y hY µY Z OZ Z éZ :[ [ [ ]\ ^\ _\ a\ ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ł ļ ļ
Ę $If
Ę a\ k\ l\ m\ o\ |\ \ \ \ \ \ \ \ \ \ \ \ õ õ l õ õ õ õ 8 õ õ õ õ õ õ õ j $$If l Ö\ ’:ą," ¦ ¦ ¦ ¦ ö 6Ö ’ ’ ’ ’Ö ’ ’ ’ ’ Ö ’ ’ ’ ’ Ö ’ ’ ’ ’4Ö
l aö
Ę $If \ \ \ \ \ Ø\ ©\ Ŗ\ ³\ ½\ Ē\ Č\ É\ Ź\ Ė\ Õ\ Ö\ õ < õ õ õ õ | õ õ õ õ 8 õ õ õ õ j $$If l Ö\ ’:ą," ¦ ¦ ¦ ¦ ö 6Ö ’ ’ ’ ’Ö ’ ’ ’ ’ Ö ’ ’ ’ ’ Ö ’ ’ ’ ’4Ö
l aö
Ę $If Ö\ ×\ Ų\ Ł\ Ś\ Ū\ Ü\ Ż\ ß\ é\ ź\ ė\ ģ\ ų\ ] ] ] < d h
Ę $If j $$If l Ö\ ’:ą," ¦ ¦ ¦ ¦ ö 6Ö ’ ’ ’ ’Ö ’ ’ ’ ’ Ö ’ ’ ’ ’ Ö ’ ’ ’ ’4Ö
l aö ] ] ] ] ] ] ] ] !] /] 0] 1] ] ] Ł] Ś] õ õ õ õ H õ õ õ õ
Ę j $$If l Ö\ ’:ą," ¦ ¦ ¦ ¦ ö 6Ö ’ ’ ’ ’Ö ’ ’ ’ ’ Ö ’ ’ ’ ’ Ö ’ ’ ’ ’4Ö
l aö
Ę $If Ś] ¢_ £_ ß_ ą_ ` O` ` Ć` Ä` 'b (b ’b c c ec fc c c £c Æc Āc Ćc Ņc Óc e e +e Pe ł ł ł ł ł ł ł ł ł ł ł ł ł ÷ ÷ ÷ ÷ ÷ ń ÷ ÷ ÷ ÷ ÷ ÷ ÷ ÷ ÷ Š`Š
Ę Pe re e ¶e ·e Ķe ęe ēe %f Ef Sf af of }f f f f “g µg Ąi Įi Āi ×i Ųi ej äj åj ėj k ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ÷ ÷ $If k k k õk ök ÷k l 7l 8l Ul xl yl l l ° $If k $$If l Ö Ö0 ’8," ¤ ō Ö0 ’ ’ ’ ’ ’ ’ ö 6Ö ’ ’Ö ’ ’ Ö ’ ’ Ö ’ ’4Ö
l aö
l l l l l Øl l ®l øl Įl Āl Ćl Źl él m &m Gm L @ P $If k $$If l Ö Ö0 ’ś," f 2 Ö0 ’ ’ ’ ’ ’ ’ ö 6Ö ’ ’Ö ’ ’ Ö ’ ’ Ö ’ ’4Ö
l aö Gm Om Pm m m ¢m Æm »m Īm Ļm źm ėm śm ūm ©n Ŗn *o +o p p p p 'q ¦q §q q Kr ż ż ż ż ż ÷ ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ń ń $If Š`Š Kr Lr Pr ·r ør ¼r Är År Ér Ór Ōr Õr
s Fs \s ls ys ° 4 < $If k $$If l Ö Ö0 ’8," ¤ ō Ö0 ’ ’ ’ ’ ’ ’ ö 6Ö ’ ’Ö ’ ’ Ö ’ ’ Ö ’ ’4Ö
l aö ys s Ūs t t øt ¹t Ćt ćt ät u .u Mu Nu ou pu u u u ¦u ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ÷ ÷ $If ¦u §u °u ¹u ŗu Ću Ėu Ģu Ķu Ōu öu v &v 4v Uv ]v ^v L H $If k $$If l Ö Ö0 ’ś," f 2 Ö0 ’ ’ ’ ’ ’ ’ ö 6Ö ’ ’Ö ’ ’ Ö ’ ’ Ö ’ ’4Ö
l aö ^v v v °v ½v Év Üv Żv ųv łv w w ėx ģx y y ž{ ’{ B} C} _} `} } } Ż} Ž} ~~ ~ ; ż ż ż ÷ ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ń ż ż ż ż ż ż ż ż Š^Š Š`Š ; < č | } Ó Ō ¶
å
( ) b c „ ū Ą ź ė Y Z ł < ~ ż ż ÷ ÷ ÷ ż ż ż ÷ ÷ ÷ ż ż ż ņ ņ ņ ņ ż ż ż ż ż š š š š š
& F Š^Š ~ Ę } Ć F { × Ų 1 A L v w ¬ u · Ņ ’ 3 R } ~ 6 ż ÷ ń ż ń ż ż ÷ ÷ ż ż ż ż ż ÷ ÷ ż ż ż ż ż ż ż ÷ ż ż ż ż Š^Š Š`Š Z ~ 7 F Ē Ć Ņ | Ē Ń - @ Ž č ö¢ ÷¢
£ M£ U„ Z„ n¦ t¦ '© Ŗ `Ŗ x« « ž« +¬ ,¬ 4¬ 5¬ A¬ B¬ H¬ I¬ O¬ P¬ Q¬ R¬ S¬ T¬ h¬ i¬ r¬ s¬ v¬ w¬ ÷ī÷ī÷ ÷ī÷ī÷ź ä ź ÷Ū÷ × × ÷Ū÷ī÷ Ņ ŅĢŅ Ņ ŅĢŅ Ņ ŅĢŅ ÷ mH nH u j U5\ CJ OJ QJ ^J
6CJ ] 6] CJ OJ QJ ^J CJ OJ QJ ^J 26 7 Ē Č ż ? U e r Ć § Ø { | Ę Ē Ń Ó Ō < = , - A B ż ż ū ū ū ū ū ū ū ż ż ż ż ż ż ż ż ū ū ū ū ū ū ū ū ū ū ū ū · į 4 5 K t u “ Ż Ž č é \ ] ® ŗ Å å ń ž $” /” O” l” ż ż ó ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż pŠ^p`Š l” x” ” £” Ą” Ģ” Ł” ’”
¢ *¢ G¢ h¢ t¢ ¢ ¢ ¼¢ Ż¢ é¢ ö¢ ÷¢ £
£ M£ N£
¤ ¤ ’¦ :§ ¾§ æ§ ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ż ū ū ū ū ż ż ż ż ż ż ż æ§ Ø Ø &© '© Ŗ Ŗ `Ŗ aŖ w« x« ž« *¬ +¬ t¬ u¬ v¬ w¬ ż ż ż ż ū ū ū ū ū ū ū ł ż ÷ ż ż ū 1h °Š/ °ą=!°"°# $ %°
i 8 @ń’ 8 N o r m a l CJ _HaJ mH sH tH < A@ņ’” < D e f a u l t P a r a g r a p h F o n t , @ ņ , H e a d e r
Ę ąĄ! , @ , F o o t e r
Ę ąĄ! N B` N B o d y T e x t $hdš ¤š `ha$ CJ OJ QJ aJ @ Z` "@
P l a i n T e x t CJ OJ QJ \^J aJ wØ ž ’’’’ ^ _ p | £ ¶ · É Ź < = e ` ” ø ¹ É 4 ; « é ź ° ² Ē Č “ µ - . E F #
# c# d# g( h( ó- ō- . . į/
0 0 0
0 0 80 E0 F0 K0 Q0 T0 W0 X0 _0 b0 e0 h0 i0 v0 y0 |0 0 0 0 ©0 Š0 ų0 1 1 =1 >1 ?1 E1 O1 a1 z1 {1 1 1 1 1 1 1 1 1 1 1 1 ”1 ¢1 Å1 ę1 ē1 ¢2 £2 ć2 ä2 å2 ė2 ģ2 ō2 õ2 ö2 ÷2 ż2 3 3 3 3 3 "3 &3 (3 ,3 -3 <3 ?3 C3 F3 J3 K3 U3 W3 [3 ^3 b3 c3 d3 3 Ė3 Ģ3 4 ®4 7 7 78 88 9 9 ŗ9 »9 ,: _: ń: -; ®; D< Ż< Ž< ~= = = = ę= ē= >
@ @ E@ t@ ē@ A {A OB ĪB ŌB C OC £C ®C DF vF F „F ēF G /G CG H H I 4I tI I 0J DJ EJ J J kK lK K ©K ŖK 'L (L ŽL ßL N N cN ŪN ÜN PO QO üP żP Q ^Q nQ ĮQ R RR ”R ÆR ŁR &S ~S ÓS 2T T ĪT U hU µU V OV V éV :W W W ]X ^X _X aX kX lX mX oX |X X X X X X X X X X X X X X X X ØX ©X ŖX ³X ½X ĒX ČX ÉX ŹX ĖX ÕX ÖX ×X ŲX ŁX ŚX ŪX ÜX ŻX ßX éX źX ėX ģX ųX Y Y Y Y Y Y Y Y Y Y !Y /Y 0Y 1Y Y Y ŁY ŚY ¢[ £[ ß[ ą[ \ O\ \ Ć\ Ä\ '^ (^ ’^ _ _ e_ f_ _ _ £_ Æ_ Ā_ Ć_ Ņ_ Ó_ a a +a Pa ra a ¶a ·a Ķa ęa ēa %b Eb Sb ab ob }b b b b “c µc Ąe Įe Āe ×e Ųe ef äf åf ėf g g g õg ög ÷g h 7h 8h Uh xh yh h h h h h h Øh h ®h øh Įh Āh Ćh Źh éh i &i Gi Oi Pi i i ¢i Æi »i Īi Ļi źi ėi śi ūi ©j Ŗj *k +k l l l l 'm ¦m §m m Kn Ln Pn ·n øn ¼n Än Ån Én Ón Ōn Õn
o Fo \o lo yo o Ūo p p øp ¹p Ćp ćp äp q .q Mq Nq oq pq q q q ¦q §q °q ¹q ŗq Ćq Ėq Ģq Ķq Ōq öq r &r 4r Ur ]r ^r r r °r ½r Ér Ür Żr ųr łr s s ėt ģt u u žw ’w By Cy _y `y y y Ży Žy ~z z ;{ <{ { | č~ | } Ó Ō ¶ å ( ) b
c
„
ū
Ą ź ė Y Z ł < ~ Ę } Ć F { × Ų 1 A L v w ¬ u · Ņ ’ 3 R } ~ 6 7 Ē Č ż ? U e r Ć § Ø { | Ę Ē Ń Ó Ō < = , - A B · į 4 5 K t u “ Ż Ž č é \ ] ® ŗ Å å ń ž $ / O l x £ Ą Ģ Ł ’
* G h t ¼ Ż é ö ÷
M N
’¢ :£ ¾£ æ£ ¤ ¤ &„ '„ ¦ ¦ `¦ a¦ w§ x§ ž§ *Ø +Ø tØ xØ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 © 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 0 0 0 0 0 0 0 0 0 © 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 © 0 0 0 0 0 0 0 0 0 0 © 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 © 0 0 © 0 © 0 © 0 © 0 © 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 DF 0 DF 0 DF 0 DF 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 « 0 « 0 « 0 « 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 « 0 « 0 0 « 0 « 0 0 0 0 0 0 0 0 0 « 0 « 0 0 « 0 « 0 0 « 0 « 0 0 « 0 « 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 « 0 « 0 0 « 0 « 0 0 « 0 « 0 0 « 0 « 0 0 0 0 0 0 0 0 0 0 @ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 « 0 « 0 0 « 0 « 0 0 « 0 « 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 @ 0 @ 0 @ 0 @ 0 0 0 0 0 0 0 0 0 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 @ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 @ 0 @ 0 @ 0
0 - - w w w z ŻP Z w¬ X i z é
4 T4 |4 >5 5 5 £6 ö6 "7 F7 c7 ēA M ^U a\ \ Ö\ ] Ś] Pe k l Gm Kr ys ¦u ^v ; ~ 6 l” æ§ w¬ Y [ \ ] ^ _ ` a b c d e f g h j k l m n o p q r s t u v w x y { | } ~ v¬ Z - 6 C J Q S U j t z ’!’ ’ š8 š @ ń ’’ ’ ÷ šņ š š š( š
š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š š šH B
š
C š D æ ’ š
š šH B
š
C š D æ ’ š
š šH B
š
C š D æ ’ š š šB
š S š æ Ė ’ ? š _X mX oX pX X ŖX «X ³X “X ŻX ģX ķX Y Y wØ ¶ ¦ : Z t F p ~ t ¶ F : ® t ¶ F : F t N : ö t . p f t . p . t
N ā : t N ā ī ā t ¶ v : * t
¶ : ~ t ¶ ī Ź t k ø Ó t k ø k t M N
8£ 9£ ¾£ æ£ ¤ ¤ '„ ż§ ž§ uØ xØ M N
8£ 9£ ¾£ æ£ ¤ ¤ '„ ż§ ž§ uØ xØ ’’ W e n d y T h o m a s W e n d y L . T h o m a s U C : \ W I N D O W S \ A p p l i c a t i o n D a t a \ M i c r o s o f t \ W o r d \ A u t o R e c o v e r y s a v e o f a g g - g e o g o v e r v i e w . a s d W e n d y L . T h o m a s E : \ d d i \ a g g - g e o g o v e r v i e w . d o c W e n d y L . T h o m a s E : \ d d i \ a g g - g e o g o v e r v i e w . d o c W e n d y L . T h o m a s E : \ d d i \ a g g - g e o g o v e r v i e w . d o c W e n d y L . T h o m a s E : \ d d i \ a g g - g e o g o v e r v i e w . d o c W e n d y L . T h o m a s E : \ d d i \ a g g - g e o g o v e r v i e w . d o c W e n d y L . T h o m a s E : \ d d i \ a g g - g e o g o v e r v i e w . d o c ÖĪ @ś’’’’’’’’’ õ/šąuč’’’’’’’’’ Ėk{OfÕN’’’’’’’’’ M6`Ą4-’’’’’’’’’ 1v®ć4’’’’’’’’’ xQæv&wīa’’’’’’’’’ h ŠžĘ Š^Š`žOJ QJ o( ·š h žĘ ^ `žOJ QJ o( o h pžĘ p^p`žOJ QJ o( §š h @ žĘ @ ^@ `žOJ QJ o( ·š h žĘ ^`žOJ QJ o( o h ąžĘ ą^ą`žOJ QJ o( §š h °žĘ °^°`žOJ QJ o( ·š h žĘ ^`žOJ QJ o( o h PžĘ P^P`žOJ QJ o( §š h ŠžĘ Š^Š`ž . h žĘ ^ `ž . h pL’Ę p^p`L’ . h @ žĘ @ ^@ `ž . h žĘ ^`ž . h ąL’Ę ą^ą`L’ . h °žĘ °^°`ž . h žĘ ^`ž . h PL’Ę P^P`L’ . h ŠžĘ Š^Š`žOJ QJ o( h H ·š h žĘ ^ `žOJ QJ ^J o( h H o h pžĘ p^p`žOJ QJ o( h H §š h @ žĘ @ ^@ `žOJ QJ o( h H ·š h žĘ ^`žOJ QJ ^J o( h H o h ąžĘ ą^ą`žOJ QJ o( h H §š h °žĘ °^°`žOJ QJ o( h H ·š h žĘ ^`žOJ QJ ^J o( h H o h PžĘ P^P`žOJ QJ o( h H §š h ŠžĘ Š^Š`žOJ QJ o( h H ·š h žĘ ^ `žOJ QJ ^J o( h H o h pžĘ p^p`žOJ QJ o( h H §š h @ žĘ @ ^@ `žOJ QJ o( h H ·š h žĘ ^`žOJ QJ ^J o( h H o h ąžĘ ą^ą`žOJ QJ o( h H §š h °žĘ °^°`žOJ QJ o( h H ·š h žĘ ^`žOJ QJ ^J o( h H o h PžĘ P^P`žOJ QJ o( h H §š h ŠžĘ Š^Š`žOJ QJ o( h H ·š h žĘ ^ `žOJ QJ ^J o( h H o h pžĘ p^p`žOJ QJ o( h H §š h @ žĘ @ ^@ `žOJ QJ o( h H ·š h žĘ ^`žOJ QJ ^J o( h H o h ąžĘ ą^ą`žOJ QJ o( h H §š h °žĘ °^°`žOJ QJ o( h H ·š h žĘ ^`žOJ QJ ^J o( h H o h PžĘ P^P`žOJ QJ o( h H §š h
ŠžĘ Š^Š`žh H . h
žĘ ^ `žh H . h
pL’Ę p^p`L’h H . h
@ žĘ @ ^@ `žh H . h
žĘ ^`žh H . h
ąL’Ę ą^ą`L’h H . h
°žĘ °^°`žh H . h
žĘ ^`žh H . h
PL’Ę P^P`L’h H . xQæv Ėk{O 1v M6` õ/š ÖĪ ’’’’’’’’’’’’’’’’’’’’’’’’’’ ’’ 0
0 0 80 E0 F0 K0 Q0 T0 W0 X0 _0 b0 e0 h0 i0 v0 y0 |0 0 0 >1 ?1 E1 O1 a1 z1 {1 1 1 1 1 1 1 1 1 1 1 1 ”1 ä2 å2 ė2 ģ2 ō2 õ2 ö2 ÷2 ż2 3 3 3 3 3 "3 &3 (3 ,3 -3 <3 ?3 C3 F3 J3 K3 U3 W3 [3 ^3 b3 c3 ^X _X aX kX lX mX oX |X X X X X X X X X X X X X X X X ØX ©X ŖX ³X ½X ĒX ČX ÉX ŹX ĖX ÕX ÖX ×X ŲX ŁX ŚX ŪX ÜX ŻX ßX éX źX ėX ģX ųX Y Y Y Y Y Y Y Y Y Y !Y /Y 0Y äf åf ėf g g g õg ög xh yh h h h h h h Øh h ®h øh Įh Āh ¦m §m m Kn Ln Pn ·n øn ¼n Än Ån Én Ón Ōn q q q ¦q §q °q ¹q ŗq Ćq Ėq Ģq xØ " ¾ " " ¾ " ¾ " " ¾ " ¾ " ¾ " ¾ ’@ &„ &„ H: &„ &„ wØ @ ’’ U n k n o w n ’’ ’’ ’’ ’’ ’’ ’’ G : ’ T i m e s N e w R o m a n 5 S y m b o l 3& : ’ A r i a l ?&
A r i a l B l a c k 9 G a r a m o n d ?5 : ’ C o u r i e r N e w ; W i n g d i n g s " 1 šŠ h äbqalq&ļkq& } M
F ' 0 c4 o ! š “ “ 0 d Ŗ = 0J 2Q š H ’’ W e n d y T h o m a s W e n d y L . T h o m a s ž’
ą
ņłOh« +'³Ł0 ¬ ø Š Ü č ü
< H T
` l t | ä s s
Wendy Thomas o end end Normal.dot s Wendy L. Thomas 12 d Microsoft Word 9.0 @ .åüX @ ¢MM»Ā@ @7aŗĀ@ ń\»Ā M
ž’
ÕĶÕ. +,ł®0 č h p | ¤ ¬ “
¼ É ä ' F Ŗ 2 Title
! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~ ž’’’
” ¢ £ ¤ „ ¦ § Ø © Ŗ « ¬ ® Æ ° ± ž’’’³ “ µ ¶ · ø ¹ ž’’’» ¼ ½ ¾ æ Ą Į ž’’’ż’’’ż’’’Å ž’’’ž’’’ž’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’R o o t E n t r y ’’’’’’’’ Ą F ąą#\»ĀĒ 1 T a b l e ’’’’’’’’’’’’ Zb W o r d D o c u m e n t ’’’’’’’’ "ž S u m m a r y I n f o r m a t i o n ( ’’’’ ² D o c u m e n t S u m m a r y I n f o r m a t i o n 8 ’’’’’’’’’’’’ ŗ C o m p O b j ’’’’ j O b j e c t P o o l ’’’’’’’’’’’’ ąą#\»Āąą#\»Ā ’’’’’’’’’’’’ ž’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’ ž’
’’’’ Ą F Microsoft Word Document
MSWordDoc Word.Document.8 ō9²q