[DDI-ADG] Latest Geography Structure - Take 2

[Katherine McNeill-Harman]

Picking up on this again...

It's hard to be crystal clear via email.  I'm not sure about the issue of 
whether or not to repeat geography.  My recommendation was to list both the 
overall geographic coverage and the levels of geography (knowing that an 
area might be represented in both in some cases, but the purpose of the two 
fields is different).

On your #1 below, I did intend for there to be a textual description of the 
GeographicCoverage.  I'd put in there a placeholder for GeographyValues (or 
some other such element), not to describe the geographic level (that would 
be w/in the GeographicLevel element) but rather to provide a standardized 
way to describe the GeographicCoverage.  This provides for both a code 
under GeographicLevelCode and a textual description under 
GeographicLevelName (this probably should be required, which I didn't note, 
so that there's at least a description even if it doesn't have a 
code).  Again, I just used GeographyValues b/it was convenient; my main 
goal was to have w/in the GeographicCoverage element a place to indicate 
both a textual description and a code.

R.e. #2 below, I was thinking of repeating if the area of 
GeographicCoverage was also technically a geographic level.  I'm not sure 
if a different kind of nesting is necessary if the area of 
GeographicCoverage is not a geographic level.

Hope this helps to clarify,
Kate

At 09:05 AM 7/26/2005 -0400, Sanda Ionescu wrote:
>Hi.
>I agree with what Katherine is proposing, with two "amendments":
>1. We should leave in the textual description ("Description") of 
>GeographicCoverage, for those instances where we do not have data at this 
>level, or, even if we do have data, for people who want to spell out the 
>total coverage in plain English. Both values and description should be 
>made optional.
>2.If we create yet another container for everything (initially 
>GeographicCoverage was thought of as a container) then the highest 
>"Geography" should be nestable under Geographic Coverage (since we're no 
>longer repeating this level as a Geography.)
>Cheers,
>Sanda.
>
>p.s. - Last minute changes for today's call - please e-mail me directly: 
>sandai at icpsr.umich.edu. Fred - are you taking the call in Ilona's office, 
>or at another number?
>
>
>At 05:13 PM 7/25/2005, Katherine McNeill-Harman wrote:
>>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
>>_______________________________________________
>>DDI-ADG mailing list
>>DDI-ADG at icpsr.umich.edu
>>http://www.icpsr.umich.edu/mailman/listinfo/ddi-adg
>
>
>
>Sanda Ionescu,
>Research Associate
>Inter-university Consortium for Political and Social Research (ICPSR)
>The University of Michigan
>P.O. Box 1248
>Ann Arbor, MI 48106
>
>Phone: (734) 615-7890
>Fax: (734) 615-7890
>        (734) 647-8200

___________________________________________
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