Dear Jens:

Thank you for these very helpful comments. As we are working through these fairly significant changes to MODS in the next version we will take them into account. As for dates, we are looking at using an eventType attribute with <provider> and that defines what type of date it is. That is, if the event type is publication then the (redefined) <date> element is a publication date.

As for your question about transforming MODS to Bibframe, we are just starting on a mapping that can be used to do these sorts of transformations, similar to what we have for MARC. As we make progress on this work, we will keep the MODS community informed. 


Rebecca Guenther
Library of Congress
Network Development & MARC Standards Office
[log in to unmask]

On Jan 4, 2013, at 9:46 AM, Jens Østergaard Petersen wrote:


Thank you for presenting these exciting ideas.

Please find some comments below.



On Jan 3, 2013, at 8:12 PM, Rebecca Guenther <[log in to unmask]> wrote:

The MODS Editorial Committee is considering ways to change or enhance MODS to fix some of the problems with consistency that have been identified and to make it more compatible with the direction of the Bibliographic Framework Transition Initiative (BIBFRAME) and RDA. One area of difficulty in the current and previous versions of MODS has been the originInfo element and its subelements. Problems that have been identified include the following:

Are there any initiatives directed towards transforming MODS to BIBFRAME, similar to those for MARCXML at <>?

<snip />

5. Dates.
There are a number of date types, e.g. dateIssued, dateCreated, dateValid,  dateOther (with uncontrolled type attribute.), etc. These need to be accommodated.

MODS generally disposes elements with variants using @type – except for the date elements which add up to a long list. Is it being considered to change these to <date type="issued">, <date type="created">, etc.? This would make searching simpler and editing records in a form-based editor easier.

<snip />

3. Place
Place would be a subelement within providerEvent. Geographic under subject is another area that needs to be cleaned up for various reasons (for instance, should hierarchicalGeographic really be a separate element or should it just be a different form of geographic and use the same element?). At a later date it will be considered whether to 1) change place under providerEvent to geographic, or 2) change geographic under subject to place, or 3) to keep place in providerEvent, but taking the same definition as <geographic> (i.e. that it can be a controlled form of name).

The element subject/temporal should perhaps also be considered in connection with the date element(s), on the analogy of subject/geographic and place.

4. Unrelated elements. Take edition, issuance and frequency out of originInfo/providerEvent as separate top level elements.

5. Dates.
Define <date> under providerEvent; the type of date is implicit in the eventType used. That is, if the eventType is "published" (or "issued"-- these have been considered synonymous) the date is publication, the provider is publisher, the place is place of publication. There are some stray dates that aren't associated with places and providers generally (i.e. dateValid). For those not related to an event, <date> can be defined at the top level and used with the type attribute (uncontrolled list). This construct will also be used for other types of dates that aren't associated with a provider event.

To accommodate the need for both transcription (how the resource presents itself) and access, there could be a subelement providerStatement under providerEvent for the transcribed form of the whole statement, i.e. place, provider, date.

It is a good idea to separate the systematic, access-related, information from documentary information in this way. Is it being considered to add a similar element to cover the statement of responsibility? I believe the general practice is to enter such information in a <note type="statement of responsibility">, but is this satisfactory for such a key piece of information? Also, I wonder if the dissection of the title information into the various subelements of titileInfo always accounts fully for the presented title information?

I see a problem when a publication has several providers, each located in one or more places. How should place 1 be paired with publisher 1, and so on? Should not place be a subelement of provider, with providerEvent/provider/name and providerEvent/provider/place? The event is one (a cooperative publication), but I would argue that the provider is the entity which has one or more places, not the event. To put it differently: a book is published by a publisher which has a domicile; it is not published by publisher at some (variable) place. - The date is of course keyed to the event.

The MODS Editorial Committee would like to hear comments on these proposed changes. They would be in a future major new version of MODS.

Chair, MODS Editorial Committee
Library of Congress