[DDI-ADG] Geographic/spatial elements
Wendy Thomas
wlt at pop.umn.edu
Thu Jun 9 09:54:46 EDT 2005
The material you are looking at in the spreadsheet was a first attempt to
sort out the current DDI elements into the modules of the conceptual
model. Some things were added to reflect conversatoins within the SRG, the
Expert Group, and the former DDI group, or to provide a means of
pointing/linking to reusable classes.
Label is a class that would be defined once and reused. However, unlike
the "reusable classes" it is a class that will get nested into other
structures such as variable, category, variableGroup, ncube, ncube group
etc. I think it is the name "reusable class" here that is confusing.
The SRG is looking at the various classses (elements) and making sure that
those that are used in a number of different situations are used
consistantly. Needless to say, the more eyes on this particular piece the
better, so if you find multiple occurances (particularly with different
uses) let me know.
Regarding "overrides": definitions at a higher level of the tree are
overriden by lower level definitions. For example: If the Wrapper Module
has a defined topical coverage of "Households, Families and Persons" and
individual data file structure may only have "Persons". In the same way a
particular label could be a subset of a large time, language, or country
set.
I want to clarify only thing about the "reusable class" as it related to
the module. The content of the "reusable class" must be linked or related
to elements within the module. For example:
<module>
<contentA>
<contentB>
<contentC-1></contentC>
<contentC-2></contentC>
</contentB>
</contentA>
<reusableClass-1></reusableClass-1>
<reusableClass-2></reusableClass-2>
</module
if <contentA> points to the <reusableClass-1> then it applies to
everything within <contentA>. If <contentC-2> pints to <reusableClass-2>
then it overrides in that particular instance.
Am I correct in this J?
So the real point in the current label structuring is...does it serve a
purpose that is different from the purpose of the geographic and time
cover in the reusable class? If not, perhaps it should be handled by the
reusable class. For example, define each county once in the reusable
classes and then point the labels to that information.
Language is probably an issue you don't want to get into within this
group, primarily because there have been long discussions about this
already and it is so much broader than the identification of the language
of the PCDATA expressed within the element. Language will be addressed in
version 3.0 in a more extensive and integrated way. You won't lose any
functionality you currently have (I did not put in the standard attributes
for every element in the spreadsheet or it would have been 3-4 times as
large) and if there are specific language needs that see should be
addressed, relay that information to the SRG via J or I. You don't need to
solve it...just point it out.
As for finding multiple uses (reuses) of the same element or attribute,
its already been done by running a program over the element names and
noting multiple uses. Our primary concern in this was to identify
element/attribute names that had multiple definitions or applications so
that these could be renamed with single definitions.
Sorry for the length of the note...hope it helps
Wendy
On Thu, 9 Jun 2005, Mary Vardigan wrote:
> Thanks, Wendy. I am wondering how the reusable class Universe (subject,
> geography, and time) relates to the attributes on the label (the ones I
> found in various label elements are country, language, time, date, year).
> That is, would there ever be a situation in which one would override the
> other?
>
> It looks as if the reusable classes apply at the module and/or element
> level. In that case, would we maybe want to design a reusable class
> (Universe or something else) to hold general attributes that encompass the
> attributes on the various labels? Should label itself be part of a reusable
> class? Maybe we should review at all the generic (i.e., reusable) elements,
> like label, from Version 2.0? Again, I hope this doesn't get us too far
> afield from our subject matter, but want to advance the discussion. Also,
> in Version 2.0, I think language was available on every element as part of
> the XML syntax.
>
> Mary
>
> At 10:00 AM 6/8/2005, Wendy Thomas wrote:
> >Geographic/Spatial elements/attributes are found at the following
> >locations:
> >
> >Resuable Class:
> > Universe
> > SpatialCoverage
> >
> >LogicalProduct (both basic and nCube)
> > Variable
> > geographic [a logical Y|N switch to identify a geographic variable]
> > geogrpahicVocabulary [identifies coding scheme used ex. NUTS2, FIPS]
> >
> > label [found in Variable, VariableGroup, nCube, nCubeGroup,
> >DimensionVariable]
> > country [allows for the association of a country code for labels that
> >differ by country - example: wording difference between UK and Germany]
> >
> >
> >Note that the use of "country" in label limits geographic differntiation
> >between labels based on country rather than a more generalized geographic
> >unit. For example: I cannot use this to indicate that in Minnesota the
> >Party name for the Democratic Party is Democratic-Farmer-Labor Party
> >whereas in the rest of the US its Democratic Party.
> >
> >The use of the geographic (Y|N) and geographicVocabulary [controlled
> >vocabulary identifier] is for the specific purpose of informing a program
> >that this field can be used for geographic identification and the coding
> >structure being used. Many files contain the same information in multiple
> >coding schemes. The intent was to flag these....there are multiple ways to
> >do this if you want a more centralized reference.
> >
> >Location of these items within the DDI-Version3-SRG_TagNames spreadsheets:
> >
> >SpacialCoverage:
> > sheet: REUSABLE CLASSES
> > lines: 49-69
> >
> >geographic and geographicVocabulary:
> > sheet: PKG LOGICAL PRODUCT - BASIC (repeated in variable in "- nCube")
> > lines: 48-49
> >
> >county (within label):
> > sheet: PKG LOGICAL PRODUCT - BASIC (repeated in variable variableGroup
> >and dimensionVariable in - nCube)
> > lines: 20, 52, 84, 95
> > sheet: PKG LOGICAL PRODUCT - nCube (in addition to repeated classes)
> > lines: 127, 192
> >
> >
> >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
> >50 Willey Hall
> >225 19th Avenue South
> >Minneapolis, MN 55455
> >
> >_______________________________________________
> >DDI-ADG mailing list
> >DDI-ADG at icpsr.umich.edu
> >http://www.icpsr.umich.edu/mailman/listinfo/ddi-adg
>
> Mary Vardigan
> Director, Collection Delivery
> Inter-university Consortium for Political and Social Research (ICPSR)
> University of Michigan
> P.O. Box 1248, Ann Arbor, MI 48106-1248
> Phone: 734-615-7908
> Fax: 734-647-8200
> www.icpsr.umich.edu
>
> _______________________________________________
> DDI-ADG mailing list
> DDI-ADG at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-adg
>
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
50 Willey Hall
225 19th Avenue South
Minneapolis, MN 55455
More information about the DDI-ADG
mailing list