It wasn’t too long ago that the music industry was in an uproar about stories of how easy it was to copy digital audio files and make digital copies with high fidelity. It was predicted that we would see the same thing in other media forms, and this week’s DLTJ Thursday Threads has two stories on the topic of book publishing. First is news of another inexpensive and simple (and now to be commercially produced) book digitizing system. Although the process of “ripping” a book from its physical medium might take longer than an audio track, these kind of devices are emerging that will make it simple to do. What happens with the digital copy after that? The second Thursday Threads pointer is to an interview with the founder of book publishing industry consultant about the state of book piracy, how it is measured, and why digital rights management software is a poor way to stop it. The last entry this week is a short excerpt of a brief summary of a study conducted by OCLC last year on the usage of MARC tags in cataloging records.

As a side note, apologies to DLTJ readers that had problems reading some of the content here over the past couple of weeks. A series of problems with my personal server — driven by the fact, I believe, that the server was first set up about 10 years ago and all the patches, tweaks, and updates over the decade have finally driven performance into the ground — prompted me to migrate this blog to Amazon’s Web Services cloud. It is now running on a micro Elastic Cloud Computing (EC2) virtual machine backed by Simple Storage Service (S3) and the CloudFront content distribution network. I’ve also been optimizing the snot out of configuration — employing all sorts of new tricks for reducing the time it takes to deliver pages to your browser. I have another blog post in draft with the details for when anyone (even me!) wants to replicate it. Given enough personal time, watch for that in the next week or so.

All of that said, if you are seeing things that don’t look or function right, please let me know.

Book Saver – A personal book digitization setup from ION

Picture and Demonstration Video of the Book Saver from ION

Book Saver has two cameras that take separate images in rapid succession of each page within an open book. Both cameras of Book Saver also have a flash for allowing the page to be fully illuminated during the scanning process. Book Saver’s cradle, where the book is placed during the scanning process, is also angled as to not require you to hold pages down to get a flat, even surface. While similar devices require up to seven seconds per one page, Book Saver takes only one second per two pages!

News of the new Book Saver product comes from Fiacre O’Duinn. It is a hand-held device for digitizing book materials. The promotional literature says it takes about 15 minutes to digitize a 200-page book. The product was announced in time for the Consumer Electronics Show earlier this month, but is not yet available. It is expected to ship this summer with a manufacturer’s suggested retail price of $189 (I’m already seeing price points of $149 mentioned).

One of the “Key Features” listed on the product page is that the device “eliminates the need to purchase electronic versions of reading material you already own.” As Fiacre points out in his post, this really brings down the cost (in equipment and in effort) of digitally reproducing books. Are we about to see a new wave of personal book sharing/piracy? And what will the impact on libraries be? In the higher education arena, it is already being mentioned as a way to digitize textbooks. It is conceivable that students would borrow textbooks from our libraries, digitize them in an afternoon, and return them — or maybe just digitize them in the library. Do we need to get ahead of devices like this with education and policy initiatives?

Book Piracy: Less DRM, More Data

As digital book publishing continues to expand at a rapid pace to meet reader demands, piracy rears its head at the forefront of many a discussion in publisher circles. Many publishers respond to the perceived threat with strict digital rights management (DRM) software. But is this the best solution? And does it even provide protection from piracy?

In the following interview, Magellan Media founder and TOC 2011 speaker Brian O’Leary (@brianoleary) discusses the current state of book piracy, how measurement data isn’t sufficient to determine its impact, and why DRM is a poor anti-piracy tool.

The same arguments in favor of digital rights management for the music sector are now being made in the book publishing sector. This interview comes from the perspective of why DRM is the wrong answer to the perceived problem of book piracy. The backdrop is O’Reilly Media’s Tools of Change for Publishing conference to be held next month in New York City.

Core Bibliographic Description

Those “outliers” can be categorized according to three general purposes:

• Provenance and Identity: identifiers (e.g. ISBN, OCLC, etc.) and cataloging source (040)
• Elements useful for discovery: title statement (245), personal names (100, 700) and subject (650)
• Elements useful for understanding and evaluation: publication statement (260), physical description (300), and notes (500)

That’s it. In a nutshell you have the very core of bibliographic description as defined by librarians over the last century or so.

This post by Roy Tenant briefly summarizes the work of OCLC Research staff member Karen Smith-Yoshimura. The research work was to gather evidence to inform changes in MARC metadata practices, and that project page includes a 72 page report [PDF] and an Excel spreadsheet of data tables along with audio and video of a one hour webinar on the report. In my FriendFeed posting of Roy’s article, Walt Crawford noted a similar finding in his 1986 Bibliographic displays in the online catalog. As Walt notes, “somehow it’s not surprising that it’s still true in 2010.”

In preparation for the last webinar of the three-part series “Using RDA: Moving into the Metadata Future“, I’m reading again Karen Coyle‘s “Library Data in a Modern Context” — the first chapter ofUnderstanding the Semantic Web: Bibliographic Data and Metadata. Right at the start she has a clear and useful definition of this thing we call “metadata.”

The most common definition of metadata is “data about data.” This short, catchy definition is worthy of a successful advertising campaign. Unfortunately, it doesn’t really help us understand metadata, and is actually somewhat incorrect. A more useful definition is decidedly less snappy, but can help us understand the helpful role that metadata can play in facilitating information access. In fact, a functional definition gives us a viable roadmap for our own studies of metadata utility and quality.

So here it goes—metadata is constructed, constructive, and actionable:

• Constructed: Metadata is not found in nature. It is entirely an invention; it is an artificiality.
• Constructive: Metadata is constructed for some purpose, some activity, to solve some problem. The proliferation of metadata formats that seem similar on the surface is often evidence of different definitions of needs or of different contexts. We may dream of a universal set of metadata for some set of things, like biological entities, printed books, or a calendar of events, but are likely to be disappointed in practice.
• Actionable: The point of metadata is to be useful in some way. This means that it is important that one can act on the metadata in a way that satisfies some needs.¹

A little further on Karen focuses on the actionablity of metadata. I have a heightened awareness of the need for other-than-visual access to information based on the last few months of activity with my previous employer, so I reread this section with “new eyes” (so to speak):

…today’s metadata must be in a form that can be processed by computers, and the sense that it is “actionable” really needs to be interpreted as being “actionable by electronic machines.” Even when the final goal is to display the data to humans in an understandable form, the data will undergo some machine processing on the way to its destination on a screen [or] in printed form or when read aloud by a screen reader.

I added that last part. The transformation of the meaning of the metadata into a visual form is but one possible sensory input across the human-computer divide. It is important to also design interfaces that bring meaning to data by supplying labels to values in alternate ways. For the MARC 300 field, it is the difference between “ix, 74 p. : ill. ; 23 cm” and “9 pages of introductory material followed by 74 numbered pages. Includes illustrations. 23 centimeters high.” If the only way to transmit this information was auditory, which one of these would you like spoken to you? Is it: “eye-ex, seventy four pee. ill. twenty three cem”?

Now let’s try to engineer that backwards. Is the auditory version easier to do with:

300    |aix, 74 p. :|bill. ;|c23 cm

or something like this made-up, MODS-like markup:

<physicaldescription>
  <extent>
    <pagination>
       <pages type="introductory">9</pages>
       <pages type="numbered">74</pages>
    </pagination>
    <illustration />
    <height unit="cm">23</height>
  </extent>
</physicaldescription>

With the second, we can produce something like the first — or even the abbreviated display version. But it is considerably more difficult to create the auditory version from the first, particularly with the wide variation of punctuation encoding ISBD offers. It just isn’t machine actionable, which makes it difficult to transform, reuse, and translate that data in another context.

I’m reminded too of this recent quote from Jonathan Rochkind: “Of course, our legacy environment is even worse, with the ‘data model’ being supplied by an unholy combination of ISBD … and MARC….” It would be good to stop doing our data entry in the language of the computer (e.g. MARC). Based on the chat from the first webinar in the series, we wouldn’t expect catalogers to type out the XML fragment above. There should be computer-assisted workflows to capture the data and store it with all the required semantics. That XML would be used for machine-to-machine communication and transformation into the output desired by the user — be it a short-hand visual display or an auditory reading of information.

Footnotes

1. Coyle, Karen. “Library Data in a Modern Context.” Library Technology Reports 46.1 (2010): 5-13.

This week I sat in on the first of the three “Using RDA: Moving into the Metadata Future” webinars being hosted by ALA. This one was hosted by Karen Coyle with the title New Models of Metadata where she talked about library-specific efforts such asRDA and FRBR as well as the linked data effort in the wider world of information. There was a great deal of concern expressed in the chat window by participants about the future of cataloging, of cataloguers, and of MARC. The latter brought up memories of Roy Tennant‘s “MARC Must Die” declaration. My take away, though, isn’t that MARC is dead as much as MARC is a dead end.

Cover art from 'Library of the Dead' audio book

MARC, not dead yet?

What trips up our community even more, I think, is that we have a tendency to equate this communications format with mental model of how we describe things from a bibliographic point of view. We think of discrete records that describe these things rather than a network (or, more accurately, a graph) of interrelated nodes. This forces us to focus on the textual content of fields and not on the relationships between things. And in doing so, we are not making the best use of our limited efforts to describe the things in our curatorial care.

MARC may not be dead, but it is a dead end.

This is definitely becoming a habit…welcome to the fourth edition of DLTJ‘s Thursday Threads. If you find these interesting and useful, you might want to add the Thursday Threads RSS Feed to your feed reader or subscribe to e-mail delivery using the form to the left. If you would like a more raw and immediate version of these types of stories, watch my FriendFeed stream (or subscribe to its feed in your feed reader). Comments, as always, are welcome.

Defining Linked Data By Analogy

RDF is the grammar for a language of data. URIs are the words of that language. As in natural language, these words (i.e., the URIs) belong to grammatical categories. RDF properties (such as “isReferencedBy”) function a bit like verbs, RDF classes like nouns.

As in natural languages, where utterances are meaningful only if they follow a sentence grammar, RDF statements follow a simple and consistent three-part grammar of subject, predicate, and object. Analogously to paragraphs, RDF statements are aggregated into RDF graphs.

This is a posting from Thomas Baker on the W3C Library Linked Data exploratory group mailing list. It compares RDF to natural languages using analogies of grammar, words, sentences, and paragraphs. I think this is a useful way to think about RDF and linked data, although as initial introduction to the topic, you might want to see the presentation below.

RDF For Librarians presentation recording

The RDF model underlying Semantic Web technologies is frequently described as the future of structured metadata. Its adoption in libraries has been slow, however. This is due in no small part to fundamental differences in the modeling approach that RDF takes, representing a “bottom up” architecture where a description is distributed and can be made up of any features deemed necessary, whereas the record-centric approach taken by libraries tends to be more “top down” relying on prespecified feature sets that all should strive to make the best use of. This presentation will delve deeply into the differences between these two approaches to explore why the RDF approach has proven difficult for libraries, look at some RDF-based initiatives that are happening in libraries and how they are allowing different uses of this metadata than was previously possible, and pose some questions about how libraries might best.

Jenn Riley gave this hour-long presentation to the Indiana University Digital Library Brown Bag earlier this month. The URL to the slides synchronized to the audio recording is http://breeze.iu.edu/p48776227/. The presentation slides and the handout from the session are available as well. I highly recommend spending an hour with this presentation to learn about how linked data compares and contrasts with MARC records. (via Diane Hillmann)

The Future of the Federal Depository Libraries

[ProPublica's Dafna] Linzer’s expose of government tampering with a court docket is an example of the problem on which the LOCKSS Program has been working for more than a decade, how to make the digital record resistant to tampering and other threats. The only reason this case was detected was because Linzer created and kept a copy of the information the government published, and this copy was not under their control. Maintaining copies under multiple independent administrations (i.e. not all under control of the original publisher) is a fundamental requirement for any scheme that can recover from tampering (and in practice from many other threats).

David Rosenthal summarizes a story about how a published document from the U.S. government was changed and why we need highly-distributed copies of government documents to detect and recover from tampering. There are big implications here for the future of government documents depository programs.

ProPublica’s Guide to Mechanical Turk

Amazon Mechanical Turk – or mTurk – is an online marketplace, set up by the online shopping site Amazon, where anyone can hire workers to complete short, simple tasks over the Internet. Amazon originally developed it as an in-house tool, and commercialized it in 2005. The mTurk workforce now numbers more than 100,000 workers in 200 countries, according to Amazon. At ProPublica, we use it for tasks like collecting, reformatting, and de-duplicating data. This is a guide to journalists looking to use Mechanical Turk in their data projects. It’s meant for users who are already familiar with mTurk and are looking for ways to improve their results.

Do you have repetitive digital conversion or analysis jobs that can be broken down into manageable-sized chunks? ProPublica published this guide on using Amazon’s Mechanical Turk service to outsource this activity.

Did you know that Amazon offers a facility to make corrections to its catalog? Somewhere in the past few months someone mentioned this to me and I tried it out. (Unfortunately, it has been long enough now that I’ve forgotten who told me; if you are the one, please fess up in this post’s comments section. It was Ron Murray from the Library of Congress. Thanks, Ron!) And it works! Is this a model for crowdsourced corrections to library data?

Here is how it looks from a user’s perspective.

Step 1. Finding something to correct

Amazon page for 'How to Talk to Anyone' with typo

Step 2. Making the Correction

Excerpt of Amazon product information page with the 'update product info' link highlighted

Excerpt of Amazon Catalog Update Form

Preview of Amazon Catalog Updates

Submission confirmation page from Amazon Catalog Update service

Step 3. Getting Confirmation from Amazon

From: “gfix-noreply@amazon.com”
To: “peter@OhioLINK.edu”Subject: Your Amazon.com Catalog Update Request

==== This is an automated response message - please do not reply ====

Thank you for using the Catalog Update Form to send suggestions for

How to Talk to Anyone: 62 Little Tricks for Big Sucess in Relationships (ASIN 1593160267)

Your update has been accepted and processed. It will appear online within the next two to three business days.
Attribute: Title
Current value:
How to Talk to Anyone: 62 Little Tricks for Big Sucess in Relationships

Your suggestion:
How to Talk to Anyone: 62 Little Tricks for Big Success in Relationships

Data accuracy is highly important to us. We appreciate the time you have taken to submit your updates to us.

Best regards,

Catalog Department
www.amazon.com

And if you go to this product page now you’ll see the title has been corrected.

Would this Work for Libraries?

If we were to do it, I think it might have to be done by a bibliographic utility like OCLC who has ways to push the updated records to member libraries. Otherwise we run the risk of diluting the corrections across many individual library catalogs. Interestingly, this sort of user-generated correction facility one that the Open Library already provides. (Open Library is a wiki-like service that offers the ability for anyone to make changes to its records, much like how anyone can edit articles on Wikipedia.) So between Amazon and Open Library there is a continuum of workflows of mediated corrections to unmediated corrections for us to consider. This scheme, of course, begs us to consider the notion of distributed version control systems for handling our bibliographic data so that changes can be merged across many sources.

Lots to think about…

Jerome McDonough of the Graduate School of Library & Information Science at the University of Illinois at Urbana-Champaign presented a paper this summer at the Balisage conference with the title Structural Metadata and the Social Limitation of Interoperability: A Sociotechnical View of XML and Digital Library Standards Development.¹ The title is very hard to penetrate, but the contents of the paper lay bare a theory for why we don’t have large, swirling pools of shared digital objects that cross institutional silo boundaries.

Jerome lays the issue out right away. Paraphrasing from several papers, he says:

Despite its success, however, XML has not lived up to many librarians’ expectations within one area, that of interoperability…. Digital library developers have expected that shared use of an XML standard for structuring of content and metadata (what is commonly called “structural metadata” within the digital library community) would ensure content interoperability and provide a clean division between content and higher level tools and services designed to work with standardized encodings of that content. In practice, this goal has proved extraordinarily elusive. Experiments conducted by participants in the Library of Congress National Digital Infrastructure for Preservation Program (NDIIPP) to test the exchange of digital objects between repositories failed even when participants were using the same XML-based encoding format and producing valid XML instances to exchange.

What Jerome is referring to is the ability to readily move objects from one repository to another. This would seem inherently doable on the surface — the offering repository and the receiving repository are both using XML and perhaps even the same “structural metadata standard” (METS, MPEG-21, etc.). These standards provide “a structural grammar for the encoding of complex digital objects” — the kind of thing needed to move these complex digital objects around various repositories. Jerome lays out two reasons why this doesn’t occur. First, there is a tremendous amount of flexibility in the metadata standards as a result of efforts to make each of the standards abstract enough to encode every conceivable structure. Document authors have choices in the depth of levels of description, labeling of object components, and arrangement of the object structure relative to creation of one or more interrelated descriptive metadata files. The second issue he identifies is the problem of “standards independence”, or the desire by the document standard author to have his/her metadata schema stand alone. Relying on other schemas may decrease the usefulness of the new standard to other organizations and environments.

The paper is a rich history of structural markup standards that have lead the profession to where it is today. He concludes with suggestions for the digital library community to move past this problem. One solution is to declare that our community is more concerned with using the flexibility inherent in the metadata standards for local needs than we are with sharing digital objects across silos. Counter to this is to refine standards to reduce the flexibility so as to increase the chances that the standards will promote interoperability. Jerome also offers the idea of promoting the activity of converting between various metadata formats to a more recognized and valued level. (He notes, for instance that the XSL stylesheets created by the Library of Congress that convert MODS into MARC/XML and back are omitted from the ‘Standards of the Library of Congress’ web page.)

Via Lorcan Dempsey.

Footnotes

1. McDonough, J. (2008). Structural Metadata and the Social Limitation of Interoperability: A Sociotechnical View of XML and Digital Library Standards Development. InBalisage: The Markup Conference Proceedings 2008. Montréal, Canada. Retrieved October 2, 2008, from http://balisage.net/Proceedings/html/2008/McDonough01/Balisage2008-McDonough01.html.

Earlier this week I received an e-mail from the director of the ISSN International Center announcing a session at the ALA Annual Conference in Anaheim to talk about the “linking ISSN”. Abbreviated ISSN-L, this is a new addition to the revised ISSN standard (ISO 3297, published last August) that allows for the collocation of separate ISSNs under a single ISSN-L. The ISSN standard now explicitly states that an ISSN is a unique identifier for a specific serial in a defined medium. In other words, separate ISSN should be assigned to each different medium version of a serial. The ISSN-L table brings these separate ISSNs together.

The FAQ I received that goes along with the e-mail announcement has several interesting statements. I’ve extracted the most interesting, at least from my perspective, here:

The purpose of the linking ISSN is to provide a tool for grouping, or collocating, the various medium versions of a resource, for instance, the print and online versions of a journal. … Those involved in the production, distribution, management of, and access to serial resources have expressed the strong desire that the ISSN system meet two different needs:

• The need for the ISSN to identify the various medium versions of a continuing resource, for product management purposes. To meet this need, separate ISSN are assigned to the various medium versions of a resource.
• The need for a collocating, or grouping mechanism that would bring together various medium versions, and thus facilitate content management. The linking ISSN (ISSN-L) has been defined to meet this currently unmet need.

The linking ISSN is a new function for the ISSN system — not a new identifier. … The first ISSN assigned in the ISSN Register to any medium version of a continuing resource is designated by default to function also as the linking ISSN and applies to all other medium versions of that resource identified in the ISSN Register. The linking ISSN is labelled (for eye-readable purposes) as “linking ISSN” or “ISSN-L”. A linking ISSN is designated for each continuing resource identified in the ISSN Register, even if the continuing resource is issued in only one medium. Only one linking ISSN is designated regardless of how many different medium versions of a continuing resource exist.

The ISSN-L should always be treated, for computer processing purposes, as a separate data element. For example, in MARC formats, which are used in the ISSN Register, ISSN-L is input in a separately tagged subfield in each of the ISSN Register metadata records to which it pertains. It is important to note that ISSN-L should be processed and used separately from medium-specific ISSN. In applications based on tables or indexes, ISSN-L should not be included in the same tables or indexes as medium-specific ISSN.

The designated ISSN-L is made available in several different ways:

• via a table which lists the ISSN-L and the corresponding ISSN linked to the ISSN-L. This table is available free of charge on the ISSN IC web site. [See note below.]
• via the ISSN Register: (each metadata record in the ISSN Register includes the medium-specific ISSN assigned to the resource described in the record, and the designated linking ISSN, as separate data elements);
• via the ISSN National Centres, which communicates to publishers the ISSN-L designated for newly-assigned ISSN,
• via the resources themselves, provided that publishers print or display this information according to the recommendations in the standard.

In order for the ISSN-L to work effectively, publishers will need to clearly indicate when they are using an ISSN-L as opposed to an ISSN. The ISO standard’s recommendations for printing and displaying ISSN-L are as follows: the linking ISSN shall be clearly distinguished as such by use of the label ISSN-L. In such cases, the label ISSN-L shall be written in uppercase and a space shall precede the 8 digits of the linking ISSN. Example: ‘ISSN-L 0251-1479′.

No programmatic method can be used to determine ISSN-L on the basis of one of the medium-specific ISSN, nor is there a programmatic way to determine the group of medium-specific ISSN associated with one ISSN-L. This is due to fundamental characteristics of the ISSN system: ISSN have no inherent meaning, and they are distributed sequentially. ISSN are assigned by national centres around the world, and a new medium version may appear at any time, perhaps published in a different country; this cannot be predicted and thus there is no programmatic way to associate an ISSN with its corresponding ISSN-L.

The assignment policy of the Standard now explicitly specifies that ISSN is a unique identifier for a specific serial in a defined medium. Therefore separate ISSN are assigned to each particular medium version of a serial. … If some publishers use the same ISSN for different medium versions of a serial, they deprive their users of the means to identify the medium- specific versions of that serial for ordering, claiming, etc. However, this should not interfere with the ISSN-L. The single ISSN will become the ISSN-L that can be used for collocating functions.

ISSN-L is a tool that aims at facilitating collocating functions. To perform these functions adequately, ISSN-L and the related ISSN have to be present in OpenURL knowledge bases. At this time, various scenarios can be envisaged. The desired end result is described as follows: The request must use the data available in the citation. It is the job of the resolver to match the identifier to the appropriate resource. It is the resolver that will make use of ISSN-L to relate the various medium of an ISSN to each other and find one to satisfy the request. One should be able to put in a request (for example an OpenURL) using any of the ISSN and separately and additionally request that the electronic copy is desired.

One note: I can’t find the ISSN-L table on the http://www.issn.org/ website. In a follow up discussion with Françoise Pellé (Director of the ISSN International Centre) I learned that it isn’t there yet, but they intend to put it there.

This is an interesting, well, kluge. It provides a neat amount of backwards compatibility — for publications that only have one medium, that publication’s ISSN automatically becomes its ISSN-L. The publishers (presumably) would need to take proactive action to tell the ISSN registrar that two ISSN are two mediums of the same publication; hopefully the word will get out and all affected publishers will do so.

It doesn’t effectively replace the xISSN service from OCLC because the ISSN-L table only gives current links. The description of xISSN says ISSNs are related in two different ways: different editions of same serial (such as print and online editions) and historical relationships (ISSN changes that result from title changes, mergers, splits, etc.). ISSN-L only handles the former (different editions) relationship type, not the latter (historical) relationship type. The ISSN-L table is (reportedly) free, however, and the xID service require an OCLC network membership. (While this posting was in draft form, Tim McCormick of OCLC announced that effective immediately, xID services from OCLC — that is, xISBN, and the forthcoming xISSN — will be included at no additional cost with all OCLC cataloguing subscriptions.

I hope to hear more after ALA Annual. Unfortunately, I think I have a conflict with the proposed meeting on Friday afternoon of ALA, so if anyone else hears anything please blog about it. (Trackbacks to here would be appreciated.)

Updates from Information at ALA

MARC codes were approved by MARBI a few months ago. Current ISSN-L identifiers will be put in MARC21 field 022 subfield ‘l’. Cancelled ISSN-L identifiers will be put in MARC21 field 022 subfield ‘m’. (Every record will have a subfield ‘l’ or a subfield ‘m’, even if it is in a single format.)

Retrospective designation uses lowest ISSN from the cluster linked via 776 field. As on-going ISSN assignments are made, the ISSN-L will be the first assigned out of any media. (May not always be the lowest in numerical order because of how ISSNs are allocated to ISSN centers.)

The crossreferencing linking table for ISSN-L has not yet been published. The international ISSN center is also considering a web service that would send back all of the associated ISSNs for an ISSN-L.

Launch is at IFLA in August 2008. Expected implementation before end of 2008. (There is of course some catch-up time as library automation vendors add this capability to individual systems.)

The text was modified to remove a link to http://ala.org/ala/lita/litamembership/litaigs/igstandards/standards.cfm on June 9th, 2011.

This morning I got an invitation to join ResearcherID, a new author profile service from Thomson Scientific. The service sounds nice enough — who doesn’t want to take steps to avoid confusion between authors? — and if you have access to other Thomson products (like ISI Web of Knowledge or Web of Science) it may be even nicer. I’m all for the establishment of unique identifiers so we can start to do some interesting things with co-citation analysis and mining the web of connections in journal articles, but I’m not signing up. At least not yet.

“A Unique Identifier”

A unique identifier

When you register, you are assigned a unique ID number that expressly associates you with your published works, regardless of any possible nomenclature confusion or institutional affiliation changes. These unique identifiers allow everyone who accesses ResearcherID.com to easily find a specific author’s work, avoiding the common problem of author misidentification.

With the service, I can assert that particular citations are papers that I have written. (Interesting sidebar — I wonder if the ResearcherID service attempts any sort of automated and/or manual verification of the claim that I was an author/co-author of a paper.) I do this either by uploading a list of citations (in Thomson’s RIS format only) or selecting them from ISI Web of Knowledge or Web of Science (if I’m at a subscribing institution). Then I have a nicely formatted web page with all of my papers. Granted, it isn’t the only way I can go about doing this, but the Thomson service does seem to make a point about distinguishing itself by assigning me a “ResearcherID” in the process.

There seems to be something more going on here, though. Why go through the effort of assigning me an alpha-numeric string and publicizing it if it isn’t going to be used somewhere else?

But what about the other end of the use case?

The End User License Agreement (EULA) are pretty standard stuff, but buried in the middle is this:

5.3. Except as described in this Agreement, You may not use, copy, adapt, translate, modify, sell, distribute or otherwise create derivative databases, services or works of or based on the ResearcherID Service (including the Researcher Registry) or the materials accessible in the ResearcherID Service.

That would seem to effectively eliminate the ResearcherID(tm) as a useful identifier in other systems. Presumably without paying Thomson for the right to use the identifier. And without knowing the cost of using the identifier in other systems (there doesn’t seem to be any information published on ways to use the identifier elsewhere, even though an earlier section of the EULA describes such usage for “Sponsored Services”), I’m not ready to sign onto (and therefore effectively promote) such a service.

The full End User License Agreement

ResearcherID Terms of Use and Privacy Policy

This agreement (Agreement) is a legal agreement between you, the user, (You or Your) and Thomson Scientific Inc. having its principal place of business located at 3501 Market Street, Philadelphia, PA 19104 (TS, We or Our) and describes the terms and conditions on which you may access and use and TS will provide the ResearcherID service described in Section 1 below (the ResearcherID Service), which includes the allocation to You of a unique Researcher ID (the ResearcherID).

BY CLICKING ON THE "ACCEPT" BUTTON BELOW YOU AGREE TO BE LEGALLY BOUND BY THE FOLLOWING TERMS AND CONDITIONS. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, TS IS UNWILLING TO PROVIDE THE RESEARCHERID SERVICE TO YOU AND YOU MUST NOT CLICK THE ACCEPT BUTTON BELOW OR CONTINUE WITH THE REGISTRATION PROCESS.

We reserve the right to modify this Agreement at any time by posting amended terms in the ResearcherID website at the following URL: http://www.researcherid.com (the ResearcherID Website). Your continued use of the ResearcherID Service indicates your acceptance of the amended Agreement.

1. PROVISION OF RESEARCHERID SERVICE

1.1. Once you have completed the registration process for the ResearcherID Service, TS will:

1.1.1. allocate a unique ResearcherID to You, which You can use to associate articles, theses, reports, speeches, or other materials that you have written or contributed to with Yourself and Your ResearcherID;

1.1.2. maintain a database (the Researcher Registry) in which it will store information or metadata (such as metadata relating to the articles that You have associated with Your ResearcherID or to institutions or organisation with which you have an affiliation, whether past or present) that: (i) You provide during the registration process or subsequently update; or (ii) You provide or we collect in connection with You using Your ResearcherID (such as when you publish articles and include Your ResearcherID as an additional identifier for You) (ResearcherID Data); and

1.1.3. publish certain information and data from the Researcher Registry on the ResearcherID Website and in other Sponsored Services (defined in Section 1.2 below).

1.2. TS may make interfaces to the Researcher Registry available for use in connection with products or services provided by TS, its Affiliates (such as ISI Web of Knowledge and Scholar One) or certain relevant authorised third parties (such as publishers and societies) (Sponsored Services) to:

1.2.1. enable such Sponsored Services to provide additional ResearcherID Data to the Researcher Registry, which You provide or which those Sponsored Services collect in connection with Your use of Your ResearcherID in connection with those Sponsored Services;

1.2.2. create new tools for use in connection with Sponsored Services (such as tools which help users more easily identify Your articles or which enable You to find collaborators or which allow other people to find You for collaborations); and

1.2.3. enhance existing Sponsored Services (such as providing more relevant search results to improve end user experience and to enhance performance measurement applications).

1.3. TS will not allow any of Your personally identifiable information stored in the Researcher Registry to be published (whether on the ResearcherID Website, Sponsored Services or otherwise generally to third parties) where you have indicated a preference to restrict its publication. For further details of how TS will process your personally identifiable information, please refer to Section 4 below.

1.4. You understand and agree that:

1.4.1. by using the ResearcherID Service and Your ResearcherID You will be providing ResearcherID Data to the Researcher Registry and You grant a royalty-free, perpetual, irrevocable license to:

(a) TS, its affiliates and applicable authorised third parties to use the ResearcherID Data in the course of providing or using the ResearcherID Service, Sponsored Services and the ResearcherID Website; and

(b) TS to reformat, extract, adapt or translate any ResearcherID Data;

1.4.2. all information publicly posted or privately transmitted by You through the ResearcherID Service or through any Sponsored Services or the ResearcherID Website is Your sole responsibility and TS will not be liable for any errors or omissions in the ResearcherID Data stored in the Researcher Registry.

2. CONDITIONS OF USE OF RESEARCHERID SERVICE

2.1. You agree and undertake that You: (i) are over the age of 18; (ii) have not been removed or suspended from the ResearcherID Service at anytime; (iii) do not have more than one active ResearcherID account; and (iv) shall not sell, transfer, pledge or otherwise trade your ResearcherID to another person.

3. YOUR OBLIGATIONS

3.1. If You have not registered to use the ResearcherID Service and accepted the terms and conditions in this Agreement and/or if You do not comply with the Conditions of Use set out Section 2 above, You should not use the ResearcherID Service.

3.2. You agree and undertake that the information You provide during the registration process or which You subsequently update shall be accurate and up to date. You agree to regularly check Your profile in the Researcher Registry to ensure that it is accurate and up to date.

3.3. Your username and password are confidential to TS. You should not disclose Your login details to any third party or allow any such third parties to access the ResearcherID Service, whether on Your behalf or otherwise. You will be fully responsible for all use of Your ResearcherID account where the correct login details have been provided to access the account.

3.4. You will not:

3.4.1. falsely state, impersonate, or otherwise misrepresent your identity, including but not limited to the use of a pseudonym, or misrepresent your current or previous positions and qualifications, or your affiliations with a person or entity, past or present or falsely attribute work to Yourself where You are not the author of or You have not contributed to the work.

3.4.2. create a denial of service, hack into, make unauthorised modifications of or otherwise impede the ResearcherID Service, whether by the use of malware or otherwise, intercept the communications of others using the ResearcherID Service or falsify the origin of the Your communications or attempt to do any of these acts;

3.4.3. use the ResearcherID Services for any illegal or injurious purpose or to publish, post, distribute, receive or disseminate defamatory, infringing, confidential, obscene, or other unlawful material or to threaten, harass, stalk, spam, abuse, or otherwise violate the legal rights (including without limitation rights of privacy and publicity) of others.

4. PROCESSING OF PERSONALLY IDENTIFIABLE INFORMATION

4.1. In the course of using the ResearcherID Service, TS will collect, store and process ResearcherID Data as described in Section 1. Some of this ResearcherID Data will be personally identifiable information (personal information). If you choose not to provide any personal information where requested for the ResearcherID Service, TS may not be able to provide You with the ResearcherID Service.

4.2. You understand and agree that TS may disclose ResearcherID Data (including Your personal information) if required to do so by law or where We believe (acting reasonably) that such disclosure is reasonably necessary to comply with any legal process or to protect the rights of TS, its Affiliates or applicable third parties.

What personal information We Collect using the ResearcherID Service

4.3. When you first register to use the ResearcherID Service, You will be asked to provide certain personal information such as name (including all names and pseudonyms under which you publish articles and other works), address, affiliated institutions and organisations (and your position within those institutions and organisations), email address and other biographical information. You may also be asked to submit additional personal information, or TS may collect additional information about You which will be linked to You and stored in the Researcher Registry, in the course of Your use of the ResearcherID Service (as described in Section 1 above), such as articles you have written or contributed to, keywords and subject areas which relate to your areas of specialisation or with which You want to be associated.

4.4. We may monitor and record e-mails and telephone calls to the Thomson Scientific helpdesk. We do this for training purposes and to make sure the problems and issues You bring to Our attention are resolved promptly and correctly. We may also monitor Your use of the Researcher Registry, Sponsored Services and the ResearcherID Website to ensure compliance with this Agreement and to ensure the security and availability of the ResearcherID Service.

What We Do With the Information We Collect

4.5. We will use and process Your personal information to provide the ResearcherID Service to You including, without limitation, maintaining the Researcher Registry, for account administration purpose and for communicating general information to You about the ResearcherID Service including maintenance updates and general changes to the ResearcherID Service. We may also communicate information concerning new features, services and tools including additional Sponsored Services where you have requested to receive this information.

4.6. We may aggregate personal information into demographic data about Our users to enable Thomson Scientific to provide the most relevant and valuable services to its user community.

4.7. We may engage third parties to provide some of the processing activities described in this Agreement on Our behalf. We may allow certain third parties to access the Researcher Registry and to provide ResearcherID Data to the Researcher Registry in the course of providing Sponsored Services. We may also provide Your information to law enforcement agencies and other authorities where We are required to do so by applicable laws. Otherwise TS does not make your information available to any third parties without Your express consent.

4.8. You understand and agree that third party providers of Sponsored Service may collect Your personal information in connection with Your use of the Sponsored Service. Those third parties may have different privacy policies and practices, which You should confirm with those third parties.

IP Address

4.9. Thomson Scientific may use your IP address to help diagnose problems with its servers. Your IP address may also be used to gather broad demographic information about Thomson Scientific's population, so we can make Our services more effective. We may also recognize Your IP address as an aid to presenting appropriate welcome messages and to authenticate Your access to the ResearcherID Services.

Security

4.10. The ResearcherID Service has been designed with Your needs for privacy and security in mind. We follow stringent procedures to protect our servers from attack and use encryption techniques to protect You personal information from unauthorised disclosure, alteration and destruction.

4.11. We also implement stringent technical and organisational policies and procedures to protect Your personal information off-line. All information stored in the Researcher Registry is restricted so that only employees who need the information to perform specific tasks in relation to the Researcher Registry are granted access to personally information. Finally, the servers that we store personal information on are kept in a secure environment.

How You can correct or update Your personal information and preferences

4.12. You can change Your registration information and preferences at anytime in the Edit My Profile section for the ResearcherID Service on the ResearcherID Website or in any Sponsored Service or otherwise by contacting the Thomson Scientific helpdesk (details of which can be found at the following URL: http://scientific.thomson.com/support/techsupport/).

Complaints and Further information about Thomson Scientific's privacy policies

4.13. We are committed to working with you to resolve, quickly and fairly any complaints you may have about this Privacy Policy and/or Our processing of Your personally identifiable data. If you have any questions or comments or if you would like further information about TS's privacy policies, please refer to our Data Privacy team (dataprivacy@thomson.com).

5. INTELLECTUAL PROPERTY RIGHTS, OWNERSHIP AND LIMITED LICENCE

5.1. The ResearcherID Service contains proprietary technology and copyright material owned by Thomson Scientific, Inc. and/or its third party licensors. All use of the ResearcherID Service and the materials accessible in ResearcherID Service are restricted and subject to Thomson Scientific's prior written consent.

5.2. 'Thomson', the Thomson starburst logo and 'ResearcherID', are trade or service marks of The Thomson Corporation or its affiliated companies. All other product and service names cited are trademarks of their respective companies.

5.3. Except as described in this Agreement, You may not use, copy, adapt, translate, modify, sell, distribute or otherwise create derivative databases, services or works of or based on the ResearcherID Service (including the Researcher Registry) or the materials accessible in the ResearcherID Service.

5.4. You may only reverse engineer, decompile or disassemble any of the software or technology contained in the ResearcherID Service to the extent expressly permitted by law, where such rights cannot be modified by agreement.

6. DISCLAIMER AND LIMITATION OF LIABILITY

6.1. TS, Its affilliates and third party suppliers make no warranty or representation as to the accuracy, completeness or correctness of any materials contained within the ResearcherID Service (including the Researcher Registry and the ResearcherID Website) or as to whether the provision of ResearcherID Service will be uninterrupted or error free nor that all errors in the rEsearcherID Service or the materials contained within ResearcherID Service will be corrected. In particular, TS, its affiliates and third Party Suppliers will not be liable for (i) any corruption, alteration, damage, loss or mistransmission (as applicable) of Your or any third party's data, software, hardware or systems; and (ii) loss or damage resulting from the inadequacy of security of data during transmission via public electronic communications networks or facilities.

6.2. The ResearcherID Service may Include Services or Internet Sites (including Sponsored Services) or contain links to Such services or Internet sites operated by third parties (other than TS or its affiliates). Where such links exist they are provided for the Your convenience only. TS does not control such third party services and Internet sites, and is not responsible for their contents or supply. TS's inclusion of links to such Internet sites or Services in connection with The ResearcherID Service does not imply any endorsement of such Services or Internet site or any information or material that is made available to you in connection with such Services or Internet sites or any association with their operators and TS makes no warranties in respect of such Services or Internet sites.

6.3. Neither TS nor ANY OF its Affiliates or Third Party Suppliers will be liable in contract, tort (including negligence) or otherwise for any indirect, special, punitive or consequential loss or damage arising out of or in connection with this Agreement or Your use of the ResearcherID Service, however such indirect loss or damage may arise.

6.4. THE MAXIMUM AGGREGATE LIABILITY OF TS, its Affiliates and third party suppliers HEREUNDER SHALL BE LIMITED TO THE FEE PAID BY YOU FOR receipt of the ResearcherID Service, WHICH IS ZERO DOLLARS ($0).

7. TERMINATION

7.1. TS may terminate this Agreement at any time without prior notice for any or no reason.

7.2. You may terminate this Agreement at any time by providing at least thirty (30) days' prior written notice to the Thomson Scientific helpdesk.

8. GENERAL

8.1. Neither You nor TS will be liable to the other for any failure or delay in the performance of its obligations under this Agreement (except for payment of money) due to circumstances beyond its reasonable control.

8.2. Failure or delay by either party in exercising any right or power hereunder will not constitute a waiver of such right or power.

8.3. You shall not assign, sub-license or delegate any of Your rights or obligations under this Agreement without the prior written consent of TS. TS may sub-contract or transfer all or any or its rights or obligations under this Agreement to any third party, provided that in the case of sub-contracting, TS shall remain responsible for the performance by its sub-contractors of such obligations under this Agreement. Any assignment, sub-licensing or delegation in breach of this Section 8.3 shall be null and void.

8.4. Any notice given under this Agreement must be in English, in writing, signed by or on behalf of the party giving it and delivered personally or sent by pre-paid post to the address of the other party or by email to the email address of the other party. Any such notices will be treated as being received on the date that the notice is recorded as having been delivered.

8.5. This Agreement contains the entire agreement between You and TS as to its subject matter and supersedes any and all written or oral prior agreements and understandings in relation thereto. You acknowledge that in entering into this Agreement You have not relied on any representations made by TS that is not expressed in this Agreement. This Section 8.5 shall not be construed as excluding either party's liability in respect of any fraudulent statements.

8.6. If any provision of this Agreement is determined to be illegal or unenforceable by any court of competent jurisdiction, it shall be deemed to have been deleted without affecting the remaining provisions.

8.7. This Agreement will be governed by and construed in accordance with the laws of the Commonwealth of Pennsylvania and You irrevocably submit to the exclusive jurisdiction of the federal and state courts located within the Commonwealth of Pennsylvania.

8.8. Each Party intends that TS's Affiliates and Third Party Sponsors shall be third party beneficiaries of this Agreement and, thus, entitled to enforce this Agreement as if an original party hereto. There shall be no other third party beneficiaries.

In reading a background paper for the American Social History Online portal, I was reacquainted with a paper by Muriel Foulonneau, Thomas Habing and Tim Cole from UIUC called “Automated Capture of Thumbnails and Thumbshots for Use by Metadata Aggregation Services.”¹ This is the abstract:

The practice of including thumbnails in short record displays, increasingly common in local implementations, is being adopted by metadata aggregation service providers as well. In addition, thumbnails and Web thumbshots have begun appearing as part of Web search results. This article reports on a project at the University of Illinois at Urbana-Champaign (UIUC) to make more comprehensible heterogeneous resources available on the UIUC CIC metadata portal by incorporating thumbnails and thumbshots of image and Webpage resources in the context of the OAI Protocol for Metadata Harvesting. In addition to thumbnails provided by partner data providers, UIUC has developed an automated process to generate thumbnails and thumbshots from the Webpages resources pointed to by the metadata records.

The paper cites dissatisfaction with results from metadata portals that consist exclusively of textual descriptions of the objects. It also cites studies that show the addition of thumbnail images to the results display improves user satisfaction. With that in mind, UIUC wrote Thumbgrabber — a Windows application written in Visual Basic that uses Internet Explorer to find images in websites and/or take image snapshots of web pages as they have been rendered. In the UIUC context, the application is fed URLs from records harvested via OAI-PMH, although it would seem like it would be able to process any arbitrary list of URLs.

This is a useful tool to keep in mind as we think more about aggregating the metadata records into vertical (subject-specific) portals and repurpose metadata records in other ways.

The text was modified to remove a link to http://cicharvest.grainger.uiuc.edu/thumb.asp on January 28th, 2011.

Footnotes

1. Foulonneau, M., Habing, T.G., Cole, T.W. (2006). Automated Capture of Thumbnails and Thumbshots for Use by Metadata Aggregation Services. D-Lib Magazine, 12(1) DOI: 10.1045/january2006-foulonneau

Boundaries are being blurred between the academic and commercial Web, between library resources, between the citation and the item itself. Students have no patience with these arbitrary boundaries; they want information, and they want it now, wherever it may be located.¹

Earlier this year, the New England Law Library Consortium (NELLCO) announced that they had received a grant from the Institute of Museum and Library Services to build a “Universal Search Solution” — a ‘one-box’ search into a unified index of a range of electronic resources. Indexed databases include OPACs, subscription-based resources, and selected free web resources. It is a two year grant to build and implement the tool for NELLCO members and release the code into open source. Index Data will be contracted to build the tool.

The tool “will be based on open standards and open source software, and will result in the creation of a … master index of material, including participating library catalogs, as well as subscription-based databases and open content, special collections, and other resources that a participating library wishes to make discoverable to its patrons.” ² The project specifications include the concept of differentiating search results based on the user’s institutional affiliation — search results from the user’s OPAC and hits from commercial data sources in the unified index that are limited by license to just that user’s institution. “Technologically, the Universal Search Solution will combine multiple technologies (consolidated indexing and data storage; metadata harvesting; and metasearching) to put together a single window to disparate resources.”³

I spoke with Tracy Thompson earlier this week about the project. The concept is an out-growth of an earlier pilot to use a Google Search Appliance (GSA) to create the unified index. The pilot was technologically successful, but ran into problems in the business model for the GSA because the pricing was based on the number of “documents” and from the GSA perspective each record indexed in a database was a document. (To give a perspective, the GSA page says the base model “starts at $30,000 to search up to 500,000 documents”⁴ — and how many bibliographic records are in our OPACs, just as a baseline for costing out a GSA?)

Current Status

In broad strokes, the first year is geared mainly towards building the tool. In the second year, the IMLS grant will fund the implementation of the tool for interested NELLCO members. After the grant period, NELLCO expects they will be able to sustain the implementation by subscription fee from the members. As described earlier, this is a consortial product/service, so there are already some economies of scale to be gained by not implementing redundant hardware/support at many local institutions.

A Different Model for Open Source Development

The grant also offers a new model for libraries to obtain affordable software services that are under their control. It combines the powerful financial leverage of IMLS and the organizational capabilities of NELLCO and its membership with the software development expertise of Index Data to bring cutting edge open source software and services to all types and sizes of libraries — affordable and with commercial support — but without vendor lock-in.

The tension between the inherent values of commercial, closed-source software vendors and higher education institutions (with an acknowledging nod towards commercial support for open source solutions) has been discussed on DLTJ before. The IMLS/NELLCO/Index Data collaboration suggests a new way for software tools to be built: a granting agency funds the initial hurdle of software development, and then the project transitions to self-supporting either through subscription charges that are in the self-interest of participants or through the sweat equity of participant-developers.

The text was modified to update a link from http://www.nellco.org/IMLS/Press%20Release.pdf to http://www.nellco.org/index.cfm?fuseaction=Feature.showFeature&featureid=21&pageid=4 on January 20th, 2011.

The text was modified to update a link from http://www.nellco.org/IMLS/Press%20Release.pdf to http://www.nellco.org/index.cfm?fuseaction=Feature.showFeature&featureid=21&pageid=4 on January 20th, 2011.

The text was modified to remove a link to http://www.uwec.edu/library/aboutUs/who/cox.htm on January 20th, 2011.

Footnotes

1. Cox, Christopher. An Analysis of the Impact of Federated Search Products on Library Instruction Using the ACRL Standards. portal: Libraries and the Academy. 6(3), July 2006, pp. 253-267.
2. From the NELLCO press release.
3. From the Index Data press release.
4. This figure is on the GSA page at the time this posting is being published, but it is also on the 8-Aug-2007 copy of the page in the Internet Archive.