Well, today is the deadline for comments to NISO on the new Z39.19 revision, and unfortunately I haven't had a chance to dig in far enough to make any comments useful to them. Blast. I did, however, open the document up today to look for something specific. In the course of that search, I came across this text:
8.3.3.2 Parts of Multiple Wholes
When a whole-part relationship is not exclusive to a pair
wholes, the name of the whole and its part(s) should not
they should be linked associatively rather than hierarchically
Carburetors, for example, are parts of machines other
relationship in this instance is cars RT carburetors.
I'm disappointed in this decision. In order to preserve a pure hierarchy (something cannot be a part of multiple wholes), some semantics are lost. The idea that a carburetor is a part of a car (as well as potentially a part of lots of other stuff) is lost by relegating it to an RT (associative relationship). Whole-part relationships appear in the document as one of three types of hierarchical relationships; therefore, it seems that by categorizing them here the authors were forced to make the decision to move a huge number of things commonly thought of as having a whole-part relationship to an associative relationship. We librarians just love hierarchy, don't we. Too bad the world is polyhierarchical. Looks like our information systems won't be able to catch up yet.
Wednesday, May 25, 2005
Monday, May 23, 2005
"In Search of the Single Search Box"
Whew! It sure has been a while since I've posted. When starting this blog, finding the time to post on it was one of my major concerns. I'd been doing pretty well, but I recently hit a stretch where I was traveling more than home for about 6 weeks, and I moved in there as well! But I'm back now, and should be closer to home for a large portion of the summer. Here's to keeping up the blog while sitting on my new patio with a frosty beverage!
I heard an excellent presentation recently at the Digital Library Federation Spring Forum, which has been referenced recently on a library mailing list (WEB4LIB?). Staff at NC State have developed some methods for a single search box on the library's web site actually providing relevant information for all the many types of queries users type in that box no matter how much explanatory information indicating what resources that box searches is present on the page. The presentation was titled "In Search of the Single Search Box: Building a 'First Step' Library Search Tool." (Firefox users beware: the presentation is in HTML-ized Powerpoint and will look really strange in your browser!) Their video demo does an excellent job of illustrating the types of information needs to which the tool can respond. As the presentation suggests, this box doesn't search inside absolutely everything, but is intended to be a first step from which users can see some ideas and choose among them for continuing their journey.
As I recall (this is what I get for waiting this long to post on the topic...), the tool presents results in four major categories:
1) FAQ for the libraries
2) Library web pages
3) Links to perform the same search in some databases (the catalog, Academic Search Premier, list of journal titles, etc.)
4) Related subject categories
The FAQs meet needs where somebody wants to know the library hours or where the closest computer lab is. The library web pages results are Google-driven, so a page excerpt appears that a user might find helpful in selecting a result when they want some contextual information about a resource. The "search the collection" links make catalog or database search results an extra click away if that was the desired search, but that click is simply moved from the beginning of the process (click a catalog link on the home page, or, alternatively, take a few minutes to figure out which box on the front page to type in!) to this stage.
The "Browse Subjects" area, where a list of potentially relevant subjects is displayed, peaks my interest most about this project. The presentation didn't have a ton of information about where these links go and how the logic to develop them is created, and unfortunately I didn't have a chance to ask the NC State folks in person more about it. But from the presentation and the demo video, it looks like these links go to pathfinder-style pages where "selected" resources (selected how and by who would presumably be a local implementation decision) are displayed or linked. The presentation slides state that journal article titles and course descriptions are currently used to provide the connections between search terms and the pre-defined subjects. That's a great place to start! One can imagine a host of other options, including subject authority files, those same library web pages indexed elsewhere, and periodic looks at search logs for this box. Oh, and I see now one of the final slides in the presentation talks about some other sources - I'd forgotten that! I find the huge amount of potential here very exciting.
This tool isn't currently deployed on the NC State Libraries Web site, but I hope to see it soon. I don't recall if they plan to release any of their source code, but it sure would be nice if this was possible. I'll be keeping an eye on developments in this area.
Oh, and by the way. Never. Moving. Again. :-)
I heard an excellent presentation recently at the Digital Library Federation Spring Forum, which has been referenced recently on a library mailing list (WEB4LIB?). Staff at NC State have developed some methods for a single search box on the library's web site actually providing relevant information for all the many types of queries users type in that box no matter how much explanatory information indicating what resources that box searches is present on the page. The presentation was titled "In Search of the Single Search Box: Building a 'First Step' Library Search Tool." (Firefox users beware: the presentation is in HTML-ized Powerpoint and will look really strange in your browser!) Their video demo does an excellent job of illustrating the types of information needs to which the tool can respond. As the presentation suggests, this box doesn't search inside absolutely everything, but is intended to be a first step from which users can see some ideas and choose among them for continuing their journey.
As I recall (this is what I get for waiting this long to post on the topic...), the tool presents results in four major categories:
1) FAQ for the libraries
2) Library web pages
3) Links to perform the same search in some databases (the catalog, Academic Search Premier, list of journal titles, etc.)
4) Related subject categories
The FAQs meet needs where somebody wants to know the library hours or where the closest computer lab is. The library web pages results are Google-driven, so a page excerpt appears that a user might find helpful in selecting a result when they want some contextual information about a resource. The "search the collection" links make catalog or database search results an extra click away if that was the desired search, but that click is simply moved from the beginning of the process (click a catalog link on the home page, or, alternatively, take a few minutes to figure out which box on the front page to type in!) to this stage.
The "Browse Subjects" area, where a list of potentially relevant subjects is displayed, peaks my interest most about this project. The presentation didn't have a ton of information about where these links go and how the logic to develop them is created, and unfortunately I didn't have a chance to ask the NC State folks in person more about it. But from the presentation and the demo video, it looks like these links go to pathfinder-style pages where "selected" resources (selected how and by who would presumably be a local implementation decision) are displayed or linked. The presentation slides state that journal article titles and course descriptions are currently used to provide the connections between search terms and the pre-defined subjects. That's a great place to start! One can imagine a host of other options, including subject authority files, those same library web pages indexed elsewhere, and periodic looks at search logs for this box. Oh, and I see now one of the final slides in the presentation talks about some other sources - I'd forgotten that! I find the huge amount of potential here very exciting.
This tool isn't currently deployed on the NC State Libraries Web site, but I hope to see it soon. I don't recall if they plan to release any of their source code, but it sure would be nice if this was possible. I'll be keeping an eye on developments in this area.
Oh, and by the way. Never. Moving. Again. :-)
Saturday, May 07, 2005
Cataloging sound recordings
There has been a fascinating discussion on the Association for Recorded Sound Collections (ARSC) email list over the last week on cataloging sound recordings (look for threads starting with "database template" and "cataloging," then continuing here). The ARSC community is wonderfully diverse, including audiophiles, librarians, archivists, and others just interested in learning about sound recordings. The thread started out with an announcement of a database template for recording information about sound recordings; someone solving an immediate problem and wanting to share their solution with others. It's expanded greatly to become somewhat of a religious discussion on the relative merits and problems of MARC/AACR2 cataloging.
I can't help but feel that, like a great many discussions of this sort, the participants are talking past each other. One point that has been mentioned but perhaps not strongly enough, is that the user experience problems with library cataloging is heavily a problem of the use the search system makes of the data and how it's presented to end-users. Ralph Papakhian, one of the premier music catalogers in the country, who I like and respect a great deal, has made the point in this thread that the data elements some respondents mention as wanting to record are in fact recordable in MARC. And if anyone would know and can explain this to others, it's Ralph. But these elements, even though they're there, are often not accessible to users. For example, MARC has fields for date of composition and coded instrumentation of a recording or score. But few if any library systems index or display this data. So catalogers rarely enter them, which provides less incentive for systems to use them, which provides less incentive for catalogers to use them, which provides less incentive for systems to use them...
But I believe systems aren't the only problem. There are lots of little things I think MARC/AACR2 could do better. However, the biggest, and mostly implicit in this discussion, difference in what MARC does and what some of the other participants in this thread look for in sound recording cataloging, is the library focus on the carrier over the content. Catalogers discuss this issue frequently, but it hasn't been brought up explicitly in this thread. Audiophiles absolutely are interested in the recording as a whole--its matrix number, sound engineers, etc. But they are also equally interested in the musical works on the recording, what personnel are connected with which piece, timings of tracks, etc. MARC has places for these things, but they are relegated to second-class status. Catalogers know and tout the benefits of structure and authority control in information retrieval. But when it comes to the contents of a bibliographic item, we apply none of these principles in the MARC environment. Contents notes are largely unstructured (and what structure is possible is rarely used and keeps changing!), don't make use of name or title authority control, and in many cases aren't indexed in library systems.
As pointed out in this thread, creating this content-level information is extremely expensive. But the networked world has the potential to change that. Much of this information has been created in structured form outside of the library environment, by record companies, retailers, and enthusiasts, but we don't make use of it. Right now, it's difficult to make use of it because our systems don't know how to talk to each other. It will take a great many baby steps, but I hope we can start down the road towards changing that.
Matt Snyder of NYPL, who I met at MLA this year and was extrememly impressed with, has made the point in this thread that MARC records (and, by extension, library catalogs) and discographies have different purposes. This is definitely true in today's environment. Library catalogs are primarily for locating things, and discographies have more of a research bent. But I feel strongly, and this email discussion seems to support this view, that the distinction is largely artificial and is becoming less relevant as information retrieval systems continue to evolve. More sharing of data between systems will hopefully result in fewer systems to consult by end-users. That's certainly my goal!
I can't help but feel that, like a great many discussions of this sort, the participants are talking past each other. One point that has been mentioned but perhaps not strongly enough, is that the user experience problems with library cataloging is heavily a problem of the use the search system makes of the data and how it's presented to end-users. Ralph Papakhian, one of the premier music catalogers in the country, who I like and respect a great deal, has made the point in this thread that the data elements some respondents mention as wanting to record are in fact recordable in MARC. And if anyone would know and can explain this to others, it's Ralph. But these elements, even though they're there, are often not accessible to users. For example, MARC has fields for date of composition and coded instrumentation of a recording or score. But few if any library systems index or display this data. So catalogers rarely enter them, which provides less incentive for systems to use them, which provides less incentive for catalogers to use them, which provides less incentive for systems to use them...
But I believe systems aren't the only problem. There are lots of little things I think MARC/AACR2 could do better. However, the biggest, and mostly implicit in this discussion, difference in what MARC does and what some of the other participants in this thread look for in sound recording cataloging, is the library focus on the carrier over the content. Catalogers discuss this issue frequently, but it hasn't been brought up explicitly in this thread. Audiophiles absolutely are interested in the recording as a whole--its matrix number, sound engineers, etc. But they are also equally interested in the musical works on the recording, what personnel are connected with which piece, timings of tracks, etc. MARC has places for these things, but they are relegated to second-class status. Catalogers know and tout the benefits of structure and authority control in information retrieval. But when it comes to the contents of a bibliographic item, we apply none of these principles in the MARC environment. Contents notes are largely unstructured (and what structure is possible is rarely used and keeps changing!), don't make use of name or title authority control, and in many cases aren't indexed in library systems.
As pointed out in this thread, creating this content-level information is extremely expensive. But the networked world has the potential to change that. Much of this information has been created in structured form outside of the library environment, by record companies, retailers, and enthusiasts, but we don't make use of it. Right now, it's difficult to make use of it because our systems don't know how to talk to each other. It will take a great many baby steps, but I hope we can start down the road towards changing that.
Matt Snyder of NYPL, who I met at MLA this year and was extrememly impressed with, has made the point in this thread that MARC records (and, by extension, library catalogs) and discographies have different purposes. This is definitely true in today's environment. Library catalogs are primarily for locating things, and discographies have more of a research bent. But I feel strongly, and this email discussion seems to support this view, that the distinction is largely artificial and is becoming less relevant as information retrieval systems continue to evolve. More sharing of data between systems will hopefully result in fewer systems to consult by end-users. That's certainly my goal!
Thursday, May 05, 2005
Known-item vs. unknown-item searching
A series of project assignments and offhand conversations recently have me thinking about how well (or how poorly) our current library-ish systems support users diving in and simply exploring what the system has to offer. On the whole, most of our discovery systems focus on known-item searching, where a user comes to the system with something specific in mind that they want to find: books by a certain author, a movie with a specific title, recordings by a particular artist. These information needs are of course common, and they are in fact the focus of Cutter's first objective of the catalog.
But look more closely at c) in that first objective - we should provide access to an item when the subject of it is known. So what exactly does that mean? Most current systems in a library environment fulfil that by making text in a subject-ish field keyword searchable. When I do a subject search in a system of that sort, I get back records that have subjects containing the word I typed in. But how do users know what the words in those subjects are? Some (certainly not all!) systems provide the user a way to look at a list of subjects used in that system. The user then is expected to locate all subjects of interest in that list, then construct a properly-formulated Boolean query OR-ing those subjects together. I'll be perfectly frank and state that I believe strongly that this is silly to expect of any user in this day and age, even an "expert" user such as a reference librarian. Let's use the computing power we have!
And what about these of Cutter's objectives?
2. To show what the library has
What we need are systems that do an exponentially better job of starting out from an interesting thing and finding more things like it. I personally think postcoordinated subject headings would be a major advance in this area, but they're certainly not enough. Systems that map lead-in terms to authorized terms, and expand search results to include narrower terms than a matched broader term are also necessary. One can also imagine other mechanisms to build that "like" relationship, based on information retrieval research, folksonomies, and transaction logs.
I suppose my point in the end is that it's simple to build a system that searches the text of pre-created metadata fields for an entered query string. It's much more difficult to build systems that allow users to truly explore. We often forget how important that exploration function is. We look at our search logs, and see mostly known-item searches, so we think that's what we need to focus on. Of course we see that - it's what our systems are designed around! But what would happen if we started to provide relevant results to subject and other unknown-item searches? I'd bet a whole lot of money that we'd see a huge increase in unknown-item searching. Sure, for some types of materials, known-item searching may very well be the primary means of access users need. But let's at least look at the alternative, and work with actual users to see how we can provide them with exploratory functions we don't currently supply.
But look more closely at c) in that first objective - we should provide access to an item when the subject of it is known. So what exactly does that mean? Most current systems in a library environment fulfil that by making text in a subject-ish field keyword searchable. When I do a subject search in a system of that sort, I get back records that have subjects containing the word I typed in. But how do users know what the words in those subjects are? Some (certainly not all!) systems provide the user a way to look at a list of subjects used in that system. The user then is expected to locate all subjects of interest in that list, then construct a properly-formulated Boolean query OR-ing those subjects together. I'll be perfectly frank and state that I believe strongly that this is silly to expect of any user in this day and age, even an "expert" user such as a reference librarian. Let's use the computing power we have!
And what about these of Cutter's objectives?
2. To show what the library has
- e. On a given and related subjects
- f. In a given kind of literature
What we need are systems that do an exponentially better job of starting out from an interesting thing and finding more things like it. I personally think postcoordinated subject headings would be a major advance in this area, but they're certainly not enough. Systems that map lead-in terms to authorized terms, and expand search results to include narrower terms than a matched broader term are also necessary. One can also imagine other mechanisms to build that "like" relationship, based on information retrieval research, folksonomies, and transaction logs.
I suppose my point in the end is that it's simple to build a system that searches the text of pre-created metadata fields for an entered query string. It's much more difficult to build systems that allow users to truly explore. We often forget how important that exploration function is. We look at our search logs, and see mostly known-item searches, so we think that's what we need to focus on. Of course we see that - it's what our systems are designed around! But what would happen if we started to provide relevant results to subject and other unknown-item searches? I'd bet a whole lot of money that we'd see a huge increase in unknown-item searching. Sure, for some types of materials, known-item searching may very well be the primary means of access users need. But let's at least look at the alternative, and work with actual users to see how we can provide them with exploratory functions we don't currently supply.
Tuesday, May 03, 2005
FRBR Workshop
Wow! Wow, wow, wow, and WOW. I'm at the end of day 2 of a 2.5 day FRBR Workshop at OCLC, and I've been continuously blown away by the activity going on here. The workshop is supposed to be in large part a working session to start thinking about what revisions to the original FRBR report would look like. I was skeptical of that goal coming in, seeing as 75 people are here, but I've been extremely pleasantly surprised. If I've even been in a room with as many bright, engaged, and interesting people before, I didn't appreciate it at the time. Within the discussion, I find just the right balance of theory and practice, of idealism and realism. There's a very clear vision of what a bibliographic future could be, and a great many ideas for ways we can reach there in manageable steps.
The workshop itself is a mixture of presentations on specific topics and time to just talk. Some presentations don't at first glance look to be FRBR related, but every single one really does have a definite impact on how FRBR should develop in the future, either as a conceptual model or as some sort of implementation model based on the conceptual one. Some presentation slides are on the workshop site now, and hopefully all will eventually be. But the presentation slides in no way do the actual presentations and the resulting large- and small-group discussions justice. I feel more confident than at most meetings of this type that the discussions will have real results, in the form of writings and implementations. I sincerely hope so - many people out there are interested in this topic, and the best thing we can do now is share, share, and share some more.
The workshop itself is a mixture of presentations on specific topics and time to just talk. Some presentations don't at first glance look to be FRBR related, but every single one really does have a definite impact on how FRBR should develop in the future, either as a conceptual model or as some sort of implementation model based on the conceptual one. Some presentation slides are on the workshop site now, and hopefully all will eventually be. But the presentation slides in no way do the actual presentations and the resulting large- and small-group discussions justice. I feel more confident than at most meetings of this type that the discussions will have real results, in the form of writings and implementations. I sincerely hope so - many people out there are interested in this topic, and the best thing we can do now is share, share, and share some more.
Thursday, April 28, 2005
Newsweek article on "tagging"
In the April 18, 2005, issue of Newsweek, "The Technologist" column is about "tagging," sites like Flickr and del.icio.us, that collect users labels for things. These "things" can be absolutely anything - the great thing about the Internet is that communities can appear almost instantaneously around anything at all. These labels can then be used to generate a folksonomy. There's a lot of buzz out there about folksonomies right now on the Web, and it's well-deserved. It's cool stuff. It provides such a great sense of how REAL PEOPLE (who?) think about things.
I'm enough of a skeptic to think it's not practical for libraries to switch wholesale to folksonomy-type endeavors for subject access, but surely there are ways in which we can capitalize on the wealth of relevant information being generated out there. I've been interested for some time in incorporating user-contributed to a project I work on. My plugs for this to date have used Wikis as examples - I think I'm going to have to add folksonomies to my spiel!
I'm enough of a skeptic to think it's not practical for libraries to switch wholesale to folksonomy-type endeavors for subject access, but surely there are ways in which we can capitalize on the wealth of relevant information being generated out there. I've been interested for some time in incorporating user-contributed to a project I work on. My plugs for this to date have used Wikis as examples - I think I'm going to have to add folksonomies to my spiel!
Tuesday, April 26, 2005
AMeGA Automatic Metadata Generation final report
I've just finished reading (reading, what's that? haven't done it in a while...) the final report from the AMeGA (Automatic Metadata Generation Applications) Project. I filled out the survey on which part of this report was based, and I have to admit, I wasn't optimistic about the project. The survey referenced that it was meant for text objects primarily, but as someone who works heavily in non-text environments, I found this disappointing. But now that it's out, overall I think the report has done a good job outlining the issues involved.
Of particular interest to me is Section 8, where proposed functionalities are listed for metadata generation applications. There are a number of very good suggestions here, often focusing on streamlining the metadata generation proceess - making use of automation when current technologies perform well, and making the human-generated part of the process easier. I definitely agree with the report that there is a huge disconnect today between research in this area and production systems. There is very interesting research in this area going on, but production systems don't yet make good use of it. Right now, we still need humans in the process. I'm not opposed on principle to changing this, but that's today's reality.
The report characterizes survey respondents as "optimists' and "skeptics," based on their projections of future abilities to automate metadata creation. The report quotes several skeptics as proclaiming it simply not, under any circumstances, to completely automate metadata creation. I'd like to think of myself on the fence with regard to this issue. I don't like to say "never" but I do see that generation of certain types of metadata elements will be easier to automate than others. The more we can automate, great. I also understand the problem with evaluating automatic metadata generation applications. Few people agree on approprate subject headings, etc., so how do we know if a generated heading is appropriate? In my opinion, the more we can expose people to the results of generated metadata, the better we can evaluate it, and the better these systems will eventually get.
Of particular interest to me is Section 8, where proposed functionalities are listed for metadata generation applications. There are a number of very good suggestions here, often focusing on streamlining the metadata generation proceess - making use of automation when current technologies perform well, and making the human-generated part of the process easier. I definitely agree with the report that there is a huge disconnect today between research in this area and production systems. There is very interesting research in this area going on, but production systems don't yet make good use of it. Right now, we still need humans in the process. I'm not opposed on principle to changing this, but that's today's reality.
The report characterizes survey respondents as "optimists' and "skeptics," based on their projections of future abilities to automate metadata creation. The report quotes several skeptics as proclaiming it simply not, under any circumstances, to completely automate metadata creation. I'd like to think of myself on the fence with regard to this issue. I don't like to say "never" but I do see that generation of certain types of metadata elements will be easier to automate than others. The more we can automate, great. I also understand the problem with evaluating automatic metadata generation applications. Few people agree on approprate subject headings, etc., so how do we know if a generated heading is appropriate? In my opinion, the more we can expose people to the results of generated metadata, the better we can evaluate it, and the better these systems will eventually get.
Wednesday, April 20, 2005
ANSI/NISO Z39.19 draft revision
Whew! I'm finally back from 3 trips in 3 weeks, and have slogged through enough email to think about the blog again. I had lots of interesting developments waiting for me when I returned - new blog fodder!
ANSI/NISO has released a draft revision of Z39.19, now titled "Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies." I haven't had a chance to read the document yet, but it sure looks interesting! From the table of contents, I'm glad to see a small section on synonym rings, as we encountered these not working the way we expected in an implementation of OracleText. At first glance, the scope of the standard seems to have expanded. There are sub-sections of the "principles" section on ambiguity and facet analysis that I don't recall being in the existing standard (but don't quote me on that!). I'm extremely interested in the section on displaying controlled vocabularies. In my opinion this is the biggest barrier to end users of systems using controlled vocabularies today - displays that completely separate the vocabulary from the search interface, requiring users to know of their existence, understand their structure, and take the time to consult them! I look forward to seeing if this draft standard can make them more understandable.
ANSI/NISO has released a draft revision of Z39.19, now titled "Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies." I haven't had a chance to read the document yet, but it sure looks interesting! From the table of contents, I'm glad to see a small section on synonym rings, as we encountered these not working the way we expected in an implementation of OracleText. At first glance, the scope of the standard seems to have expanded. There are sub-sections of the "principles" section on ambiguity and facet analysis that I don't recall being in the existing standard (but don't quote me on that!). I'm extremely interested in the section on displaying controlled vocabularies. In my opinion this is the biggest barrier to end users of systems using controlled vocabularies today - displays that completely separate the vocabulary from the search interface, requiring users to know of their existence, understand their structure, and take the time to consult them! I look forward to seeing if this draft standard can make them more understandable.
Sunday, April 10, 2005
"Authority control in AACR3"
I recently read a paper by Kierdre Kiorgaard and Ann Huthwaite that I heard about on Catalogablog, entitled "Authority control in AACR3." The paper describes the efforts underway to address the issue of authority control explicitly in AACR3, in a manner more explicit than in AACR2. The statement in this paper I find most interesting is this:
"The definition that is likely to be included in AACR3 is: 'the means by which entries for a specific entity are collocated under a single, unique authorized form of a heading; access is provided to that authorized form from variant forms; and relationships between entities are expressed.'"
Authority control for names certainly fulfils the collocating function described here, and, conversely, a disambiguation function by creating different headings for different people with similar or identical names. But in today's information systems it can and should fulfil another function - helping users to decide if the name heading displayed to them is for the individual they're interested in. But I believe only the first goal is served by a system where the uniqueness of a person is represented only by the form of the heading. Name authority files also don't completely disambiguate names; there are many cases of duplicate names in the authority file when no information other than what appears on a publication is available to the cataloger.
I can't help but wonder if we're missing an opportunity here to move to a structure that can more easily fulfil both goals. Information that would help a user decide if a person is the one they're interested in is frequently added to a name heading, but not always. If all of that information, plus any more that may be of use, is made available to the user in a flexible manner, rather than just the data necessary to disambiguate one name from another, the second goal would be much more easily served. Perhaps this is not the time for this sort of change to be made. I do think we as librarians and system designers should be open to changes of this sort, continuing to focus primarily on the task we want to accomplish, and leaving the mechanics of accomplishing that goal as a later step.
"The definition that is likely to be included in AACR3 is: 'the means by which entries for a specific entity are collocated under a single, unique authorized form of a heading; access is provided to that authorized form from variant forms; and relationships between entities are expressed.'"
Authority control for names certainly fulfils the collocating function described here, and, conversely, a disambiguation function by creating different headings for different people with similar or identical names. But in today's information systems it can and should fulfil another function - helping users to decide if the name heading displayed to them is for the individual they're interested in. But I believe only the first goal is served by a system where the uniqueness of a person is represented only by the form of the heading. Name authority files also don't completely disambiguate names; there are many cases of duplicate names in the authority file when no information other than what appears on a publication is available to the cataloger.
I can't help but wonder if we're missing an opportunity here to move to a structure that can more easily fulfil both goals. Information that would help a user decide if a person is the one they're interested in is frequently added to a name heading, but not always. If all of that information, plus any more that may be of use, is made available to the user in a flexible manner, rather than just the data necessary to disambiguate one name from another, the second goal would be much more easily served. Perhaps this is not the time for this sort of change to be made. I do think we as librarians and system designers should be open to changes of this sort, continuing to focus primarily on the task we want to accomplish, and leaving the mechanics of accomplishing that goal as a later step.
Saturday, April 09, 2005
Friday, April 01, 2005
April Fools!
Be sure to check out the April 1 edition of Library Journal. I hope this gets archived somewhere. What a hoot!
Sunday, March 27, 2005
Random thoughts on XOBIS
Kevin Clarke, one of the authors of XOBIS, kindly left a comment on my recent blog post on the topic. It shamed me into returning to the XOBIS general overview document I peeked at briefly when originally writing about it. I've now given the entire document a quick read. I can't claim to have an in-depth understanding of it at this point; it certainly took me several readings of the FRBR report and a decent amount of time thinking about modeling different things in FRBR before I felt I could really say anything intelligent about it. Nevertheless, I have a few initial impressions on XOBIS.
The most obvious difference I see between XOBIS and FRBR is that XOBIS attempts to be a model that can describe all of knowledge, while FRBR limits itself to modelling bibliographic relationships. In a practical sense, for recording bibliographic data (and this certainly isn't the only possible use of XOBIS!) this means that XOBIS explicitly handles entities that represent in a bibliographic environment creators or subjects of bibliographic items (and, in FRBR, other Group 1 entities), currently residing in a relatively unstructured way in name and subject authority files. FRBR, on the other hand considers only briefly its Group 2 ("person" and "corporate body") and Group 3 ("concept," "object," "event," and "place") entities, focusing instead on Group 1 entities.
Relationships between entities is a key feature of XOBIS; they are also a bit confusing to me on my first read. My initial impression is that the relationships as specified focus more on subject-type relationships rather than relationships among bibliographic items. My reading is that the XOBIS definition of work is much closer to what we currently consider a bibliographic item than FRBR's work. The discussion and examples in the overview document talk about versions of works and how they are related, but I saw much less about the "accidental" sort of relationship a FRBR-ish work (as its expressed in a specific manifestation) would have to another expressed work on the same manifestation, for example, two symphonies appearing on the same CD. It would be an interesting excercise to map out how the XOBIS model would handle this sort of situation, where the symphony itself is the entity of primary interest to a majority of end-users rather than the specific performance or the title of the CD on which it appears.
XOBIS comes out of the Medlane project of the Lane Medical Library at Stanford. I wonder what effect medical materials have had on the development of the XOBIS model. I know my focus on musical materials in various projects, most notably Variations2, certainly strongly affects my thinking about FRBR and related efforts. I'm sure that's obvious from my earlier question wondering how XOBIS would handle a situation that the Variations2 model is designed around.
There are also some very interesting items in the report's bibliography, including a project mailing list (renamed since the version listed here, and looks low-traffic). Time for citation chasing!
The most obvious difference I see between XOBIS and FRBR is that XOBIS attempts to be a model that can describe all of knowledge, while FRBR limits itself to modelling bibliographic relationships. In a practical sense, for recording bibliographic data (and this certainly isn't the only possible use of XOBIS!) this means that XOBIS explicitly handles entities that represent in a bibliographic environment creators or subjects of bibliographic items (and, in FRBR, other Group 1 entities), currently residing in a relatively unstructured way in name and subject authority files. FRBR, on the other hand considers only briefly its Group 2 ("person" and "corporate body") and Group 3 ("concept," "object," "event," and "place") entities, focusing instead on Group 1 entities.
Relationships between entities is a key feature of XOBIS; they are also a bit confusing to me on my first read. My initial impression is that the relationships as specified focus more on subject-type relationships rather than relationships among bibliographic items. My reading is that the XOBIS definition of work is much closer to what we currently consider a bibliographic item than FRBR's work. The discussion and examples in the overview document talk about versions of works and how they are related, but I saw much less about the "accidental" sort of relationship a FRBR-ish work (as its expressed in a specific manifestation) would have to another expressed work on the same manifestation, for example, two symphonies appearing on the same CD. It would be an interesting excercise to map out how the XOBIS model would handle this sort of situation, where the symphony itself is the entity of primary interest to a majority of end-users rather than the specific performance or the title of the CD on which it appears.
XOBIS comes out of the Medlane project of the Lane Medical Library at Stanford. I wonder what effect medical materials have had on the development of the XOBIS model. I know my focus on musical materials in various projects, most notably Variations2, certainly strongly affects my thinking about FRBR and related efforts. I'm sure that's obvious from my earlier question wondering how XOBIS would handle a situation that the Variations2 model is designed around.
There are also some very interesting items in the report's bibliography, including a project mailing list (renamed since the version listed here, and looks low-traffic). Time for citation chasing!
Wednesday, March 23, 2005
Postcoordinated subject headings
There has been an interesting discussion on the Autocat mailing list over the last two weeks (well it's died down now, but I haven't gotten around to writing about it yet...) with the subject "The inadequacies of subject headings." The discussion has centered on a few posters questioning whether the LCSH-style focus on precoordinated headings is really a good idea. Several posters proposed (not all by name) postcoordinated headings as more useful, both for end-users and for catalogers. More than one person mentioned the large amount of training required for catalogers to effectively apply headings from a precoordinated system.
I was struck in the discussion by the widespread lack of big-picture thinking about the issue, and the corresponding lack of awareness of the many initiatives going on in this area. There were certainly some members contributing to the discussion who have spent some time thinking about this issue, but many seemed afraid of the idea. I got the sense that many folks were trained on LCSH, that's what they use, and why in the world would they want to use anything else? When posts mentioned specific postcoordinated schemes (FAST, AAT, etc.) they tended to be mentioned as something the person had heard of but never used and didn't fully understand. I'm generalizing a bit here, but that tone was definitely present.
I don't know that I have anything concrete to say other than that I've noticed a trend of resistance to non-LCSH subject systems, but I do think that as catalogers are increasingly being asked to be metadata experts (and by that I mean metadata in a broad sense, not just traditional cataloging practice!) they'll more and more need to know about what vocabularies are out there. A huge part of my job as a Metadata Librarian is choosing among the various data structure and data content standards available for a given implementation. We're definitely past the days when one size (MARC/AACR/LCSH) fits all. The more all sorts of librarians learn about alternatives and can make good decisions about when they're appropriate to use, the better off our whole profession will be.
I was struck in the discussion by the widespread lack of big-picture thinking about the issue, and the corresponding lack of awareness of the many initiatives going on in this area. There were certainly some members contributing to the discussion who have spent some time thinking about this issue, but many seemed afraid of the idea. I got the sense that many folks were trained on LCSH, that's what they use, and why in the world would they want to use anything else? When posts mentioned specific postcoordinated schemes (FAST, AAT, etc.) they tended to be mentioned as something the person had heard of but never used and didn't fully understand. I'm generalizing a bit here, but that tone was definitely present.
I don't know that I have anything concrete to say other than that I've noticed a trend of resistance to non-LCSH subject systems, but I do think that as catalogers are increasingly being asked to be metadata experts (and by that I mean metadata in a broad sense, not just traditional cataloging practice!) they'll more and more need to know about what vocabularies are out there. A huge part of my job as a Metadata Librarian is choosing among the various data structure and data content standards available for a given implementation. We're definitely past the days when one size (MARC/AACR/LCSH) fits all. The more all sorts of librarians learn about alternatives and can make good decisions about when they're appropriate to use, the better off our whole profession will be.
Sunday, March 20, 2005
"We're not competing with Google"
I was in a meeting recently that had as an agenda item Google Print and its effect on our current library services. (I seem to be having this meeting a lot lately.) I was by far the youngest in the room and by far the attendee working most frequently in areas outside of "traditional" librianship (whatever that means). I intentionally spent most of the meeting listening rather than talking. One statement in particular made by someone in the room struck me and started me thinking a great deal: "We're not competing with Google."
I didn't respond to it at the time, but the statement has been churning around in my head ever since. Whether or not it's true depends, of course, on what one means by "competing." If we mean, "attempting to do exactly the same thing," then that's pretty much true. While we're both in the information business, the way in which we approach it is fundamentally different. And that's OK. But if we mean "fighting for the attention of users" or "fighting for the perception that we provide valuable services worth funding," then maybe we are competing with Google. The differences between libraries' missions and the way in which we go about achieving them is important to us, but perhaps it's too subtle for a large proportion of the population. Certainly there are lots of folks out there that think Google can and will replace libraries, even if we think they're wrong.
So what does this mean? Well, I think it means that libraries need to continue to promote what we do and why. Not in the preachy Michael Gorman style proclaiming from on high to the masses that libraries are the cornerstone of high civilization and those who disagree aren't worth thinking about, but rather by building and delivering services that meet our users' needs. In the rapidly changing information environment, this means we do need to be rethinking how we do a lot of what we do. Let's remember our core principles of preservation, collocation, and free access, and find new ways to implement these in today's environment and for today's diverse users.
I didn't respond to it at the time, but the statement has been churning around in my head ever since. Whether or not it's true depends, of course, on what one means by "competing." If we mean, "attempting to do exactly the same thing," then that's pretty much true. While we're both in the information business, the way in which we approach it is fundamentally different. And that's OK. But if we mean "fighting for the attention of users" or "fighting for the perception that we provide valuable services worth funding," then maybe we are competing with Google. The differences between libraries' missions and the way in which we go about achieving them is important to us, but perhaps it's too subtle for a large proportion of the population. Certainly there are lots of folks out there that think Google can and will replace libraries, even if we think they're wrong.
So what does this mean? Well, I think it means that libraries need to continue to promote what we do and why. Not in the preachy Michael Gorman style proclaiming from on high to the masses that libraries are the cornerstone of high civilization and those who disagree aren't worth thinking about, but rather by building and delivering services that meet our users' needs. In the rapidly changing information environment, this means we do need to be rethinking how we do a lot of what we do. Let's remember our core principles of preservation, collocation, and free access, and find new ways to implement these in today's environment and for today's diverse users.
Wednesday, March 16, 2005
A DC frustration
I had another one of those <sigh> moments about Dublin Core today. I've got some really amazingly simple bibliographic data I need to put in a within a METS document. At first I said, "Hey, let's just use DC. It will be easy." (Note to self: anytime you say "It will be easy," you're asking for trouble.) Everything was going along swimmingly until I was thinking about boilerplate text to put in all the records. One of these pieces of text would be to indicate the department at my institution that housed the materials in question. Ding, ding, ding! Alarm bells! There's no good place for this in simple Dublin Core! (Or qualified Dublin Core for that matter.)
I've dealt with this exact situation before, I guess I was blocking it out because it's SO annoying. Some folks would put this information in <dc:contributor>, and in fact several of my OAI sets do just this in their DC records. I suppose that might be OK, but the DC Contributor definition is "An entity responsible for making contributions to the content of the resource" and I don't know if I'm so comfortable calling "paying somebody to digitize this stuff and then asking another department to 'put it up on the Web'" "making contributions to the content of the resource." Some folks would put this information in <dc:publisher>, but again I'm skeptical. "An entity responsible for making the resource available" (DC Publisher definition) does apply to the digital resource. However, we're dealing with published materials here whose publisher for the print item can be an important access point. And we don't (nor does pretty much anybody) have a sophisticated mechanism in place for making good 1:1 principle records and linking them all together in a way that allows users to search on things meaningful to them and get meaningful results back. Putting our holding institution in Publisher in this environment would not serve our users' needs.
I started out using a hack I'd used before: put the holding info at the beginning of a <dc:source> field and add to the end the local call number so it fits the Source definition. But then I got annoyed at using what I consider a hack. So I started digging around. The Western States Dublin Core Metadata Best Practices made up their own element (currently called "Contributing Institution") and don't map it to DC. This is one of the very few elements they go completely out of DC for. The DC Libraries Working Group made a proposal in 2002 for a new DC element called holdingLocation, but by the time this proposal was reviewed by the Usage Board, MODS had gotten off the ground, so, the UB decision said to use the MODS <location> element instead.
So the DC solution to this problem is to use an Application Profile that borrows an element from another schema. But once you start doing this, the draw of DC (simplicity!) is lost. I'm probably just going to use MODS instead. Sigh.
I've dealt with this exact situation before, I guess I was blocking it out because it's SO annoying. Some folks would put this information in <dc:contributor>, and in fact several of my OAI sets do just this in their DC records. I suppose that might be OK, but the DC Contributor definition is "An entity responsible for making contributions to the content of the resource" and I don't know if I'm so comfortable calling "paying somebody to digitize this stuff and then asking another department to 'put it up on the Web'" "making contributions to the content of the resource." Some folks would put this information in <dc:publisher>, but again I'm skeptical. "An entity responsible for making the resource available" (DC Publisher definition) does apply to the digital resource. However, we're dealing with published materials here whose publisher for the print item can be an important access point. And we don't (nor does pretty much anybody) have a sophisticated mechanism in place for making good 1:1 principle records and linking them all together in a way that allows users to search on things meaningful to them and get meaningful results back. Putting our holding institution in Publisher in this environment would not serve our users' needs.
I started out using a hack I'd used before: put the holding info at the beginning of a <dc:source> field and add to the end the local call number so it fits the Source definition. But then I got annoyed at using what I consider a hack. So I started digging around. The Western States Dublin Core Metadata Best Practices made up their own element (currently called "Contributing Institution") and don't map it to DC. This is one of the very few elements they go completely out of DC for. The DC Libraries Working Group made a proposal in 2002 for a new DC element called holdingLocation, but by the time this proposal was reviewed by the Usage Board, MODS had gotten off the ground, so, the UB decision said to use the MODS <location> element instead.
So the DC solution to this problem is to use an Application Profile that borrows an element from another schema. But once you start doing this, the draw of DC (simplicity!) is lost. I'm probably just going to use MODS instead. Sigh.
Monday, March 14, 2005
Defining "librarian"
I've seen a few articles and discussions recently converging around the idea of defining what a "librarian" actually is. The March 2005 issue of American Libraries has a cover story about paraprofessionals working in libraries and the perceptions of them by patrons and "librarians" at their place of work, there has been an ongoing thread with the subject "End of Librarianship" over the Autocat mailing list weeks 1 and 2 of March 2005 (browse the archives), and a posting today at lisnews.com reporting a library director job indicating an MLS was optional for applicants. These all touch in some way on whether an MLS, a job title including the word "librarian," or a job in a library makes one a "librarian."
Certainly the definition of "librarian" is contextual. The American Libraries article asks some library paraprofessionals what their answer is to the question "Are you the librarian?" Since a patron asking that question almost certainly means "Can you help me?" rather than "Do you have an MLS?" or "Does your job title say you're a librarian?" so the answer there in my opinion should be an emphatic YES.
But many librarians are extremely protective of this label. It represents a significant investment of time, money, and intellect into earning a professional degree. And that's certainly nothing to sneeze at. (Even if some MLS programs in this country today can't reasonably be described as "rigorous.") However, I certainly know a number of people in jobs with titles including "librarian" who were hired under the rationale "MLS or equivalent experience" who do excellent jobs. Shouldn't one's ability to perform the duties of a position be the primary criterion for hiring them? I tend to think that a piece of paper bearing the designation MLS doesn't necessarily tell an employer whether or not an applicant is qualified.
I guess the argument comes down to whether the term librarian should refer to "what you do" or "who you are." And I can see how each would be appropriate in different circumstances. I tend to believe one should demonstrate his or her skill and professionalism in their interactions with people and in their work performance, rather than assuming an acronym and a diploma are an accurate indication.
Certainly the definition of "librarian" is contextual. The American Libraries article asks some library paraprofessionals what their answer is to the question "Are you the librarian?" Since a patron asking that question almost certainly means "Can you help me?" rather than "Do you have an MLS?" or "Does your job title say you're a librarian?" so the answer there in my opinion should be an emphatic YES.
But many librarians are extremely protective of this label. It represents a significant investment of time, money, and intellect into earning a professional degree. And that's certainly nothing to sneeze at. (Even if some MLS programs in this country today can't reasonably be described as "rigorous.") However, I certainly know a number of people in jobs with titles including "librarian" who were hired under the rationale "MLS or equivalent experience" who do excellent jobs. Shouldn't one's ability to perform the duties of a position be the primary criterion for hiring them? I tend to think that a piece of paper bearing the designation MLS doesn't necessarily tell an employer whether or not an applicant is qualified.
I guess the argument comes down to whether the term librarian should refer to "what you do" or "who you are." And I can see how each would be appropriate in different circumstances. I tend to believe one should demonstrate his or her skill and professionalism in their interactions with people and in their work performance, rather than assuming an acronym and a diploma are an accurate indication.
Saturday, March 12, 2005
"Google at the Gate"
In the March 2005 issue of American Libraries, there is an article entitled "Google at the Gate" containing questions about the recently-announced Google digitization project, with answers from Michael Gorman of Cal State-Fresno and ALA president-elect, Deanna Marcum of LC, Susan McGlamery of OCLC, and Ann Wolpert of MIT. The article appears at an interesting time, just as the buzz is dying down from what some have called "Gormangate" - a huge reaction, especially among the blog community, to comments Michael Gorman made recently lampooning the value of bloggers.
In this article, Gorman continues the dismissive style of rhetoric that have incensed so many in his previous comments on the Google projcet and on blogging. The tone is very much one of a person who is certain he is right and need not consider any other arguments put to him. Two quotes in particular caught my eye:
"Any user of Google knows it is pathetic as an information retrieval system..."
This quote, of course, depends heavily on the definition of "information retrieval system." The remainder of the sentence references the traditional IR research metrics of recall and precision, so it's probably reasonable to assume that Gorman is measuring the effectiveness of Google along those lines. And that's one fair way to measure. However, your random Google user is probably unlikely to measure Google according to those terms. Most information needs are for something on a topic rather than everything on a topic. We in libraries are used to (and should be!) focusing on the latter. But that doesn't mean it's the only way to design a search engine.
"I cannot see the threat to small libraries [from the Google digitization project], nor can I see much of an advantage."
Gorman's answer to this question stands in stark contrast to those of the participants in the interview. The others give multi-sentence responses, addressing at least some possiblities for advantages and disadvantages to small libraries from the Google digitization project. But the style of Gorman's answer is, again, dismissive, giving the impression he's made up his mind that the Google project is "bad" and that there is no need to consider its impact on libraries, small or otherwise. Perhaps he's carefully thought through all the issues and this quote is the result of a great deal of reflection. But there's no explanation presented, so the reader cannot know. I suspect this style of rhetoric, passing down from on high a conclusion without any explanation or support, will not prove effective for libraries as we increasingly need to talk about our services and expertise to those outside the profession.
In this article, Gorman continues the dismissive style of rhetoric that have incensed so many in his previous comments on the Google projcet and on blogging. The tone is very much one of a person who is certain he is right and need not consider any other arguments put to him. Two quotes in particular caught my eye:
"Any user of Google knows it is pathetic as an information retrieval system..."
This quote, of course, depends heavily on the definition of "information retrieval system." The remainder of the sentence references the traditional IR research metrics of recall and precision, so it's probably reasonable to assume that Gorman is measuring the effectiveness of Google along those lines. And that's one fair way to measure. However, your random Google user is probably unlikely to measure Google according to those terms. Most information needs are for something on a topic rather than everything on a topic. We in libraries are used to (and should be!) focusing on the latter. But that doesn't mean it's the only way to design a search engine.
"I cannot see the threat to small libraries [from the Google digitization project], nor can I see much of an advantage."
Gorman's answer to this question stands in stark contrast to those of the participants in the interview. The others give multi-sentence responses, addressing at least some possiblities for advantages and disadvantages to small libraries from the Google digitization project. But the style of Gorman's answer is, again, dismissive, giving the impression he's made up his mind that the Google project is "bad" and that there is no need to consider its impact on libraries, small or otherwise. Perhaps he's carefully thought through all the issues and this quote is the result of a great deal of reflection. But there's no explanation presented, so the reader cannot know. I suspect this style of rhetoric, passing down from on high a conclusion without any explanation or support, will not prove effective for libraries as we increasingly need to talk about our services and expertise to those outside the profession.
Wednesday, March 09, 2005
PCC reaction to AACR3 Part 1 draft
I've posted before about the divisive reaction occuring in the library world to the forthcoming AACR3 drafts. A new development came about this week when the Program for Cooperative Cataloging (PCC) publicly released their official comments sent to CC:DA (who will then send them on to the JSC) on the AACR3 part 1 draft.
I find the comments strange, to say the least. They're not consistent in tone, which I suppose can be expected for a document compiled from comments from a number of people. But for the most part, it keeps a reasonable message, connecting specific comments to large-scale goals. One major complaint of the document is that evaluation is happening before the introduction is written outlining the principles underlying the rules. While this is true, it's not as if there is no information available on what these principles are. They are discussed in virtually every presentation on AACR3 (some presentation slides are online) and are given in a more formal discussion paper on the AACR3 site. More information on AACR3, its goals, and development process, are available from the JSC site.
The PCC comments spend several pages lampooning the process by which AACR3 is being developed. No news there, and I understand they do this to get on the record objecting, but I wonder if it doesn't do them more harm than good. Certainly at this point the process isn't going to change, and I can envision a reader at the JSC giving less weight to the wealth of very reasonable feedback present in the bulk of the document as a result of the opening diatribe. But then again I could definitely be wrong about that.
There is one other major item of interest to me in this document. The paragraph beginning on page 9 and continuing on page 10 (those are the page #s in the PDF, the printed page #s are 8 and 9), contains what I can only characterize as a threat:
"If COP/JSC continue AACR3 along its current path, AACR3 simply will not be worth our while...AACR3 will become an even bigger laughing-stock in the broader information community. As Chair of the Program for Cooperative Cataloging's Standing Committee on Standards, I feel that I will need to recommend to PCC to look for or develop alternate metadata standards to govern its records."
If this is a threat, it rings as an empty one. While I back to some extent the community asking for more open access to the AACR3 revision process, I don't believe this sort of statement will cause anything to change. Maybe over the next few decades we'll see a large-scale shift in library descriptive practices away from AACR in favor of something else. I'm a bit skeptical of this, but it could happen, albeit slowly. The rhetoric here sounds to me like a child holding her breath and threatening to run away (and believe me, I know how those children feel!). It doesn't read as effective in meeting its goal.
But I don't want these few statements to take away from a great deal of very useful comments in this document. This is the chance to let voices be heard in AACR3 development; here's hoping they don't fall on deaf ears.
I find the comments strange, to say the least. They're not consistent in tone, which I suppose can be expected for a document compiled from comments from a number of people. But for the most part, it keeps a reasonable message, connecting specific comments to large-scale goals. One major complaint of the document is that evaluation is happening before the introduction is written outlining the principles underlying the rules. While this is true, it's not as if there is no information available on what these principles are. They are discussed in virtually every presentation on AACR3 (some presentation slides are online) and are given in a more formal discussion paper on the AACR3 site. More information on AACR3, its goals, and development process, are available from the JSC site.
The PCC comments spend several pages lampooning the process by which AACR3 is being developed. No news there, and I understand they do this to get on the record objecting, but I wonder if it doesn't do them more harm than good. Certainly at this point the process isn't going to change, and I can envision a reader at the JSC giving less weight to the wealth of very reasonable feedback present in the bulk of the document as a result of the opening diatribe. But then again I could definitely be wrong about that.
There is one other major item of interest to me in this document. The paragraph beginning on page 9 and continuing on page 10 (those are the page #s in the PDF, the printed page #s are 8 and 9), contains what I can only characterize as a threat:
"If COP/JSC continue AACR3 along its current path, AACR3 simply will not be worth our while...AACR3 will become an even bigger laughing-stock in the broader information community. As Chair of the Program for Cooperative Cataloging's Standing Committee on Standards, I feel that I will need to recommend to PCC to look for or develop alternate metadata standards to govern its records."
If this is a threat, it rings as an empty one. While I back to some extent the community asking for more open access to the AACR3 revision process, I don't believe this sort of statement will cause anything to change. Maybe over the next few decades we'll see a large-scale shift in library descriptive practices away from AACR in favor of something else. I'm a bit skeptical of this, but it could happen, albeit slowly. The rhetoric here sounds to me like a child holding her breath and threatening to run away (and believe me, I know how those children feel!). It doesn't read as effective in meeting its goal.
But I don't want these few statements to take away from a great deal of very useful comments in this document. This is the chance to let voices be heard in AACR3 development; here's hoping they don't fall on deaf ears.
Monday, March 07, 2005
CCO
I just received this month's copy of American Libraries in the mail, and the printed preliminary program for ALA Annual was included with the mailing. I noticed at first glance that the first session listed under the "Collection Management and Technical Services" track is "Cataloging Cultural Objects: Toward a Metadata Content Standard for Libraries, Archives and Museums." I'm thrilled that CCO is getting some air time in the "mainstream" librarian community - this sort of widening of perspective is sorely needed.
There's a lot of confusion out there, even among experts, about what CCO is supposed to be for, and what its connection is to VRA Core and CDWA. As I read it, CCO is to VRA Core roughly as AACR is to MARC. But then again, many folks don't fully understand the relationship between AACR and MARC is, either, so I suppose the confusion here isn't all that surprising. I'm looking forward to more discussion of CCO to help get the word out.
There's a whole lot more in the program that looks very exciting. I can't wait for June!
There's a lot of confusion out there, even among experts, about what CCO is supposed to be for, and what its connection is to VRA Core and CDWA. As I read it, CCO is to VRA Core roughly as AACR is to MARC. But then again, many folks don't fully understand the relationship between AACR and MARC is, either, so I suppose the confusion here isn't all that surprising. I'm looking forward to more discussion of CCO to help get the word out.
There's a whole lot more in the program that looks very exciting. I can't wait for June!
Wednesday, March 02, 2005
DC and AACR
An interesting development! The DCMI has been approached by the AACR3 folks for input into connecting AACR3 development with other metadata initiatives. Four representatives from the DC Libraries community will be providing offical feedback, and discussion will take place on the DC Libraries list. This is certainly encouraging news!
I'm going to be out of town again until next Monday and won't be posting for the road. Happy weekend!
I'm going to be out of town again until next Monday and won't be posting for the road. Happy weekend!
Subscribe to:
Posts (Atom)
Posts
