The order and grouping of related elements in RIMMF

In RIMMF, there's not really any difference between adding an element to a record and repeating an element that is already in the record–the user has control over the order and grouping of the data in the RIMMF record, and when the record is saved, that ordering and grouping is preserved in the saved record (in occurrence numbers that are attached to the element behind-the-scenes) and observed whenever that record is reloaded.

But what about elements that need to have their association with other elements preserved? And in particular, how is that handled when such elements are repeated?

This particular topic leads to one of the often-mentioned issues in moving our data out of MARC, whether into some new RDA standard, or into Bibframe. Some background discussion of this issue follows.

In MARC, the content designators, along with ISBD, overlay semantic order and grouping on the data. The classic example is the 260 field:

260 ##$aLondon :$bDuckworth ;$aIndianapolis :$bHackett Pub. Co.,$c1999.

From ISBD, we know that the publisher¹⁾ 'Duckworth' publishes from London²⁾, and 'Hackett' from Indianapolis.

Why does MARC not do this–

260 ##$aLondon :$bDuckworth,$c1999.
260 ##$aIndianapolis :$bHackett Pub. Co.,$c1999.

–seems like a good question in 2013, but, like so much of MARC, we have to go back to the days of typing catalog cards for an explanation.

Now, switching to RDA, we also have the core elements Publisher's Name, Place of Publication, and Date of Publication. We do not have MARC or ISBD to help us solve this problem of the ordering of the elements³⁾. So, in a 'flat' display, we might end up with this:

Place of Publication:  London
Place of Publication:  Indianapolis
Publisher's Name:      Duckworth 
Publisher's Name:      Hackett Publishing Company
Date of Publication:   1983

or perhaps this (if some sort of machine-based sorting was in effect):

Place of Publication:  Indianapolis
Place of Publication:  London
Publisher's Name:      Duckworth 
Publisher's Name:      Hackett Publishing Company
Date of Publication:   1983

Neither of the above is desirable from a data point of view; we need an explicit mechanism to connect 'Duckworth' to 'London', and 'Hackett' to 'Indianapolis'.

We ran into this problem very early in RIMMF development. Our solution was to apply occurrence numbers to the elements when they are created, to save this occurrence info when the record is saved, and then to follow those occurrence numbers whenever the record is reloaded.

For example, in RIMMF, the user may enter publishing information (for a pattern like the one above) in any variety of groupings. Here is one possible 'flat' approach:

The problem with the 'flat' approach is the loss of association between Publisher's Name and Place of Publication.

And here is a 'grouped' approach:

The obvious problem we have in the 'grouped' approach is the repetition of the 'Date of Publication'. We do not have any rules that say it must be repeated, but it seems as if leaving it out may imply that the second Publication Statement has a different or unknown date.

An additional issue we have in RIMMF is the tight contraint on elements, by default. However, it is possible to move the 'Date of Publication' outside of the 'Publication Statement' by selecting the special option 'Remove element constraints'. Once that is done, the repeated date of Publication may be deleted, resulting in a display like this:

RIMMF appears to be flexible enough to save the data this way and reload it correctly.

Application developers will probably all devise their own mechanism for handling this problem. But we're not sure that is the best approach. Perhaps some new way of specifying the presentation of elements will be developed in the future, and ideally, that specification will be machine-actionable.

We believe this is an issue that needs to be discussed in more detail.