RIMMF: Should RIMMF autofill Media Type from Carrier Type data?

[tmqdeborah]

One of the good things about how RDA has been designed is that it is going to allow software to save the time of the inputter by making certain instructions-based assumptions. RIMMF already autofills certain data based on other inputted data (e.g., 'Preferred Title for the Work' from 'Title Proper').

It has been suggested that we could supply appropriate 'Media Type' terms, based on the terms entered for 'Carrier Type'.

For example, if you enter

• Carrier Type: volume -- then Media Type is: unmediated
• Carrier Type: videodisc -- then Media Type is: video
• Carrier Type: online resource -- then Media Type is: computer
• Carrier Type: object -- then Media Type is: unmediated

Questions:

• Is this safe?
• Can anyone think of any terms where this one-to-one correlation does not apply?
• What should RIMMF (or any other RDA-based input form) enter as the Media Type when Carrier Type is : 'other' or 'unspecified'

[GordonDunsire]

RDA Carrier Type and Media Type are based on the RDA/ONIX Framework. Carry Type is a base carrier category formed from the ROF elements StorageMediumFormat, HousingFormat, and IntermediationTool. Each element has a complete and exhaustive set of values. Media Type is visibly derived from the Carrier Type, but is also based on the ROF element IntermediationTool.

So, in answer to the questions:

• It is safe; there is a one-to-one correlation.
• No-one should be able to think of any terms where this does not apply; such terms will be synonyms for existing Carrier Types. The JSC is considering adding terms such as "Playaway", but these will be extensions to existing Carrier Types, and the correlation will always apply.
• "Other" and "unspecified" are not RDA Carrier Type terms. "Other" will always turn out to be an extension or synonym to an existing Carrier Type; "unspecified" is missing data.

The JSC does not intend to break the correlation between Carrier Type and Media Type. The jSC decided to include Media Type as a specific element for the broad categorization of Carrier Type. After acknowledging in discussion that an application could derive Media Type from Carrier Type; the JSC thought it would be helpful to make the element explicit.

[tmqdeborah]

Can you please explain a bit more about how "other" and "unspecified" should be treated by an application?

RDA 3.3 says: "If none of the terms in the list applies to the carrier or carriers of the resource being described, record other. If the carrier type or types applicable to the resource being described cannot be readily ascertained, record unspecified."

Based on this instruction, RIMMF currently includes both terms in the pull-down list for the Carrier Type element, leaving it up to the inputter to also choose the value for the Media Type element.

Another interpretation of this instruction, the MARC Term list for RDA Carrier Types, lists "other" under each media category, and gives "unspecified" as a separate carrier/media category:
http://www.loc.gov/standards/valuelist/rdacarrier.html

So, am I correct in thinking that if an application is going to provide a Media Type value based on the value entered for Carrier type, and:

• "unspecified" is entered as a Carrier Type value, then an application should provide Media Type: "unspecified"?
• "other" is entered as a Carrier Type, then the application would need to prompt for a value to be entered in Media Type?

[GordonDunsire]

"Unspecified" and "other" do not appear as terms in the RDA Registry Media Type or Carrier Type vocabularies, so RIMMF should not use them if it is based on the Registry vocabularies.

The JSC is currently looking at the Carrier Type and Content Type vocabularies wrt to the RDA/ONIX Framework, so the current instructions on using these additional terms may change.

There is no formal relationship between the MARC code and term lists and RDA, so any current coincidence should be treated as accidental.

[tmqdeborah]

In the meantime, can you suggest how "other" and "unspecified" should be mapped to RDA elements when they appear in MARC records? Should they just be dropped, i.e., no data added for the RDA element?

In one file of 964896 records, I found 963 record(s) that matched the pattern:
AND 336$a=other||unspecified [Case=Y] , OR 338$a=other||unspecified [Case=Y]

Some examples (I realize that some of these are Findaway or Playaway resources (for which, solutions are coming), but the records illustrate that the terms are being used):
245 00 $a Me, Eloise.
264 1 $a [Solon, Ohio] : $b Playaway View, $c [2013]
264 2 $a Solon, Ohio : $b [Distributed by] Findaway World, LLC
300 $a 1 video media player (ca. 1 hr.) : $b digital, sd., col. ; $c 3 1/2 x 4 1/2 in.
336 $a two-dimensional moving image $b tdi $2 rdacontent
337 $a video $b v $2 rdamedia
337 $a unmediated $b n $2 rdamedia
338 $a other $b vz $2 rdacarrier
338 $a other $b nz $2 rdacarrier

245 14 $a The kill room $h [electronic resource] : $b a Lincoln Rhyme novel / $c Jeffery Deaver.
250 $a Unabridged.
260 $a Solon, Ohio : $b Findaway World, $c [2013]
300 $a 1 sound media player (13.5 hr.) : $b digital ; $c 3 3/8 x 2 1/8 in.
306 $a 133000
336 $a spoken word $b spw $2 rdacontent
336 $a computer program $b cop $2 rdacontent
337 $a audio $b s $2 rdamedia
337 $a computer $b c $2 rdamedia
338 $a other audio carrier $b sz $2 rdacarrier

245 14 $a The last alibi / $c David Ellis.
264 1 $a Solon, Ohio : $b Findaway World, LLC, $c [2013].
300 $a 1 sound media player : $b digital, HD audio ; $c 3 3/8 x 2 1/8 in.
336 $a spoken word $b spw $2 rdacontent
337 $a audio $b s $2 rdamedia
337 $a unmediated $b n $2 rdamedia
338 $a other $b sz $2 rdacarrier

245 00 $a Peoria Musical Programs.
264 1 $a [Place of publication not identified] : $b [publisher not identified], $c 1878.
300 $a 1 box : $b illustrated ; $c box 14.5 x 12 x 2 in.
336 $a text $b txt $2 rdacontent
337 $a other $b x $2 rdamedia
338 $a other $b nz $2 rdacarrier

245 10 $a 7 wonders / $c Antoine Bauza.
246 3 $a Seven wonders
264 1 $a Bruxelles, Belgium : $b Repos Production, $c [2013]
264 2 $a Plattsburgh, NY : $b Asmodee US.
300 $a 1 game (7 Wonder boards, 7 Wonder cards, 49 Age I cards, 49 Age II cards, 50 Age III cards, 46 conflict tokens, 24 value 3 coins, 46 value 1 coins, 1 score booklet, 1 "quick rules" sheet, 2 "2-player" cards) : $b cardboard, color ; $c in container 29 x 29 x 8 cm + $e 1 rulebook (12 pages : color illustrations ; 26 cm)
336 $a three-dimensional form $b tdf $2 rdacontent
337 $a unmediated $b n $2 rdamedia
338 $a other $b nz $2 rdacarrier

[DianeHillmann]

Folks:

For many years I've questioned the use of 'other' and 'unspecified' in RDA
Vocabularies. For an interesting meditation on the issue, see:

http://nuzzel.com/sharedstory/07052015/robot-hugs/other_three

Diane

On Wed, Jul 8, 2015 at 6:31 PM, Deborah Fritz [email protected]
wrote:

In the meantime, can you suggest how "other" and "unspecified" should be
mapped to RDA elements when they appear in MARC records? Should they just
be dropped, i.e., no data added for the RDA element?

In one file of 964896 records, I found 963 record(s) that matched the
pattern:
AND 336$a=other||unspecified [Case=Y] , OR 338$a=other||unspecified
[Case=Y]

Some examples (I realize that some of these are Findaway or Playaway
resources (for which, solutions are coming), but the records illustrate
that the terms are being used):
245 00 $a Me, Eloise.
264 1 $a [Solon, Ohio] : $b Playaway View, $c [2013]
264 2 $a Solon, Ohio : $b [Distributed by] Findaway World, LLC
300 $a 1 video media player (ca. 1 hr.) : $b digital, sd., col. ; $c 3 1/2
x 4 1/2 in.
336 $a two-dimensional moving image $b tdi $2 rdacontent
337 $a video $b v $2 rdamedia
337 $a unmediated $b n $2 rdamedia
338 $a other $b vz $2 rdacarrier
338 $a other $b nz $2 rdacarrier

245 14 $a The kill room $h [electronic resource] : $b a Lincoln Rhyme
novel / $c Jeffery Deaver.
250 $a Unabridged.
260 $a Solon, Ohio : $b Findaway World, $c [2013]
300 $a 1 sound media player (13.5 hr.) : $b digital ; $c 3 3/8 x 2 1/8 in.
306 $a 133000
336 $a spoken word $b spw $2 rdacontent
336 $a computer program $b cop $2 rdacontent
337 $a audio $b s $2 rdamedia
337 $a computer $b c $2 rdamedia
338 $a other audio carrier $b sz $2 rdacarrier

245 14 $a The last alibi / $c David Ellis.
264 1 $a Solon, Ohio : $b Findaway World, LLC, $c [2013].
300 $a 1 sound media player : $b digital, HD audio ; $c 3 3/8 x 2 1/8 in.
336 $a spoken word $b spw $2 rdacontent
337 $a audio $b s $2 rdamedia
337 $a unmediated $b n $2 rdamedia
338 $a other $b sz $2 rdacarrier

245 00 $a Peoria Musical Programs.
264 1 $a [Place of publication not identified] : $b [publisher not
identified], $c 1878.
300 $a 1 box : $b illustrated ; $c box 14.5 x 12 x 2 in.
336 $a text $b txt $2 rdacontent
337 $a other $b x $2 rdamedia
338 $a other $b nz $2 rdacarrier

245 10 $a 7 wonders / $c Antoine Bauza.
246 3 $a Seven wonders
264 1 $a Bruxelles, Belgium : $b Repos Production, $c [2013]
264 2 $a Plattsburgh, NY : $b Asmodee US.
300 $a 1 game (7 Wonder boards, 7 Wonder cards, 49 Age I cards, 49 Age II
cards, 50 Age III cards, 46 conflict tokens, 24 value 3 coins, 46 value 1
coins, 1 score booklet, 1 "quick rules" sheet, 2 "2-player" cards) : $b
cardboard, color ; $c in container 29 x 29 x 8 cm + $e 1 rulebook (12 pages
: color illustrations ; 26 cm)
336 $a three-dimensional form $b tdf $2 rdacontent
337 $a unmediated $b n $2 rdamedia
338 $a other $b nz $2 rdacarrier

—
Reply to this email directly or view it on GitHub
#11 (comment).

[GordonDunsire]

I think the data should be dropped.

Note that I consider the assumption that the LC NDMSO code lists are the same as the RDA value vocabularies to be dangerous, as these examples clearly demonstrate. In the "rdacarrier" code list, "other" appears multiple times, each with a different code. This is not what RDA 3.3.1.3 actually says. Several of the examples appear to be misinterpretations of the RDA instructions.

Both "unspecified" and "other" are only useful in closed-world systems; in open-world systems they don't mean anything (consistent). See slide 5 in http://www.gordondunsire.com/pubs/pres/VersioningVocabsLD.pptx, and the video of me presenting it (available at http://ifla2014-satdata.bnf.fr/program.html).

[tmqdeborah]

With the understanding that both of these terms will be removed from the RDA instructions and so should not be used in a value vocabulary for an RDA element, we still have two questions remaining:

• what term should we use when entering data for an RDA element when none of the available terms in its value vocabulary seem to apply, and we are not offered the option to "use another concise term "?
• what term should we use when importing data for an RDA element to (either programmatically or manually) replace:
  • other
  • unspecified

[GordonDunsire]

1. This is a generic issue, not specific to these vocabularies. RDA has a blanket instruction to use "another" Vocabulary Encoding Scheme wherever RDA supplies its own VES, which is pretty well the same as "another concise term". RIMMF and other applications can choose to conform to the RDA application profile(s) currently under development, which will specify the RDA VESs, or accommodate multiple VESs from different sources. I think the former is more sensible for RIMMF. Whatever, the term to be used must be in the VES; otherwise it isn't a VES.
2. As I have already suggested, do not replace "other" or "unspecified" when importing MARC21 data.