[DDI-ADG] Latest Geography Structure - Take 2

[J Gager]

My concern with this approach is that it creates a level of ambiguity.
I don't like that one would have to repeat a geography if it is both the
highest level, and has data.
 
I think the intent of the original approach is that any geography would
be defined in one and only one place.  The coverage can be identified by
determining the highest level (any geography without a parent - or an
alternative would be another attribute to indicate a geography is the
highest level).  Secondly, whether a geography containing data is
identified by an attribute or a tag name is arbitrary - they both
accomplish the same thing in the end.
 
Anyway, that is my 2 cents.  Anyone else want to weigh in?
 
J

-----Original Message-----
From: Katherine McNeill-Harman [mailto:mcneillh at MIT.EDU] 
Sent: Monday, July 25, 2005 5:13 PM
To: J Gager; DDI-ADG
Cc: gey at berkley.edu
Subject: Re: [DDI-ADG] Latest Geography Structure - Take 2


To continue the geography thread:

Continuing our discussion last week, I'd suggest two edits to the
spreadsheet, a revised version is attached; throwing out several ideas
for discussion, so look forward to others' reactions/additional ideas:

1) I do believe we should enable some sort of structured description of
geographic coverage (that is the overall coverage of the study) to
enable machine actionability on that.  (e.g. I'm imagining some great
search interface in the future that has fields for both geographic
coverage and geographic level, each of which act on structured metadata)

It seems we have two options for doing this:

a) Right now we just have a place in geographic coverage for a textual
description, which provides little/no ability for machine actionability
within that section.  However, presumably all overall coverage areas
would also be listed as a geographic level, whether or not there's data
available at that level (hence, the sub-element of Geography to indicate
whether or not that level "HasSummaryData."  Each of those can contain
structured GeographyValues.

b) I would propose the alternative, as I think it's a bit more direct.
I recall us deciding that we would have separate elements for the
overall coverage vs. geographic levels (i.e. those levels at which
there's data in the study).  I believe that we said that in the case
when the geographic coverage/overall area is also a level at which
there's data available (e.g. the overall coverage is of a country, but
you can also get info. at the country level, not simply at lower levels
like state or province), that we would repeat the description of that
area in both the geographic coverage and the geographic level elements.

However, as compared to what's in "a," I would propose only repeating
the overall coverage area in Geography if indeed it is a level at which
data is available (therefore eliminating the for "HasSummaryData,"
because all levels in there would have data).  Instead, I propose to
enable more structured description of the Geographic Coverage within
that section itself.  So I've put in there a place to indicate
GeographyValues, structured information about the coverage of the study
(e.g. if it's a country, the author could insert a standard country code
that could be machine-actionable).  I know some people said in the phone
conversation that if we were to do this it should be called something
other than GeographyValues.  I put that in, but others may have ideas
for a better name. [Note, now that something like GeographyValues sits
w/in GeographicCoverage, I'm not sure what would be the relationship
between the BoundingBox and the Bounding Polygon that's optional w/in
GeographyValues].

2) Plus, I wonder about the hierarchical relationships among the
elements in the spreadsheet.  Right now everything is under "Geographic
Coverage," when in fact this term is referring to a specific aspect of
geography that to me isn't logically the "parent" (is that the right use
of the term?) over the other things.  I would propose one of two
alternatives (listed on sheet 1 and 2 in the attached), and don't know
which make more sense structurally.
a) if we want everything nested under one geographic element (option 1),
then I'd create an additional overall element that's simply a container
for all the others; I've actually named it Geography, b/this seemed like
a logical overall name, and renamed the previous "Geography"
"GeographicLevel," as this seemed a little more descriptive.
b) If there is no need for a top-level element, then I'd flatten it and
put GeographicCoverage and GeographicLevel at the same level in the
elements.

Not having worked much with version 2.0, some of these ideas may be
wacky, but I'll at least put them out there and see what others say.
Look forward to email discussion on this.

Kate

At 12:31 PM 7/19/2005 -0400, J Gager wrote:


Sorry for the previous message - I accidently hit send...
 
Here is the latest work up of the Geography structure, I have worked in
Wendy's comments and part of our discussion today.  We have decided it
is time to wrap this up so that we can move on to the our other tasks -
Time and Aggregate Data.  The plan is that the geography will continue
to be reviewed and reworked between meetings via this email list.  We
should really focus on the definitions, as they are admittedly lacking.
Also, it would be helpful to have a few use cases described.  If there
are any major issues, we can discuss them at the end of our weekly
meetings.
 
Thanks,
 
J

_______________________________________________
DDI-ADG mailing list
DDI-ADG at icpsr.umich.edu
http://www.icpsr.umich.edu/mailman/listinfo/ddi-adg

___________________________________________
Katherine McNeill-Harman
Data Services Librarian
Dewey Library for Management and Social Sciences
Massachusetts Institute of Technology
77 Massachusetts Avenue, E53-100
Cambridge, MA 02139
mcneillh at mit.edu
617-253-0787 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.icpsr.umich.edu/pipermail/ddi-adg/attachments/20050725/9e118228/attachment.html