Print

Print


This is a very interesting issue.  In MARC, the 662 field was set up specifically to deal with this, being both more and less flexible.  We have:

·         $a Country or larger (continents, planets,etc.)

·         $b First political subdivision (State, Province, etc.)

·         $c 2nd political subdivision or a region (County, mountain range, etc.)

·         $d City

·         $e Subsection of a city (neighborhood, street)

·         $2 source of data

 

Like all systems, the final use should determine the arrangement and in Geography & Map Division, the 662 is utilized for all online maps to create an index that would sort in a somewhat logical manner.  We use the LC Authority files (name and subject) as the source for our data.  This still leaves us with some decisions on how to handle qualifiers: a good example of this is Red River, N.M. which is both a river and a town.  The town is in the Name Authority as  Red River (N.M.) and the river is in the subject authority as Red River (N.M. : River).  Because there is nowhere else to put it in the 662, we add the qualifier at the end of the 662:

 

662   $a United States $b New Mexico $c Red River (River)

 

If I was to convert this to MODS, I could use the placetype to good advantage:

 

<hierarchicalGeographic>

            <country>United States</country>

            <state>New Mexico</state>

            <placeOther placeType="river">Red River</placeOther>

   </hierarchicalGeographic>

 

I am using <placeOther> because I don’t know if you can use “placeType” with <area>; if you can, I would prefer the latter, as my other rivers would be in <area>

 

There are plenty of other examples I could give and I am sure all of you can think of these, too.

 

The information below is good and I like the flexibility the placetype provides for dealing with issues such as qualifiers. 

 

Colleen

 

Colleen R. Cahill

Digital Conversion Coordinator and

    Recommending Officer for Fantasy and Science Fiction

Geography & Map Division

Library of Congress

101 Independence Ave. SE

Washington, DC 20540-4650

W: 202-707-8540

Fax: 202-707-8531

[log in to unmask]

These opinions are mine, Mine, MINE!

 

 

From: Metadata Object Description Schema List [mailto:[log in to unmask]] On Behalf Of Denenberg, Ray
Sent: Tuesday, February 04, 2014 8:30 AM
To: [log in to unmask]
Subject: [MODS] FW: HierarchicalGeographic Proposal

 

Please see the proposal below that was posted December 27.  There has been no response, and the MODS Editorial Board has a call scheduled for tomorrow during which we will decide whether to approve the proposal.  If you have comments please post them by tomorrow morning before 10AM EST.

 

--Ray

 

From: Denenberg, Ray
Sent: Friday, December 27, 2013 2:40 PM
To: [log in to unmask]
Subject: HierarchicalGeographic Proposal

 

The MODS Editorial Board has been discussing the MODS <hierarchicalGeographic> element for quite some time, following up on discussion here a few months ago.  See http://listserv.loc.gov/cgi-bin/wa?A2=ind1308&L=MODS&P=R268&I=-3&X=7B5B726607F43F158C

 

We think that hierarchicalGeographic will merit a full overhaul when we move to version 4.   But  we think that there are a few useful changes that we can make  for the next version (3.6).  For now, we wish to discuss possible 3.6 changes (and defer discussion of 4.0 changes until later). 

 

The following changes to <hierarchicalGeographic>  are proposed for MODS version 3.6.

 

1. <placeOther> Element
The subelements of <hierarchicalGeographic> are place types, like <continent>, <country>, <province>, etc.  So you can only represent a place type if it is one of these elements.  While we propose to add a few subelements for commonly used  place types (discussed next), it is also proposed that subelement <placeOther> be defined, with uncontrolled attribute @placeType.

 

Example:

    <hierarchicalGeographic>

            <country>United States</country>

            <state>Rhode Island</state>

            <city>Providence</city>

            <placeOther placeType="neighborhood">Blackstone</placeOther>

   </hierarchicalGeographic>

 

2. Additional Subelements for Place Types

It is proposed to define a few additional subelements for commonly used place types.  We don't have a specific list of types to propose and we welcome suggestions, but examples that have been discussed are <borough>, <park>, and <street>.

 

3. Indication of hierarchical level

It is proposed to define an attribute @level for all place type elements. 

 

@level  would of course be optional; there would be no need for it for simple case like the following where the hierarchy is easily inferred:

            <country>United States</country>

            <state>Rhode Island</state>

            <city>Providence</city>

 

But there are a few cases where this would be useful:

·         With the introduction of <placeOther>, it will be useful to be able to indicate where the value fits within the hierarchy.

·         The actual hierarchy of the existing place types for hierarchicalGeographic isn't always clear, and in some cases depends on the context.

·         It will be useful to be able to indicate that two places have the same level.

·         In cases where the same place type is supplied more than once, it is necessary to indicate their levels relative to one-another.

 

To elaborate of the latter two points:

 

Consider the following example, where Blackstone is a sub-neighborhood of East Side, in Providence.

    <hierarchicalGeographic>

            <country level="1">United States</country>

            <state level="2">Rhode Island</state>

            <city level="3">providence</city>

            <placeOther placeType="neighborhood" level="4">East Side</placeOther>

            <placeOther placeType="neighborhood" level="5">Blackstone</ placeOther>

   </hierarchicalGeographic>

 

That Blackstone is a sub-neighborhood of East Side would be indicated by the respective levels assigned.

 

On the other hand, Wayland is a neighborhood that borders on Blackstone.  To indicate the region composed of both neighborhoods: 

    <hierarchicalGeographic>

            <country level="1">United States</country>

            <state level="2">Rhode Island</state>

            <city level="3">providence</city>

            <placeOther placeType="neighborhood" level="4">East Side</ placeOther>

            <placeOther placeType="neighborhood" level="4">Wayland</ placeOther>

   </hierarchicalGeographic>

 

As another example, while

            <state>Tennessee</state>

            <placeOther placeType="national park">Smoky Mountain National Park</placeOther>

 

might be used to indicate the part of  Smoky Mountain National Park within Tennessee, the following might indicate the union of those portions in Tennessee and North Carolina: 

            <state level="2">Tennessee</state>

            <state level="2">North Carolina</state>

            <placeOther placeType="national park" level="3">Smoky Mountain National Park</placeOther>

 

Another example, neighborhoods sometimes cross over several town boundaries.  In Massachusetts, Chestnut Hill is a part of Newton, Boston, and Brookline: 

            <state level="2">Massachusetts</state>

            <city level="3">Boston</city>

            <town level="3">Newton</town>

            <town level="3">Brookline</town>

            <placeOther type="neighborhood" level="4">Chestnut Hill</placeOther>

 

 As a final example, consider Massachusetts Avenue which runs through Lincoln Park within Capitol Hill in Washington DC. Say you want to identify that section of Mass Ave  within the park: 

            <state level="2">District of Columbia</state>

            <city level="3">Washington</city>

            <placeOther placeType="neighborhood" level="4">Capitol Hill</placeOther>

            <park level="5">Lincoln Park</park>

            <street level="5">Massachusetts Avenue</street>

 

The intention of this last example is to indicate the intersection of the two level 5 entities.  There are loose ends to tie, and more detailed semantics will need to be defined for all of these examples, if we determine that these are worthwhile use cases.

 

4. Authority
We propose to add an authority attribute to all place type elements.  (This  can be done trivially since they are all currently defined as type "stringPlusLanguage" and can all be redefined as type "stringPlusLanguagePlusAuthority", which is an existing type.)

 

5. Places that no longer exits

We propose to define attribute @period. It's presence will indicate that the described entity once existed but no longer exists.  Its value would be a hint of when it existed (it could be simply a date).

 

Consider the following example: 

            <state level="2">Kansas</state>

            <state level="2">Nebraska</state>

            <state level="2">Wyoming</state>

            <state level="2">Idaho</state>

            <state level="2">Oregon</state>

            <placeOther  level="3" type="trail" period="gold rush">Oregon Trail</placeOther>

 

 

The MODS Editorial Board solicits comments on this proposal.

 

 

Ray Denenberg, Library of Congress

on behalf of the MODS EC