Planet Cataloging

July 28, 2015

Resource Description & Access (RDA)

Inaccuracies in RDA

Please see Inaccuracies [RDA Blog post revised with Question & Answer on 2015-07-28]

Resource Description & Access (RDA)

Please provide your comments on this interpretations of RDA Rules, as mentioned in the Question & Answer part of this RDA Blog post.

by Salman Haider ( at July 28, 2015 05:19 AM

LC RDA Implementation of Relationship Designators in Bibliographic Records


Library of Congress Implementation of Resource Description and Access Relationship Designators in Bibliographic Records with MARC 21 RDA Cataloging Examples, Guidelines, and Best Practices

Key points
  • The training manual is only for relationship designators in bibliographic records.
  • The requirement for providing relationship designators is only applicable to creators, whether coded in MARC 1XX or 7XX.
  • Relationship designators for Person-Family-Corporate Body  should not be used in a name/title access point tagged 7XX or 8XX, even if they are creators.
  • If the nature of the relationship cannot be ascertained even at a general level, do not assign a relationship designator (if in doubt, leave it out).
  • Other relationship designators are encouraged.
  • The element name, e.g., “creator”, may be used as a relationship designator when you can’t determine a more appropriate relationship designator.
  • The training manual also provides a useful section on “Punctuation and Capitalization”.
  • Relationship designators in RDA may change so always search Appendix I or J for the correct term before assigning one.
The new policy applies to newly completed RDA records, not to routine maintenance of already completed records, or to non-RDA records.

Monographs:  apply to full level original RDA records being coded 042 “pcc”.  It is encouraged, but not required, to apply to minimal level cataloging or imported records treated as “copycat” or “pccadap” in 906$c.  Note that relationship designators are “passed through” if present in copied records, unless egregiously incorrect.

Serials and Integrating Resources: apply to all CONSER authenticated records.

Implementation date:  July 1, 2015”

Best Practices 
  • Using relationship designators for other types of relationships (for example, contributor relationships), is strongly encouraged. 
  • Include a relationship designator, even if it repeats a term used as a qualifier to the name. 
  • Consult RDA Appendix I.2.1: Relationship Designators for Creators. Remember that the relationship designators that are used with creators are on the list in RDA Appendix I.2.1, not on the lists in I.2.2 or I.3.1. 
  • It is recommended that PCC catalogers use relationship designators from the RDA appendices. If the term needed is not there, use the Fast Track PCC relationship designator proposal form to propose a new term or request a revision of an existing term. 

General Guidelines

Guideline 1: Use of this Training Manual 
This training manual is intended to be used as a resource when applying relationship designators in RDA bibliographic records. It does not apply to authority records.

Guideline 2: Sources for Relationship Designators 
It is recommended that PCC catalogers use relationship designators from the RDA appendices. If the term needed is not there, use the PCC relationship designator proposal form to propose a new term or request a revision of an existing term. 

If a PCC cataloger wishes to use a term from a different registered vocabulary (e.g., MARC relator terms, RBMS relationship designators, etc.), he/she may do so.

Guideline 3: Specificity 
Within a hierarchy of relationship designators, prefer a specific term to a general one if it is easily determined. For example, use librettist rather than author for the creator of a libretto, or lyricist rather than author for the creator of the words for songs in a musical.

Guideline 4: RDA Element Name as Relationship Designator 
Assign an RDA element name as a relationship designator (e.g., "creator" (19.2) or "publisher" (21.3)) if it will most appropriately express the relationship. 

However, do not propose RDA element names for inclusion in RDA relationship designator lists. 

Guideline 5: Unclear Relationship 
If the nature of the relationship cannot be ascertained even at a general level, do not assign a relationship designator.

Guideline 6: Adding a Relationship Designator to Existing Terms and/or Codes 
Do not evaluate or edit older codes or terms in cataloging records unless they are clearly in error. Add an RDA relationship designator following an existing term, and before any existing code.

Guideline 7: Applying Relationship Designators in Accordance with their Definitions 
Be careful to apply relationship designators in accordance with their definitions. For example, note the difference between artist and illustrator. If the definitions or the hierarchies appear to be problematic, propose changes to them. Fast Track procedures are in process. See the PCC Relationship Designator Proposal Form

Guideline 8: Access Point and Relationship Designator for an Entity Not Named in a Resource 

In general, it is not necessary to provide access points for related entities not named in the resource. However, other sources of information may be consulted to identify related entities and determine the nature of their relationship to the resource.

Guidelines for Appendix I Relationship Designators 

Guideline 9: Relationship Designators for All Access Points 
PCC highly encourages including relationship designators for all access points whenever it is clear what the relationship is. 

Guideline 10: More than One Relationship Designator Appropriate 
If more than one relationship designator is appropriate because the same entity has multiple roles, preferably use repeating $e (or $j for MARC X11 fields). If necessary, multiple headings may be used instead. Add relationship designators in WEMI order. 

Guideline 11: Relationship Designators for Families and Corporate Bodies 
Note that the relationship designators in RDA Appendix I may be applied to families and corporate bodies as well as to individuals.

Guideline 12: Relationship Designators and Name/Title Access Points in 7XX 
Appendix I relationship designators should not be used in a name/title access point tagged MARC 700- 711 or 800-811, or in a name/title linking field tagged MARC 76X-78X.

Guidelines for Appendix J Relationship Designators 

Guideline 13: Relationship Designators for Resource-to-Resource Relationships 
The use of relationship designators for resource-to-resource relationships is encouraged.

Guideline 14: Relationship Designator Implied by MARC 7XX Content Designation 
If a cataloger wishes to indicate a known relationship to a known resource, and the $i relationship information subfield is defined for the MARC 7XX field being used, provide a relationship designator. Do so even if the field coding otherwise already expresses a relationship.

Guideline 15: Multiple Relationships 
Where multiple relationships exist, e.g., an abridged translation, provide separate access points, each with a single relationship designator in a single $i subfield. Alternatively, identify one relationship as primary and record that relationship alone.

Guideline 16: Reciprocal Relationships for Sequential Works and/or Expressions 
Except in the case of sequential work or expression relationships and equivalent manifestation relationships for serials, it is not necessary to provide reciprocal relationship fields.

Guideline 17: Relationship Designator for Related Resource when MARC 130 or 240 is Present 
Catalogers may add a 7XX field with a relationship designator referring to a specific related resource even if a 130 or 240 field is already present implying that they are versions of the same work.

Guideline 18: Unknown or Uncertain Relationship in a Resource 
If there is reason to believe that the resource being cataloged is related to another resource, but the resource in question cannot be identified (e.g., in the case of an expression that is believed to be a translation but the original is unknown), give the information in a note.

Guideline 19: Related Resource with Same Principally Responsible Creator 
When constructing a reference to a related resource sharing the same principally responsible creator as the resource being described, record the authorized access point for the related entity in a 700/710/711/730 author-title access point explicitly naming the creator in its $a, rather than a 740 title entry with an implied relationship to the 1XX in the same record. 

Guideline 20: Unstructured Descriptions 
For unstructured descriptions it is not necessary to indicate the WEMI level at which the relationship is asserted. 

Punctuation and Capitalization 

Designators that Follow Authorized Access Points 
Relationship designators that follow authorized access points are not capitalized and are always preceded by a comma, unless the authorized access point ends in an open date. 

Designators that Precede Authorized Access Points or Appear at the Beginning of a Field 
Relationship designators that precede authorized access points or that appear at the beginning of a field are capitalized and are followed by a colon.

Your Browser doesn't support for Iframe !

Relationship Designators in RDA: Connecting the Dots 

Your Browser doesn't support for Iframe !

[Source: Adam L. Schiff, Principal Cataloger, University of Washington Libraries]

See also related RDA Blog posts:



Comment by Bob Kosovsky, Curataor, Rare Books and Manuscripts, Music Division, The New York Public Library, New York, United States:
Bob Kosovsky Actually the latest blog entry has a nice detailed entry on relationship designators. I couldn't find them choosing between the codes or the full designation, but they speak of the codes only in the past tense, and considering RDA's general drift to spell things out, I take that to mean one should spell out the designator.

Comment by Robln Fay, Metadata, Web, & Social Media Consultant for libraries & beyond
RobIn Fay yes, I agree with Bob Kosovsky. I would not abbreviate the relationship designators. Now, in theory (in theory), machines should be (should be) smart enough to figure out abbreviations in context, but they can't really yet. The best you can do is program the options and with a fast enough machine it will run through the choices so fast it will seem that it thinks (vs probability). So something like: $e ed. maps to $e editor

Thanks all for your love, suggestions, testimonials, likes, +1, tweets and shares ....

See also related posts in following RDA Blog Categories (Labels):

by Salman Haider ( at July 28, 2015 04:19 AM

July 27, 2015

TSLL TechScans

LC makes BIBFRAME training materials available

In preparation for its much-anticipated BIBFRAME cataloging pilot project, the Library of Congress has developed training materials for staff involved in the pilot, and made the first of three modules available online at Module one is divided into two sets of slides, plus supplementary reading/viewing assignments and brief quizzes. The training materials are designed for experienced catalogers and do not assume prior knowledge of linked data concepts.

The first set of slides provides a brief introduction to the concepts behind the Sematic Web and linked data, and the evolution of the World Wide Web from a web of documents to a web of data. It explains the need to move bibliographic data out of its MARC silo and onto the Semantic Web.

The second set of slides delves into the principles underlying RDF (Resource Description Framework), the “language of the Web.” Detailed, clearly presented examples of RDF triples provide a concrete visualization of what bibliographic data structured in RDF looks like.

Although I found a number of typos in the slides (I AM a cataloger, after all!), I found the training materials very helpful in confirming and deepening my knowledge of linked data and the Semantic Web. 

by (Jean Pajerek) at July 27, 2015 01:28 PM

July 25, 2015

Terry's Worklog

Code4LibMW 2015 Write-up

Whew – it’s be a wonderfully exhausting past few days here in Columbus, OH as the Libraries played host to Code4LibMW.  This has been something that I’ve been looking forward to ever since making the move to The Ohio State University; the C4L community has always been one of my favorites, and while the annual conference continues to be one of the most important meetings on my calendar – it’s within these regional events where I’m always reminded why I enjoy being a part of this community. 

I shared a story with the folks in Columbus this week.  As one of the folks that attended the original C4L meeting in Corvallis back in 2006 (BTW, there were 3 other original attendees in Columbus this week), there are a lot of things that I remember about that event quite fondly.  Pizza at American Dream, my first experience doing a lightening talk, the joy of a conference where people were writing code as they were standing on stage waiting their turn to present, Roy Tennant pulling up the IRC channel while he was on stage, so he could keep an eye on what we were all saying about him.  It was just a lot of fun, and part of what made it fun was that everyone got involved.  During that first event, there were around 80 attendees, and nearly every person made it onto the stage to talk about something that they were doing, something that they were passionate about, or something that they had been inspired to build during the course of the week.  You still get this at times at the annual conference, but with it’s shear size and weight, it’s become much harder to give everyone that opportunity to share the things that interest them, or easily connect with other people that might have those same interests.  And I think that’s the purpose that these regional events can serve. 

By and large, the C4L regional events feel much more like those early days of the C4L annual conference.  They are small, usually free to attend, with a schedule that shifts and changes throughout the day.  They are also the place where we come together, meet local colleagues and learn about all the fantastic work that is being done at institutions of all sizes and all types.  And that’s what the C4LMW meeting was for me this year.  As the host, I wanted to make sure that the event had enough structure to keep things moving, but had a place for everyone to participate.  For me – that was going to be the measure of success…did we not just put on a good program – but did this event help to make connections within our local community.  And I think that in this, the event was successful.  I was doing a little bit of math, and over the course of the two days, I think that we had a participation rate close to 90%, and an opportunity for everyone that wanted to get up and just talk about something that they found interesting.  And to be sure – there is a lot of great work being done out here by my Midwest colleagues (yes, even those up in Michigan Smile).

Over the next few days, I’ll be collecting links and making the slides available via the C4LMW 2015 home page as well as wrapping up a few of the last responsibilities of hosting an event, but I wanted to take a moment and again thank everyone that attended.  These types of events have never been driven by the presentations, the hosts, or the presenters – but have always been about the people that attend and the connections that we make with the people in the room.  And it was a privilege this year to have the opportunity to host you all here in Columbus. 



by reeset at July 25, 2015 02:17 AM

July 23, 2015

TSLL TechScans

Conversations about RDA

LJ INFOdocket reports that the Library of Congress has released an new series of training videos, "Conversations about RDA".   Topics include:
  • Compare and contrast: AACR2 and RDA in the bibliographic record
  • Undifferentiated personal name headings
  • Cataloger judgement and statement of responsibility
  • Capitalization, abbreviations & numbers
  • Exercising judgment in the statement of responsiblity
The videos average 20 minutes and provide focused looks at a topical areas. The videos are linked from the Library of Congress Webcast page within the Science and Technology category.

by (Jackie Magagnosc) at July 23, 2015 07:34 PM

Mod Librarian

5 Things Thursday: DAM Workflow, Beautiful Libraries, Radical Posters

5 Things Thursday: DAM Workflow, Beautiful Libraries, Radical Posters

Here are five more things for you:

  1. “Workflow. It’s like a buzzword without any buzz.” – from Jim Kidwell’s article Digital Asset Management Workflow: The Unsung Hero of DAM.
  2. Check out this archive of posters documenting radical history from the University of Michigan Library.
  3. Another list of the world’s most beautiful libraries and The Seattle Public Library’s Central Library is on there again.
  4. I…

View On WordPress

July 23, 2015 12:01 PM

July 22, 2015

Local Weather

I've not written here in ages. But today at work we had a great moment: we shipped out our first big collection, the Andrew Smith Gallery archives. It was the first collection we brought into our new space and now it is the first big collection out. 14 pallets of boxes coming in; 12 pallets of boxes, and several other containers going out.

The space, the stuff, and the staff: this is what makes the Beinecke Technical Services operation at 344 Winchester the wonder that it is.

There were 466 boxes on those pallets. The represent a large chunk (the rest went in bins) of the Andrew Smith Gallery records, a collection of business records from an important dealer in photography of the American West. We moved it here from the LSF Processing Space on 14 pallets soon after we moved in, and in the space of two and a half months the accessioning team processed 710 boxes. An impressive feat. It shows what we are able to achieve in our new space.

Below is a photo of the forklift coming into the same hallway as above. Nice to be able to drive the lift between this hallway and the loading dock.
This made moving twelve pallets to the loading dock and onto trucks bound for the Library Shelving Facility much easier. This instead of  pushing freezer carts across the Beinecke Plaza.

I congratulate and celebrate Mike Rush, Tina Evans, Leigh Golden, Jim Fisher, Jenn Garcia, Karen Nangle, and several student workers.

Thank you to all.

by MLB ( at July 22, 2015 03:33 PM

July 21, 2015

Terry's Worklog

Merge Record Changes

With the last update, I made a few significant modifications to the Merge Records tool, and I wanted to provide a bit more information around how these changes may or may not affect users.  The changes can be broken down into two groups:

  1. User Defined Merge Field Support
  2. Multiple Record merge support

Prior to MarcEdit 6.1, the merge records tool utilized 4 different algorithms for doing record merges.  These were broken down by field class, and as such, had specific functionality built around them since the limited scope of the data being evaluated, made it possible.  Two of these specific functions was the ability for users to change the value in a field group class (say, change control numbers from 001 to 907$b) and the ability for the tool to merge multiple records in a merge file, into the source.

When I made the update to 6.1, I tossed out the 3 field specific algorithms, and standardized on a single processing algorithm – what I call the MARC21 option.  This is an algorithm that processes data from a wide range of fields, and provides a high level of data evaluation – but in doing this, I set the fields that could be evaluated, and the function dropped the ability to merge multiple records into a single source file.  The effect of this was that:

  • Users could no longer change the fields/subfields used to evaluate data for merge outside of those fields set as part of the MARC21 option.
  • if a user had a file that looked like the following —
    sourcefile1 – record 1
    mergefile – record1 (matches source1)
    mergefile – record2
    mergefile – record3 (matches source1)

    Only data from the mergefile – record 1 would be merged.  The tool didn’t see the secondary data that might be in the merge file.  This has always been the case when working with the MARC21 merge option, but by making this the only option, I removed this functionality from the program (as the 3 custom field algorithms did make accommodations for merging data from multiple records into a single source).

With the last update, I’ve brought both of these to elements back to the tool.  When a user utilizes the Merge Records tool, they can change the textbox with the field data – and enter a new field/subfield combination for matching (at this point, it must be a field/subfield combination).  Secondly, the tool now handles the merging of multiple records if those data elements are matched via a title or control number.  Since MarcEdit will treat user defined fields as the same class as a standard number (ISBN technically) for matching – users will now see that the tool can merge duplicate data into a single source file.

Questions about this – just let me know.


by reeset at July 21, 2015 04:06 PM

MarcEdit 6.1 Update

This update will have four significant changes to three specific algorithms that are high use — so I wanted to give folks a heads up.

1) Merge Records — I’ve updated the process in two ways.  

   a) Users can now change the data in the dropdown box to a user-defined field/subfield combination.  At present, you have defined options: 001, 020, 022, 035, marc21.  You will now be able to specify another field/subfield combination (must be the combination) for matching.  So say you exported your data from your ILS, and your bibliographic number is in a 907$b — you could change the textbox from 001 to 907$b and the tool will now utilize that data, in a control number context — to facilitate matching.  

   b) This meant making a secondary change.  When I shifted to using the MARC21 method, I removed the ability for the algorithm to collapse multiple records of the same type with the merge file into the source.  For example, after the change to the marc21 algorithm, in the following scenario, the following would be true:

 source 1 — record 1
merge 1 — matches record 1
merge 2 — matches record 2
merge 3 — matches record 3


The data moved into source 1 would be the data from merge1 — merge 3 wouldn’t be seen.  In the previous version prior to utilizing just the Marc21 option, users could collapse records when using the control number index match.  I’ve updated the merge algorithm, so that default is now to assume that all source data could have multiple merge matches.  This has the practical option of essentially allowing users to take a merge file with multiple duplicates, and merge all data into a single corresponding source file.  But this does represent a significant behavior change — so users need to be aware.


2) RDA Helper — 

   a) I’ve updated the error processing to ensure that the tool can fail a bit more gracefully

   b) Updating the abbreviation expansion because the expression I was using could miss values on occasion.  This will catch more content — it should also be a bit faster.


3) Linked Data tools — I included the ability to link to OCLC works ids — there were problems when the json outputted was too nested.  This has been corrected.


4) Bibframe tool — I’ve updated the mapping used to the current LC flavor.


Updates can be found on the downloads page (Windows/Linux) or via the automated update tool.

Direct Links:


by reeset at July 21, 2015 06:51 AM

July 17, 2015

mashcat « mashcat

Mashcat now mashing together library data and systems feeds

There are a number of folks blogging about library data, library systems, and the intersection thereof. To help readers find these blogs, the Mashcat website is now offering a “planet”, i.e., an aggregator of those blogs’ RSS feeds.

To subscribe to the aggregate feed, point your RSS reader at You can also visit the Planet Mashcat page to see the posts in situ.

Owen Stephens has also set up a #blogs channel in the Mashcat Slack.

Do you blog about library data or library systems and want to be included in the planet? If so, please drop a comment below with a link to your blog.

by Galen Charlton at July 17, 2015 03:41 PM

Coyle's InFormation

Flexibility in bibliographic models

A motley crew of folks had a chat via Google Hangout earlier this week to talk about FRBR and Fedora. I know exactly squat about Fedora, but I've just spent 18 months studying FRBR and other bibliographic models, so I joined the discussion. We came to a kind of nodding agreement, that I will try to express here, but one that requires us to do some hard work if we are to make it something we can work with.

The primary conclusion was that the models of FRBR and BIBFRAME, with their separation of bibliographic information into distinct entities, are too inflexible for general use. There are simply too many situations in which either the nature of the materials or the available metadata simply does not fit into the entity boundaries defined in those models. This is not news -- since the publication of FRBR in 1998 there are have numerous articles pointing out the need for modifications of FRBR for different materials (music, archival materials, serials, and others). The report of the audio-visual community to BIBFRAME said the same. Similar criticisms have been aimed at recent generations of cataloging rules, whose goal is to provide uniformity in bibliographic description across all media types. The differences in treatment that are needed by the various communities are not mutually compatible, which means that a single model is not going to work over the vast landscape that is "cultural heritage materials."

At the same time, folks in this week's informal discussion were able to readily cite use cases in which they would want to identify a group of metadata statements that would define a particular aspect of the data, such as a work or an item. The trick, therefore, is to find a sweet spot between the need for useful semantics and the need for flexibility within the heterogeneous cultural heritage collections that could benefit from sharing and linking their data amongst them.

One immediate thought is: let's define a core! (OK, it's been done, but maybe that's a different core.) The problem with this idea is that there are NO descriptive elements that will be useful for all materials. Title? (seems obvious) -- but there are many materials in museums and archives that have no title, from untitled art works, to museum pieces ("Greek vase",) to materials in archives ("Letter from John to Mary"). Although these are often given names of a sort, none have titles that function to identify them in any meaningful way. Creators? From anonymous writings to those Greek vases, not to mention the dinosaur bones and geodes in a science museum, many things don't have identifiable creators. Subjects? Well, if you mean this to be "topic" then again, not everything has a topic; think "abstract art" and again those geodes. Most things have a genre or a type but standardizing on those alone would hardly reap great benefits in data sharing.

The upshot, at least the conclusion that I reach, is that there are no universals. At best there is some overlap between (A & B) and then between (B & C), etc. What the informal group that met this week concluded is that there is some value in standardizing among like data types, simply to make the job of developers easier. The main requirement overall, though, is to have a standard way to share ones metadata choices, not unlike an XML schema, but for the RDF world. Something that others can refer to or, even better, use directly in processing data you provide.

Note that none of the above means throwing over FRBR, BIBFRAME, or RDA entirely. Each has defined some data elements that will be useful, and it is always better to re-use than to re-invent. But the attempts to use these vocabularies to fix a single view of bibliographic data is simply not going to work in a world as varied as the one we live in. We limit ourselves greatly if we reject data that does not conform to a single definition rather than making use of connections between close but not identical data communities.

There's no solution being offered at this time, but identifying the target is a good first step.

by Karen Coyle ( at July 17, 2015 08:59 AM

Metadata Matters (Diane Hillmann)

What do we mean when we talk about ‘meaning’?

Over the past weekend I participated in a Twitter conversation on the topic of meaning, data, transformation and packaging. The conversation is too long to repost here, but looking from July 11-12 for @metadata_maven should pick most of it up. Aside from my usual frustration at the message limitations in Twitter, there seemed to be a lot of confusion about what exactly we mean about ‘meaning’ and how it gets expressed in data. I had a skype conversation with @jonphipps about it, and thought I could reproduce that here, in a way that could add to the original conversation, perhaps clarifying a few things. [Probably good to read the Twitter conversation ahead of reading the rest of this.]

Jon Phipps: I think the problem that the people in that conversation are trying to address is that MARC has done triple duty as a local and global serialization (format) for storage, supporting indexing and display; a global data interchange format; and a focal point for creating agreement about the rules everyone is expected to follow to populate the data (AACR2, RDA). If you walk away from that, even if you don’t kill it, nothing else is going to be able to serve that particular set of functions. But that’s the way everyone chooses to discuss bibframe, or, or any other ‘marc replacement’.

Diane Hillmann: Yeah, but how does ‘meaning’ merely expressed on a wiki page help in any way? Isn’t the idea to have meaning expressed with the data itself?

Jon Phipps: It depends on whether you see RDF as a meaning transport mechanism or a data transport mechanism. That’s the difference between semantic data and linked data.

Diane Hillmann: It’s both, don’t you think?

Jon Phipps: Semantic data is the smart subset of linked data.

Diane Hillmann: Nice tagline :)

Jon Phipps: Zepheira, and now DC, seem to be increasingly looking at RDF as merely linked data. I should say a transport mechanism for ‘linked’ data.

Diane Hillmann: It’s easier that way.

Jon Phipps: Exactly. Basically what they’re saying is that meaning is up to the receiver’s system to determine. Dc:title of ‘Mr.’ is fine in that world–it even validates according to the ‘new’ AP thinking. It’s all easier for the data producers if they don’t have to care about vocabularies. But the value of RDF is that it’s brilliantly designed to transport knowledge, not just data. RDF data is intended to live in a world where any Thing can be described by any Thing, and all of those descriptions can be aggregated over time to form a more complete description of the Thing Being Described. Knowledge transfer really benefits from Semantic Web concepts like inferences and entailments and even truthiness (in addition to just validation). If you discount and even reject those concepts in a linked data world than you might as well ship your data around as CSV or even SQL files and be done with it.

One of the things about MARC is that it’s incredibly semantically rich ( and has also been brilliantly designed by a lot of people over a lot of years to convey an equally rich body of bibliographic knowledge. But throwing away even a small portion of that knowledge in pursuit of a far dumber linked data holy grail is a lot like saying that since most people only use a relatively limited number of words (especially when they’re texting) we have no need for a 50,000 word, or even a 5,000 word, dictionary.

MARC makes knowledge transfer look relatively easy because the knowledge is embedded in a vocabulary every cataloger learns and speaks fairly fluently. It looks like it’s just a (truly limiting) data format so it’s easy to think that replacing it is just a matter of coming up with a fresh new format, like RDF. But it’s going to be a lot harder than that, which is tacitly acknowledged by the many-faceted effort to permanently dumb-down bibliographic metadata, and it’s one of the reasons why I think,, and might end up being very destructive, given the way they’re being promoted (be sure to Park Your MARC somewhere).

[That’s why we’re so focused on the RDA data model (which can actually be semantically richer than MARC), why we helped create, and why we’re working at building out our RDF vocabulary management services.]

Diane Hillmann: This would be a great conversation to record for a podcast ;)

Jon Phipps: I’m not saying proper vocabulary management is easy. Look at us for instance, we haven’t bothered to publish the OMR vocabs and only one person has noticed (so far). But they’re in active use in every OMR-generated vocab.

The point I was making was that we we’re no better, as publishers of theoretically semantic metadata, at making sure the data was ‘meaningful’ by making sure that the vocabs resolved, had definitions, etc.

[P.S. We’re now working on publishing our registry vocabularies.]

by Diane Hillmann at July 17, 2015 02:35 AM

July 16, 2015

Mod Librarian

5 Things Thursday: Global DAM, Automated Metadata, University of Miami

Here are your five things for the week:

  1. John Horodyski on managing your global content with DAM.
  2. More on the perils of automated metadata – hmmm, it should be checked by actual humans!
  3. The Stages of DAM Consciousness lead from realizing you have a problem to realizing you may need help.
  4. Nice Tumblr from the University of Miami Special Collections
  5. Adding video metadata by talking? Check out this p…

View On WordPress

July 16, 2015 12:01 PM

July 15, 2015

First Thus


On 6/14/2015 5:18 PM, Karen Coyle wrote:
> BF claims to be “cataloging rules neutral.” The variant title class > doesn’t seem to support that neutrality. I also wouldn’t be surprised if > there were other such cases in BF. Perhaps this harks back to a > conflation of goals: a general bibliographic framework vs. the > replacement for the heavily Anglo-American biased MARC format.

I don’t know if it’s even possible to be “neutral” here. The idea of “Variant titles” presupposes that there are specific title(s) that take precedence. In AACR2/RDA, there is the very cataloging idea of “chief source of information” (CSI) and there are rules describing how to find it on each type of format (books, journals, videos, maps, etc.). Our cataloging rules state that the main title comes from the CSI while other titles are different types of variants. Not every bibliographic agency has this concept of “chief source of information” however and I personally have not come across this concept outside the library community.

Plus, there are simply different concepts. As an example, here are the codes for “Title types” for ONIX, which is designed for book publishers–certainly one group we should be considering. I can’t point to a webpage for this. You must download it locally as a zip file from I hope it can be read in this message. Apologies if not.

> 00 Undefined
> 01 Distinctive title (book); Cover title (serial); Title on item (serial content item or reviewed resource) The full text of the distinctive title of the item, without abbreviation or abridgement. For books, where the title alone is not distinctive, elements may be taken from a set or series title and part number etc to create a distinctive title. Where the item is an omnibus edition containing two or more works by the same author, and there is no separate combined title, a distinctive title may be constructed by concatenating the individual titles, with suitable punctuation, as in “Pride and prejudice / Sense and sensibility / Northanger Abbey”. > 02 ISSN key title of serial Serials only.
> 03 Title in original language Where the subject of the ONIX record is a translated item.
> 04 Title acronym or initialism For serials: an acronym or initialism of Title Type 01, eg “JAMA”, “JACM”. > 05 Abbreviated title An abbreviated form of Title Type 01.
> 06 Title in other language A translation of Title Type 01 into another language.
> 07 Thematic title of journal issue Serials only: when a journal issue is explicitly devoted to a specified topic.
> 08 Former title Books or serials: when an item was previously published under another title.
> 10 Distributor’s title For books: the title carried in a book distributor’s title file: frequently incomplete, and may include elements not properly part of the title.
> 11 Alternative title on cover An alternative title that appears on the cover of a book.
> 12 Alternative title on back An alternative title that appears on the back of a book.
> 13 Expanded title An expanded form of the title, eg the title of a school text book with grade and type and other details added to make the title meaningful, where otherwise it would comprise only the curriculum subject. This title type is required for submissions to the Spanish ISBN Agency.
> 14 Alternative title An alternative title that the book is widely known by, whether it appears on the book or not.

So, we see lots of differences, not least of all with terminology. For instance, library use of “Distinctive title” means some quite specific, and different, from what we see here. We do not see a uniform/preferred title. The closest could be “Title in original language” and/or “Former title”.

“Alternative title” in ONIX also means something totally different from what a library cataloger understands. Here, it seems to mean what “Variant title” means to a cataloger, but ONIX expands it to front and back cover.

I think it is very difficult to make anything neutral.

James Weinheimer
First Thus
First Thus Facebook Page
Personal Facebook Page Google+
Cooperative Cataloging Rules
Cataloging Matters Podcasts The Library Herald


by James Weinheimer at July 15, 2015 02:56 PM

July 14, 2015

025.431: The Dewey blog

Pluto: Are we there yet?

Today, July 14, 2015, at 07:49 EDT, New Horizons, NASA’s interplanetary space probe (629.4354922, built with 629.4354 Planetary flights, plus notation 922 from 523.4922 Pluto) passed within 8,000 miles of the surface of the dwarf planet Pluto (523.4922).  NASA expects confirmation of the flyby and the spacecraft’s status at about 21:02 EDT tonight.

Launched in 2006, “New Horizons’ flyby of the dwarf planet and its five known moons is providing an up-close introduction to the solar system's Kuiper Belt, an outer region populated by icy objects ranging in size from boulders to dwarf planets.  Kuiper Belt objects, such as Pluto, preserve evidence about the early formation of the solar system” ( 

Previous blogs (here, here, and here) have discussed the demotion of Pluto to a dwarf planet and the impact on the DDC schedule.

In addition to its systems and scientific payload, New Horizons carries nine small but meaningful mementos (

  • Two US state quarters (737.4973, built with 737.49 Coins of specific countries, plus notation T2—73 United States), one from Florida where New Horizons launched and the other from Maryland where it was built;
  • a piece of SpaceShipOne, the first privately funded spacecraft (629.47 Astronautical engineering [“Class here . . . spacecraft”]) to travel in space;
  • a small container of the ashes of Clyde Tombaugh (520.92, built with 520 Astronomy & allied sciences, plus notation T1—092 Biography), the astronomer who discovered Pluto;
  • a 1991 US postal stamp, bearing an artist’s rendering of Pluto and the caption “NOT YET EXPLORED” (769.56495234922, built with 769.564 Postage stamps depicting various specific subjects, plus notation 9 from 704.949 [Iconography of] Other specific subjects, plus notation 5234922 Pluto);
  • two US flags (929.9273, built with 929.92 Flags, plus notation T2—73 United States); and
  • two CD-ROMs (004.565 Optical storage [“Including CD-ROM . . . discs”]), one with photos of the New Horizons team members and one with the names of 434,738 people who signed up in advance.


by Carol at July 14, 2015 10:05 PM