ALA Annual in Chicago was the usual flurry of old friends, Powerpoint presentations, and exposure to topics new to me. The blogger's get-together put together by the It's all good folks and generously hosted by OCLC was certainly one of the highlights. I've been a bit tentative in promoting my blog to date, so it was nice to mingle with other bloggers and talk shop (and beyond!). Another major highlight was Kevin Clarke's presentation on XOBIS. Nice to finally meet you, Kevin!
I spent most of my time at ALA attending presentations I "had" to attend--those related to my daily work. I was able to spend a small amount of time expanding my horizons, but I wish I could have done more. And this schedule is without being involved in any ALA committees that meet during the conference. There is simply too much going on to take advantage of it all.
On another note: on the trip home I started reading, but didn't finish, Martha Yee's recent paper outlining a "MARC 21 Shopping List." I should hold any substantial comment until I finish the article, but so far I'm impressed. The approach of looking very precisely at the criticism of MARC and current cataloging practice to determine what exactly is being criticized, I believe, is long overdue. I do find myself thinking of counter-arguments to some of the conclusions, however. But intelligent discourse is absolutely what we should be striving for!
Tuesday, June 28, 2005
Thursday, June 23, 2005
Coming out of the woodwork
I've been noticing lately just how progressive librarians are. It gives me a nice warm fuzzy feeling inside every time I see evidence of this phenomenon.
FRBR is a good example. A colleague of mine recently described FRBR as a "religion," and I think that's not entirely untrue. But I'm increasingly seeing rank-and-file librarians (not just us "digital" folks or special collections librarians who do things "differently" anyways, according to one popular perception) show an interest in it. These folks commonly just want to learn what it is and what it can do for them. They aren't interested in jumping on a bandwagon just to be there. Rather, they genuinely want to evaluate for themselves the value of the model to them and their users. Sure, there are now and will always be extremists on both sides of the issue. I know librarians who want nothing to do with FRBR, and I know others who insist nothing from today's bibliographic control practices will be of any use in five years. But thankfully most of us fall somewhere in the middle.
I see huge numbers of librarians willing to talk about their ideas, even if they represent a departure at some small or vast level from current practice. I see huge numbers of librarians taking analytical approaches to solving real access problems they deal with every day. I see huge numbers of librarians keeping the overall goals of access and preservation of intellectual output foremost in their minds as they look for solutions. I see huge numbers of librarians having lively, interesting, professional discussions about options for achieving these goals. I love my job.
FRBR is a good example. A colleague of mine recently described FRBR as a "religion," and I think that's not entirely untrue. But I'm increasingly seeing rank-and-file librarians (not just us "digital" folks or special collections librarians who do things "differently" anyways, according to one popular perception) show an interest in it. These folks commonly just want to learn what it is and what it can do for them. They aren't interested in jumping on a bandwagon just to be there. Rather, they genuinely want to evaluate for themselves the value of the model to them and their users. Sure, there are now and will always be extremists on both sides of the issue. I know librarians who want nothing to do with FRBR, and I know others who insist nothing from today's bibliographic control practices will be of any use in five years. But thankfully most of us fall somewhere in the middle.
I see huge numbers of librarians willing to talk about their ideas, even if they represent a departure at some small or vast level from current practice. I see huge numbers of librarians taking analytical approaches to solving real access problems they deal with every day. I see huge numbers of librarians keeping the overall goals of access and preservation of intellectual output foremost in their minds as they look for solutions. I see huge numbers of librarians having lively, interesting, professional discussions about options for achieving these goals. I love my job.
Friday, June 17, 2005
DCMI & Bibliographic Description
This week the Dublin Core Metadata Initiative published a new recommendation, "Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata." I'm finding it to be a muddled mess of possibilities and examples with few real, clear guidelines for an implementer to follow.
The recommendation is described as emerging from the need for describing journal articles in DC. The recommendations tend to center around putting the information that was previously problematic (journal title, volume number, issue number, page range, etc.) within a bibliographicCitation refinement for dc:identifier, while getting the rest of the citation information from other parts of the DC record. "Optionally, but redundantly, these details may be included in the citation as well." This optional part has huge consequences for anyone using DC metadata to get to these citations. One could never know if the complete citation is present in the dc:identifier.bibliographicCitation element, or if one needs to look elsewhere for information to complete the citation. Also, it results in a situation where some of the data needed for this citation is clearly fielded (author in dc:creator, article title in dc:title, etc.), but the rest of it is not. This is hardly an elegant solution to the problem at hand.
Also, "there are no recommendations for providing bibliographic citations in simple Dublin Core." However, it is "suggested" that citation information be put in dc:identifier or dc:description. How is anybody suppposed to use DC for this purpose if the "experts" on it can't bring themselves to turn a "suggestion" into a "recommendation?" This document says to all of us out in metadata-land that there's a solution (actually, TWO solutions - identifier and description - choose between them randomly!), but the powers that be can't or won't formally endorse it, perhaps because it's viewed as a hack. This passive-aggressive "well, we see you have a problem and here are some possible ways to solve it on an official-looking document, but we're not going to tell you that we think any of these solutions are a good idea" crap is really starting to get on my nerves.
I'm also confused about something. bibliographicCitation is a refinement of dc:identifier, and therefore by the DC "dumb-down" rule is a type of identifier. The recommendation says, "dcterms:bibliographicCitation is an element refinement of dc:identifier, recognising that a bibliographic resource is effectively identified by its citation information." But then it goes on to say, "In Dublin Core Abstract Model terms the value of the dcterms:bibliographicCitation property is a value string, encoded according to a KEV ContextObject encoding scheme. It is not intended to be the resource identifier, which for a journal article would probably use an appropriate URI scheme such as DOI." So which is it? Is bibliographicCitation an identifier or not? Is the second quote using "identifier" to mean something different than dc:identifier without telling us? I'm willing to assume for now what I see as a contradiction here comes from my purely surface-level understanding of the DC Abstract model. But maybe not...
The recommendation is described as emerging from the need for describing journal articles in DC. The recommendations tend to center around putting the information that was previously problematic (journal title, volume number, issue number, page range, etc.) within a bibliographicCitation refinement for dc:identifier, while getting the rest of the citation information from other parts of the DC record. "Optionally, but redundantly, these details may be included in the citation as well." This optional part has huge consequences for anyone using DC metadata to get to these citations. One could never know if the complete citation is present in the dc:identifier.bibliographicCitation element, or if one needs to look elsewhere for information to complete the citation. Also, it results in a situation where some of the data needed for this citation is clearly fielded (author in dc:creator, article title in dc:title, etc.), but the rest of it is not. This is hardly an elegant solution to the problem at hand.
Also, "there are no recommendations for providing bibliographic citations in simple Dublin Core." However, it is "suggested" that citation information be put in dc:identifier or dc:description. How is anybody suppposed to use DC for this purpose if the "experts" on it can't bring themselves to turn a "suggestion" into a "recommendation?" This document says to all of us out in metadata-land that there's a solution (actually, TWO solutions - identifier and description - choose between them randomly!), but the powers that be can't or won't formally endorse it, perhaps because it's viewed as a hack. This passive-aggressive "well, we see you have a problem and here are some possible ways to solve it on an official-looking document, but we're not going to tell you that we think any of these solutions are a good idea" crap is really starting to get on my nerves.
I'm also confused about something. bibliographicCitation is a refinement of dc:identifier, and therefore by the DC "dumb-down" rule is a type of identifier. The recommendation says, "dcterms:bibliographicCitation is an element refinement of dc:identifier, recognising that a bibliographic resource is effectively identified by its citation information." But then it goes on to say, "In Dublin Core Abstract Model terms the value of the dcterms:bibliographicCitation property is a value string, encoded according to a KEV ContextObject encoding scheme. It is not intended to be the resource identifier, which for a journal article would probably use an appropriate URI scheme such as DOI." So which is it? Is bibliographicCitation an identifier or not? Is the second quote using "identifier" to mean something different than dc:identifier without telling us? I'm willing to assume for now what I see as a contradiction here comes from my purely surface-level understanding of the DC Abstract model. But maybe not...
Monday, June 13, 2005
A gulf between research and practice
I've observed, as have others, that there is often a large gap between "digital library research" and "digital library practice" (by some definition of those terms). I got a good taste of this at the Joint Conference on Digital Libraries last week. At one session, an audience member asked the presenter if he had read this:
Nov. 2004, PhD dissertation, Marcos André Gonçalves, "Streams, Structures, Spaces, Scenarios, and Societies (5S): A Formal Digital Library Framework and Its Applications", http://scholar.lib.vt.edu/theses/available/etd-12052004-135923/
... as it related to the topic at hand. The presenter hadn't heard of it, and neither had I. But why hadn't I heard of it?!? This sort of work should absolutely be on any digital library practicioner's reading list, and any researcher in this area, be it computer science (as this one was) or LIS, should have some familiarity and ongoing discourse with practicioners. Both pure research and pure implementations of digital libraries are necessary, but that doesn't mean there is no middle ground, or that the two can't engage each other in a meaningful way. My work will be better for having read this research, and research will be better for having learned about what departments like mine produce.
I think one reason for this gulf is the differing definition of "library" held by different folks. But that's a post for another day.
Nov. 2004, PhD dissertation, Marcos André Gonçalves, "Streams, Structures, Spaces, Scenarios, and Societies (5S): A Formal Digital Library Framework and Its Applications", http://scholar.lib.vt.edu/theses/available/etd-12052004-135923/
... as it related to the topic at hand. The presenter hadn't heard of it, and neither had I. But why hadn't I heard of it?!? This sort of work should absolutely be on any digital library practicioner's reading list, and any researcher in this area, be it computer science (as this one was) or LIS, should have some familiarity and ongoing discourse with practicioners. Both pure research and pure implementations of digital libraries are necessary, but that doesn't mean there is no middle ground, or that the two can't engage each other in a meaningful way. My work will be better for having read this research, and research will be better for having learned about what departments like mine produce.
I think one reason for this gulf is the differing definition of "library" held by different folks. But that's a post for another day.
Wednesday, June 01, 2005
Beyond silly...
Ok. I'm not usually one to dismiss something out of hand as silly. I've definitely become in adulthood a "let's take a minute to look at all sides" kind of person. After that, I'll still tend to develop a strong opinion, but I like to believe I'm always willing to listen. That said, there are some things that I do have an immediate reaction to, consisting of me wanting to yell, "What in the world were you thinking?!?!" I had one of those moments stretched out over the last few days. Feel free to get me off my high horse and engage in real dialogue!
A post on Autocat last Friday asked about what to record in MARC 007 as the playing speed of a CD. The answer:
"Compact digital discs: Speed is measured in meters per second. This
is the distance covered on the disc's surface per second, and not the
number of revolutions.
f 1.4 m. per sec."
WHY, exactly, is this information important to be included in a MARC record? CDs and DVDs only play at one speed. I know that for analog discs (records, remember those?), one needs to know, for example, if it's a 45 or a 33 1/3, but not for the media currently under discussion! (And LP speeds are what they're *supposed* to be, not what they really should be to reproduce at pitch!) It strikes me very strongly as an anachronism, completely unnecessary in a bibliographic record for a CD created in 2005.
The conversation on Autocat then spun into a discussion of why it's not measured in revolutions per second, some technical details about how CD players work, etc. Interesting, certainly. But I'm a bit incredulous that the focus is on the method of measurement rather than the point of including that data in the first place! If and when CD players are historical artifacts, and all information on how they worked is lost, looking in MARC records and interpreting the very complex semantics of 007 is not going to be the revelation reconstructing the speed at which they should play. Even if we should be recording this information for posterity (value for dollar, anyone?), it doesn't have to be in every single bib record for a CD! We record this information at the expense of far more important data, such as analytics for individual musical works on the recording. Please, please, please! Let's step back and think about why we create these records in the first place. AACR3 (oops, RDA!) is trying to do this, but I fear it's not going nearly far enough.
Rant over. I do realize there are lots of practical problems we have with legacy data if we're going to make large-scale practice to cataloging changes. Let's work to solve those problems and not let them scare us off from doing anything. There are lots and lots of folks out there doing just this stepping back I'm pleading for. Good work, all of you! Let's do some more.
UPDATE! I get AUTOCAT in digest mode, and wrote the above based on messages received up to the morning of 6/1. In the digest I received 6/2, there are no less than TWO posters wondering what the heck this stuff is doing in a MARC record anyways. There's also continued endless discussion about linear velocity, how the CD measurements relate to tape media, how they relate to the "48x" speed advertised for CD-ROMs, etc. It's great that folks want to really understand these things, but I'd still argue that preferencing this sort of information over lots of other useful information isn't the right thing to do.
A post on Autocat last Friday asked about what to record in MARC 007 as the playing speed of a CD. The answer:
"Compact digital discs: Speed is measured in meters per second. This
is the distance covered on the disc's surface per second, and not the
number of revolutions.
f 1.4 m. per sec."
WHY, exactly, is this information important to be included in a MARC record? CDs and DVDs only play at one speed. I know that for analog discs (records, remember those?), one needs to know, for example, if it's a 45 or a 33 1/3, but not for the media currently under discussion! (And LP speeds are what they're *supposed* to be, not what they really should be to reproduce at pitch!) It strikes me very strongly as an anachronism, completely unnecessary in a bibliographic record for a CD created in 2005.
The conversation on Autocat then spun into a discussion of why it's not measured in revolutions per second, some technical details about how CD players work, etc. Interesting, certainly. But I'm a bit incredulous that the focus is on the method of measurement rather than the point of including that data in the first place! If and when CD players are historical artifacts, and all information on how they worked is lost, looking in MARC records and interpreting the very complex semantics of 007 is not going to be the revelation reconstructing the speed at which they should play. Even if we should be recording this information for posterity (value for dollar, anyone?), it doesn't have to be in every single bib record for a CD! We record this information at the expense of far more important data, such as analytics for individual musical works on the recording. Please, please, please! Let's step back and think about why we create these records in the first place. AACR3 (oops, RDA!) is trying to do this, but I fear it's not going nearly far enough.
Rant over. I do realize there are lots of practical problems we have with legacy data if we're going to make large-scale practice to cataloging changes. Let's work to solve those problems and not let them scare us off from doing anything. There are lots and lots of folks out there doing just this stepping back I'm pleading for. Good work, all of you! Let's do some more.
UPDATE! I get AUTOCAT in digest mode, and wrote the above based on messages received up to the morning of 6/1. In the digest I received 6/2, there are no less than TWO posters wondering what the heck this stuff is doing in a MARC record anyways. There's also continued endless discussion about linear velocity, how the CD measurements relate to tape media, how they relate to the "48x" speed advertised for CD-ROMs, etc. It's great that folks want to really understand these things, but I'd still argue that preferencing this sort of information over lots of other useful information isn't the right thing to do.
Subscribe to:
Posts (Atom)
Posts
