Aura: linking data to reuse cataloguing effort / Jenny Wright
•Download as PPTX, PDF•
0 likes•157 views
This document provides metadata for various expressions, manifestations, and works including books, images, and audio recordings. It links this cultural heritage data to support identification and reuse through a unique identifier system. Metadata fields follow the RDA and MARC21 standards and include title, creator, publisher, and format information. Images are also included and linked to the catalogued works and expressions.
Recommended
More Related Content
What's hot
What's hot (19)
More from CILIP MDG
More from CILIP MDG (20)
Recently uploaded
Recently uploaded (20)
Aura: linking data to reuse cataloguing effort / Jenny Wright
- 1. Aura: linking data to reuse cataloguing effort / Jenny Wright.
- 2. Image © BDS
- 3. Image © BDS
- 4. 336 $a text $2 rdacontent 336 $a still image $2 rdacontent 336 $a spoken word $2 rdacontent 337 $a unmediated $2 rdamedia 337 $a audio $2 rdamedia 338 $a volume $2 rdacarrier 338 $a audio disc $2 rdacarrier 339 $a anillustratedbook+bookdisc
- 6. Welsh, Irvine VIAF 101956084 Trainspotting VIAF 219966941 100 1# $a Welsh, Irvine, $e author. 245 10 $a Trainspotting / $c Irvine Welsh. Image: 'Urban love' Found on flickrcc.net http://www.flickr.com/photos/87603889@N00/114094851
- 7. Larsson, Stieg, 1954-2004 VIAF 54441441 Mä̈n som hatar kvinnor VIAF 176384536 100 1# $a Larsson, Stieg, $d 1954-2004, $e author. 240 10 $a Män som hatar kvinnor. $l English 245 14 $a The girl with the dragon tattoo / $c Stieg Larsson ; translated by Reg Keeland. 700 1# $a Keeland, Reg, $d 1943- $e translator. Image: 'Lisbeth Salander' Found on flickrcc.net http://www.flickr.com/photos/52857964@N03/9413055422
- 8. Expr PK URN FK1 Work_URN Expr_Assoc PK URN FK1 Expr_URN FK2 NAF_URN Type Expr_History PK URN FK1 Expr_URN Mani PK URN FK1 Expr_URN Mani_History PK URN FK1 Mani_URN Mani_Title_Statem PK URN FK1 Mani_URN Mani_Variant_Title PK,FK1 URN Mani_URN NAF PK URN Type Work PK URN Work_Assoc PK URN FK1 NAF_URN FK2 Work_URN Type Work_History PK URN FK1 Work_URN Work_LCSH PK,FK2 URN FK1 Work_URN Heading Sub_Division_1 Sub_Division_6 Work_LCSH_Lookup PK URN Work_Relate_Alias PK,FK1 URN Work_Relate PK URN FK2 Work_URN FK1 Work_Related_To_URN Relationship_Type Expr_Relate_Alias PK,FK1 URN Expr_Relate PK URN FK1 Expr_URN FK2 Expr_Relate_To_URN Relationship_Type Mani_Relate_Alias PK,FK1 URN Mani_Relate PK,FK3 URN FK1 Mani_URN FK2 Mani_Relate_To_URN Relationship_Type
- 10. Vickery, Phil. Gluten-free cooking 641.5638 Gluten-free diet -- Recipes Text. English Kyle Cathie 2009 9781856268288
- 11. Vickery, Phil. Gluten-free cooking 641.5639311 Gluten-free diet -- Recipes Text. English. 2009 Kyle Cathie 2009 9781856268288 Text. English. 2016 Kyle Books 2016 9780857833150
- 12. Brookes, Geoff. Swansea then & now. Text. English Stroud: The History Press, 2015 9780750965033
- 18. Stevenson, Robert Louis, 1850-1894. Treasure island. Text. English London: Egmont UK Limited, 2015 9781405279598 London : Blackie, 1979 0216885086 Spoken word. English Bath: Chivers Audio, 2008 9781405647571 Muppet Treasure Island (Motion picture: 1996)
- 19. Stevenson, Robert Louis, 1850-1894. Treasure island. Text. English London: Egmont UK Limited, 2015 9781405279598 London : Blackie, 1979 0216885086 Bath : Chivers, 2002 9780754049135 Spoken word. English Bath: Chivers Audio, 2008 9781405647571 Cool! Well done remembering dinner money I've paid Thom's Explorer camp way back when (thankfully doesn't clash with the Nairn weekend, I'd forgotten all about it ) xxx
- 20. Rowling, J. K. Harry Potter and the philosopher’s stone. Text. English London: Bloomsbury, 1998. 9780747542988 London : Bloomsbury, 1997 9780747532699
- 27. Image © BDS
- 28. Image © BDS
- 29. Image © BDS
- 30. Image © BDS
- 31. Image © BDS
- 32. Image © BDS
- 33. Image © BDS
- 34. Image © BDS
- 35. Image © BDS
- 36. Image © BDS
- 37. Image © BDS
- 38. Image © BDS
- 39. Image © BDS
- 41. Image © BDS
- 42. Image © BDS
- 43. Image © BDS
- 44. Image © BDS
Editor's Notes
- Today I’m going to tell you about some work I’ve been involved with that I hope all cataloguers will find of interest – the conception and construction of new software for a cataloguing and associated data entry system. In order for it all to make sense, I want to provide a little bit of context for the Aura project.
- BDS is a cataloguing agency founded in 1995, creating bibliographic records to library standards in a production environment. We’re based in Dumfries, in southwest Scotland, and have expanded into beautiful premises on the Crichton campus. We use in-house cataloguing software. When the BDS data entry system was created in 1995 we used the best available technology. It is DOS-based, not a Windows application, and unfortunately therefore looks dreadful in comparison with modern user interfaces.
- It was created under time pressure, but worked well and has had many features added over the years, in reaction to specific demands or because of staff ideas about how to improve things. It requires users to have a lot of training, in MARC21 and internal processes. Data entry by skilled users is efficient, but there are issues: only so much of the record is visible at once, so the record is best handled in MARC field order as it does not allow moving around in the record easily. It also requires IT support staff to have knowledge of a programming language called Dataflex which is not commonly used, and that was becoming more of an issue too. We can do things like going straight to the Name Authority File from an appropriate MARC field, make our selection and then pull it back into the record,
- and we have lots of macros: the best example of a shortcut is in our use of the new Content, Media and Carrier fields in RDA. There are 3 separate, repeatable MARC fields to handle these, and many resources need multiple fields. Rather than enter all that is required, and take up lots of lines on our entry screen, we came up with an in-house solution of using a single line description in a local 339 field. This is expanded on export to the full set of 336, 337, and 338 fields. However, even with all of these built in features, we still felt we could do better. We needed a new data entry system, and a significant catalyst was the advent of RDA.
- We moved to using RDA as the cataloguing standard in January 2013. RDA is based on the conceptual model of FRBR, using the concepts of works, expressions and manifestations. A WORK is realised through its expression which is embodied in the manifestation. It’s manifestations which we catalogue, and to date we’ve created an individual record for each manifestation.
- As we moved to implementation, it became obvious to us and the rest of the cataloguing world that RDA does not fit well in MARC. In some ways, this made implementation easier, as it meant smaller changes in practice. But MARC hides a lot of the ‘intent’ in RDA cataloguing, which doesn’t help us fully embrace RDA. In this example, work title and manifestation title proper are the same – Trainspotting. So we only have a 245 in MARC, giving us both the Work title and the transcribed manifestation title proper.
- But when the Work and Manifestation titles are different, then in MARC we need a 240 as well as 245. I could argue that all records should have a 240 for the Work title as well as the 245 for the manifestation title, but few have the time to do that, or the resources to make it happen automatically. The concepts and elements are quite different, and RDA in MARC cannot fully realise the relationships involved.
- So, as we plotted a new data entry system, The use of the FRBR model underlying RDA, and the advent of linked library data, as well as a hope for a ‘master’ record long in mind, suggested a relational database structure. A relational database holds data in tables which have relationships to one another. It is quite a different way of conceptualising data, compared to the flatfile structure we’re used to thinking in with our MARC21 trained brains. And note that I say “Data” rather than “Records”, which is a significant change of mindset. As cataloguers who deal with manifestations, the cluster of associated data for a manifestation could be called a record, but more and more we’re going to have to find ways to change the way we think about bibliographic information.
- The relational database is powerful, because if we change data in one table, all connected tables are also affected. For example, this provides the means to make sure that all name headings in records are current: if a name in the Names Table is updated, such as when a date of death is added, then any table making use of that data is automatically updated too.
- In this example, when the first manifestation was catalogued in 2009, there was no specific Dewey number for Gluten free cooking, so it just had Cooking with respect to food content.
- Now, when the 2016 updated edition comes out, we do have a specific Dewey number for Gluten-free cooking. By updating the Dewey of the Work, we update the Dewey for every manifestation of that work (yes, they’re different Expressions, because of updated content). It’s also possible for BDS to have multiple manifestations of a work, some of which we’ve only had publisher information on and some of which we’ve catalogued book-in-hand. Any confirmed details which affect the Work and Expression for the Manifestation we have in hand will then also positively affect the data for the other manifestations.
- Whilst many manifestations can plug in to a network of connected resources, plenty do not and so the new system still needed to be efficient enough for all those ‘individual’ type titles too.
- So, we wanted a system that allowed this entities and relationships model to be made full use of, but it still had to produce MARC records, have an eye on the future with Bibframe and Linked Library Data, and support rather than hinder productivity. It also has to be able to import data, as we receive most of our information from publishers via an ONIX feed, and there’s all our legacy data in our current database too. So, we wanted something that kept our data as granular as possible, with a good user interface and as much of our cataloguing expertise built in as we could write logic statements for….
- The work is far from over, but we’re far enough through that I can identify three main areas of work: the model for the database, being able to bring MARC records and get MARC records out, and the business rules which support the creation of good data. I’ll talk about the kinds of issues involved with each of those.
- We began by listing all the bits of information we wanted to include, and deciding whether they belonged with the Work, Expression or Manifestation. In addition to the RDA elements, we needed to capture additional information that the MARC record would need, and internal requirements such as trade edition statements.
- An easy, early decision, was to use as many identifiers as we could easily find. Each entity having a unique identifier is inherent in the relational database structure, but wherever possible we also wanted to store persistent global identifiers like ISNIs, and NACO control numbers. This supports future linked data developments.
- The NACO identifiers are in all the Name authority records on the Library of Congress Authorities site, and form part of the permalink to the record
- We were using a bibliographic conceptual model as our basis – we were quite happily thinking in terms of Works, Expressions, Manifestations, related Works, and so on.
- However, the RDA implementation of the FRBR model is only dealing with descriptive cataloguing, and not with classification and indexing. The biggest issues were actually where that model interfaced with other knowledge organisation systems……RDA has subject as a Work level attribute[C]. And sure, Adventure stories is a genre one could apply to the work. But Library of Congress Subject Headings also includes form headings such as Talking books [C] and Large type books [C] which pertain to Expression and Manifestation levels respectively. Our solution was to not put these kind of form headings in the Work record along with the rest of the LCSH, but to automatically add Talking books when the Main content type is “spoken word”, and add Large type books (as well as a bunch of other stuff) when the “is this large print” box was ticked.
- And then there was the issue of Audience, which is also a Work level attribute in RDA. Except, it’s easy to find Manifestations which present to different Audiences, without modifying the work in any way. The best example requires us to cast our minds back a couple of decades - when J.K. Rowling’s Harry Potter first appeared on the scene, it was uncommon for books to be marketed at more than one audience. The Harry Potter phenomenon has affected publishing in many ways, not least that books can be marketed at both adults and children. Particularly in the then pre-Kindle days when it was deemed that no adult would read an obviously child’s book in public, they were issued with different covers and different ISBNs for the sake of stock control. Given that this is infrequent though, we solved that one by having an Audience override at Manifestation level.
- Interfacing with Dewey also had its issues. Dewey has different class numbers depending on the language or even version of the Bible. But even with setting up a new work for each different version, which perhaps should strictly only be a new Expression, we have an issue with aggregate works.
- Aggregate works are anything that can be split into separate works, so a book containing articles by different authors is the obvious example, but there are so many: omnibuses of novels, for example The Lord of the rings in one volume, or box set; continuing resources keep on aggregating of course. The principal problem we had to solve was self-referencing works. By that I mean a publication which both IS and is ABOUT a particular work, such as the text of Hamlet + study notes, or if we go back to our bible example
- A Bible which has commentary as well as the Bible text. Self-referencing works cause all sorts of modelling issues
- Our solution is pragmatic. We create works where we need them, and avoid self-referencing. That covers the highlights of our modelling problems.
- The next set of problems was to do with the interface with MARC: importing data that’s less granular than your database is problematic. Exporting required a high level of complexity, but it did fall to logic. So, here’s a MARC record – MARC has its problems, but many fields are absolutely fine. The 245 Title field and the 300 Physical description field are both examples of difficult areas in MARC, because the granularity is relatively poor. Let’s focus on the 300 field, and I’ll demonstrate what I mean by poor granularity.
- So, this first example has quite clean data. The pagination is simple, as is the size in the subfield $c. Subfield $b, however, has two pieces of information – whether there are illustrations, and whether they are coloured, or not. In our second and third examples, you can start to see how the pagination can be difficult from a machine readable point of view. When we look at an AACR2 300, we have a new set of problems, and then if we look at the 300 of a nonbook item, you can really start to see what I mean by ‘lack of granularity’ – the same MARC fields are used for lots of very different information.
- OK, having outlined the plan, and the sorts of problems we encountered whilst enacting that plan, I think it’s best to move now to looking at some outcomes, via the initial User interface. We used a tabbed layout, to optimise visibility of data elements and their accessibility for entering and editing by the user. So, there’s a Work, Expression, and Manifestation tab available and each of those has tabs for specific aspects of the data.
- So, in our test User interface, you can see a search box top left. Double clicking on a result brings up the relevant information in the main screen, and a WEM tree in the bottom left.
- In the Expression Language Tab, you can see how we choose the Language from the controlled list – either the Complete range of possibilities, or a
- Core list of more likely options.
- Because of the details that a MARC record requires in the 041 field, we had to add further fields to our database to make sure we capture the information we’d need to build the 041.
- In the Expression Physical Expression tab, again we have this controlled list approach to describing the illustrations in the expression.
- …and whether or not they are coloured. Note that because of our CIP work, lack of information about illustrations may not mean that there are no illustrations, so we have a “No information” option to keep that nuance. So, if a new manifestation shows that a particular Expression has illustrations, and the existing Expression was based only on CIP data, then the fact that it didn’t have illustrations wouldn’t mean it wasn’t a match.
- Again, keeping everything straight in our database, MARC and future data carriers, meant lots of detail in the Manifestation title statement. The MARC 245 field is not very granular, and often important information is conveyed only in ISBD punctuation. This is not machine readable. How is a computer supposed to tell when a full stop is present because of an abbreviation, and when its presence signals a Part work title coming after a statement of responsibility? So, we’ve got lots of detail being added here, to allow the correct construction of the 245 field and also to satisfy ourselves that we could lay hands on a specific piece of data if we needed to.
- Library suppliers, and libraries organising their own book processing, need a lot more detail on the physical carrier than RDA asks for, and so trade information on format had to be included as yet another field for the manifestation.
- Given all the issues with making sure we could get MARC records out of our data, the user interface has a MARC view, allowing skilled users to check the output.
- This is work that is not yet finished, but it’s pretty good for a starting point.
- So, given that we’re hoping that many of the manifestations needing catalogued have related entities in the system already, how does that work? This expression has an illustrator
- And this one has a different illustrator. You can see them appear in the tree in the sidebar, as we add them to the database. In the top left hand box, which is the Search box, you may be able to see the ISBN I entered – if it’s not in the database, the system searches elsewhere – principally our existing, original database.
- So, let’s look at what our system does when importing a MARC record. If I enter the ISBN, and it’s not in the database, the system looks for it elsewhere. When a match is found,
- we then have this window appear, which attempts to match to Works and Expressions already in the system. It’s matching against the author and title, and when we accept the suggested Matching work, or choose a different one, it goes on to look for matching expressions. If you decide it’s a new work, then obviously it will need to be a new expression too.
- Since this has a different illustrator from the other two, there’s no match and it suggests a new expression be created. Clicking on that “tick” then checks details of the manifestation before the final Import instruction is selected,
- And we now have some work to do, but far less than creating the record from scratch.
- Another tool added, as much to check our progress with building the logic of MARC creation as anything, is the compare the imported MARC record with the MARC that is created from the Aura system. Information in the original record that is not in the new record is highlighted in red, information in the new record that is not in the original is highlighted in green, and differences in fields is highlighted orange.
- OK, I’ve mentioned modelling, I’ve mentioned MARC import and export, the last big chunk of work to talk about is Business rules. When I talk about business rules in this context, I mean the kind of rule that says “If you’ve identified this resource as having the Main content type of text, then you cannot have data in the field for Expression duration, because that only applies to Spoken word, Performed Music, or Moving images.” As you can imagine there are a lot of logic statements which could be deployed, and we’re still adding to them.
- Many of the rules in the background will support users, by providing defaults which 9 times out of 10 will save a few keystrokes. For instance, the Language of the Expression defaults to English. Other defaults are more conditional, and akin to choosing which track you’re on. For instance, the main content type defaults to Text, unless the work form chosen suggests otherwise. If the main content type chosen is Spoken word, then the system will expect fields, such as Duration, and Sound characteristics, to be used, and Not Map scale. If the Large Print? Is changed to Yes, then (large print) can be added to the pagination, a trade edition statement of Large print edition, and the LCSH form heading Large type books can be added. The final component to the business rules is error checking – a Work has to have a title, and other core pieces of information, so the system won’t let you save it unless the core requirements are met. If the physical format chosen is incompatible with other data elements, the system can flag that up to the user. Now that we’re in a Windows environment, we could also do things like use system dictionaries to flag up spelling errors, though I haven’t explored that with the development team yet as we’ve a heap of higher priorities to deal with first.
- So, we’re moving away from a text based, records based way of looking after library data, to use as many identifiers and discrete pieces of data as we can. If cataloguing becomes more about identifying entities and their relationships, this will facilitate better search and retrieval for users, and I think making cataloguing more intellectually satisfying in the process.
- If cataloguing becomes more about identifying entities and their relationships, this will facilitate better search and retrieval for users, and I think making cataloguing more intellectually satisfying in the process. RLS Jekyll and Hyde Works about Works based on Alan Grant Batman
- There’s still an awful lot to do before we get to the celebratory stage, and I chose this image more for the cascading than the champagne. A significant training issue for this new system will be to make users realise the effect that changing information in just one field can potentially have. We also need to make decisions about exactly what kind of field changes are worth triggering a “resend record” status. Our customers want up-to-date records, but will they want 10 new manifestation records just because a new Dewey number has been issued and applied? Given that it is unlikely to match the spine label, such changes might cause problems to customers. A careful review will be part of that decision. One possibility became known as the Aspic rule, as in “after a certain point, records are going to have to be considered set in aspic, even when data changes” So, all caveats aside, this continues to be an interesting project and I’m looking forward to getting to the testing stage shortly. Thanks for listening.