[DDI-ADG] Latest Geography Structure - Take 2

Tue Jul 26 09:09:42 EDT 2005

At 09:05 AM 7/26/2005, 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

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