Metadata Matters

Category: Linked data

  • Onward!

    One of the things Jon and I still talk about (despite our putative retirement), is how to pass on to the newer generation what we’ve learned over our years working in the vocabulary, data maintenance and data aggregation spaces. Of course, we’ve written or co–written quite a few papers and articles, and most continue to be read and cited (or so ResearchGate tells me), and as well we have significant numbers of presentations and slides available freely.

    Jon sometimes tries to convince me that in the age of AI and waning interest in metadata and vocabularies, particularly in non-library research venues, our time of relevance has passed. He may be right in some respects, but I’m not convinced that’s true in libraries. And the Open Metadata Registry, still alive and quietly kicking, is still being used by an interesting variety of vocabulary nerds. I checked today and noted that there’s a NASA Name Authority vocabulary still in active development as of last week (I haven’t checked to see whether the developers have been active during the partial government shutdown or not).

    Recently, I worked on the NISO effort to describe the state of the vocabulary world and one of our main discoveries was how few of the tools developed over the past few years are still functioning. Most were developed using research funding, notoriously time limited (one or two years is common). What’s left is an array of commercial products (difficult to determine how effective they are, though they’re certainly costly), and the OMR, which we’ve been supporting since our NSF funding dried up in 2008. We had funding from ALA Publishing for some of that time, and we’re still working on a beta version of the OMR.

    We’d like to find out whether there’s any interest out there in figuring out what can be done, in the non-commercial realm, to determine what the needs are–in libraries particularly, but also in other institutions–for continuing a service like the OMR, and what might be strategies to continue it (or something similar) into the next decade or so.

    Ultimately an important question is whether formal RDF vocabulary management matters in a data world dominated by Machine Learning, fragmented by the low bar set for publishing ‘Linked Data’ and the ongoing ‘format wars’ in the library community. Vocabularies matter when definitions are clearly expressed and mechanisms are provided to align heterogeneous metadata across divergent datasets. Definitions and alignments have to be maintained over time — all data has a lifespan of utility. Too often data is released into the wild of the internet without any thought to how it will be consumed and how it will be maintained. Ongoing vocabulary maintenance is crucial to future-proofing public datasets. Or is it all just too hard, given the pressures of funding and the more immediate worry of whether you’ll still have a job next week?

    Given the burgeoning of podcasts on anything and everything, we’ve considered whether that might be a way to get some interesting conversations going (maybe even interviews, which are my favorite kind to listen to). Or we might just up the effort to continue blogging (thus cementing our reputation for persistence!) Do mention some topics that interest you, whether for the blog or (possibly) a podcast. Comments welcome in the comment section of this blog, or on Twitter, at @Metadata_Maven or @jonphipps.

    Discuss!

  • Hey BibFramers, what’s it all about?

    One of the ongoing myths about RDA is that it’s just a set of instructions and rules for the creation and maintenance of bibliographic metadata, regardless of data model. This has never been entirely accurate, since the RDA instructions explicitly reference RDA’s FRBR-based metadata model, which was significantly modified by BibFrame. But the notion of RDA-as-rules divorced from its data and infrastructure seems still to be part of the promotion of Bibframe. This is not helpful, and when the misinformation is stated over and over it begins to look like an Alternative Fact.

    For example, as part of the Bibframe Update presentations at ALA in Chicago, it was stated that the Bibframe editor will have the “RDA rules hot linked to element labels” (presumably from the Toolkit) to assist catalogers using BF to create bib data. I find this difficult to get my head around — BF and RDA use different reference models, name things differently, etc. And the RDA 3R project to reorganize and rewrite the instructions to align RDA with the IFLA LRM (which is both more extensive than, and less aligned with the Bibframe model) is well underway, and will likely confuse the issue even more.

    The contention that RDA guidance can be used to build BF data is certainly not new. What is new was the momentum of change in process with RDA, from the R3 project, to the internationalization of RDA governance, to the growing list of translations. When the 3R Project is complete (early next year), the RDA instructions in the Toolkit and the data in the RDA Registry will be far more integrated than AACR and MARC ever were. Whether that integration will leave room for BibFrame to use the new instructions is unclear.

    There was an impressive list of RDA information sessions at Annual, and an increasing numbers of folks attending them. This suggests that the RDA message seems to be gaining momentum, and there’s mounting evidence that this is so. A few presentations from the “RDA towards Linked Data sessions, held in conjunction with the European RDA Interest Group (EURIG) annual meeting in Fiesole, Italy this May illustrate that point:

    In his presentation, Philip Schreur pointed out that RDA “is a natural representation of our data on the Web” because of its extensible and flexible framework, its rich treatment of relationships, and its focus on resource discovery.

    Gordon Dunsire’s presentation showed how the wider implementation of the “4-fold path” in RDA for data capture and storage is intended to support a full range of data representation from catalogue cards, flat file schema, and RDBMS, to linked data.

    Most people who attended the RDA sessions in Chicago seemed to be very interested in RDA’s approach, in particular how the data is handled, the growth of translations, and the strong desire to extend RDA to meet the needs of specialized cataloging communities. A meeting to explore the needs of those communities was exceptionally well attended, with lots of good suggestions. And the RDA Linked Data Forum (where people actually got a chance to ask questions!!) was standing room only. (My slides are here).

    There are definite challenges for the North American cataloging community moving forward if they want to avoid isolating themselves from the rest of the bibliographic world, by and large unenthusiastic about BibFrame. The Anglo-American cataloging rules are fading into the distance as the rest of the world embraces the reality of a truly multinational, multilingual, multicultural metadata environment, exemplified by the RDA/LRM bibliographic model. The North American bibliographic community has never been explicitly “America First” and now is not the time to start.

    Stay tuned.

  • The RDA Toolkit == The RDA Data Model

    Sitting in the CC:DA meeting at ALA last week, listening to the RDA report and the questions it generated, I was struck yet again by the disconnect between the understanding by the audience of RDA as a content model — the Instructions as embodied in the Toolkit — and the presentation by the speakers of the changes to both the RDA Toolkit and the RDA Registry in terms of the changes to the RDA data model.

    In the case of the Toolkit, a significant part of the reorganization is intended to better align the Toolkit with the Registry, the data model. In the case of the Registry, a significant portion of the changes are intended to continue the current data model’s status as an implementation of FRBR, and to adjust the model to accommodate the consolidation of the various FRBR models into the IFLA LRM.

    From its inception, the Toolkit has reflected the RDA instructions, an upgraded and internationalized version of AACR2, originally intended to provide content instructions for populating the MARC21 carrier, while conceptually describing the data in terms of the FRBR-oriented RDA carrier. The changes to the Toolkit are a necessary evolution away from the slowly devolving MARC21 data model toward the RDA data model. But the audience doesn’t, can’t, easily see that distinction, and the ‘questions’ swirl around expressions of discomfort with the changes that reflect a lack of understanding of the broadening disconnect between the Toolkit and the Registry, and between RDA and MARC21.

    This cognitive dissonance must be addressed by the RSC and its representatives at every future opportunity when discussing the rationale for both the alignment of the RDA data model with IFLA LRM, and the alignment of the RDA content model in the Toolkit with the RDA data model. In that context, the global bibliographic community needs definitive guidance in understanding the relationship between the entities and elements of the RDA data model and the MARC21 data model in which they currently create and maintain their metadata.

  • The Vocabulary Management Mess

    Announcement: The vocabulary management mess needs your attention.

    In 2013 I wrote a couple of posts critical of some updating practices LC was using in its id.loc.gov services. The first post focused on the relators vocabulary, and how change was handled within that vocabulary.

    The follow-up post dealt with the unacknowledged gaps in the LCSH service on id.loc.gov.

    So, here we are almost three years later, and not much has changed. I went back through the examples in pt. 1, and the issues pointed out there are still exactly as noted three years ago. For those three years there have been many discussions about linked open data, but the vocabulary infrastructure needed to support LOD is still largely not ready for prime time.

    And it’s not as if nobody’s been thinking about solutions. We wrote a paper about how versioning management ought to work in vocabulary services, but it seems to have been overlooked by even the large established services. It’s hard to avoid the conclusion that there just hasn’t been much recognition of the problem we were trying to solve. Trust me, it’s a real problem, and a very big one at that. It’s not just local, or attached to one institution–we’re talking about an international problem, one that could delay the uptake of linked data far longer than we’d like.

    For users of vocabularies, the absence of vocabulary services (aside from simple lookup and basic file download) are a large impediment to the actual use of LOD. How does a creator of bibliographic data–who we’ve been encouraging to use vocabularies–actually use those vocabularies to manage their overall data needs over time? By downloading files and examining diffs every week (month, quarter, year)? Remember when we had to cruise websites to find out when a new software update was available? We’re at that stage right now in vocabulary management, and not making progress towards a service environment that will actually support the use of vocabularies in data.

    To think about ‘how big’ the problem is, consider how many vocabularies occur regularly in instance data: ISBD, FRBRer, RDA, schema.org, DC Terms, etc. When terms in those vocabularies change, how do those managers of instance data know what has changed? Should they be expected to just leave the old data as is, or send it to the cleaners every year or so? Proper vocabulary management practices can be a big part of the answer–the machine-assisted answer.

    So, what’s to be done?

    Just about 10 years ago, LC initiated a Working Group on the Future of Bibliographic Control, complete with blue ribbon membership and a broad remit to look around and suggest a path for re-imagining what they and other libraries were facing as they worked towards a different future. Full day hearings were held in three locations across the US and these events drew so much interest that the streaming capabilities set up for the sessions were overwhelmed. I testified at one of those hearings, and–I’m sure you’re surprised–spoke about the value of vocabularies in this brave new world.

    But the amazing thing was the level of interest and engagement of the library community in the issues discussed by the WG. I’m not sure I’ve ever seen anything like it, before or since. For a while there, every time I was asked to present at a meeting, the WG report was the desired topic. Literally everyone was talking about it–the community clearly recognized the importance of the effort and wanted to be part of it.

    We definitely need something like that again–a place to bring together the community and its experts, to state the problems and brainstorm the solutions. Let’s call it a ‘Library Vocabulary Summit’, for the moment, and roll the possibilities around in our heads. We’d need funding, leadership, and marketing to make it happen. Let’s ALL talk! (Preferably around a large table, face to face, with a relevant agenda).

  • Why Do We Undervalue Maintenance?

    I ran across a really interesting article last week, and the points it makes have been rocketing around my head as I consider what’s broken (and why) in the small world many of us live in, not to mention how we can fix those broken things. I’d really recommend taking a look at it: “Hail the maintainers: Capitalism excels at innovation but is failing at maintenance, and for most lives it is maintenance that matters more”, by Lee Vinsel & Andrew Russell.

    The gist of the authors’ point–that we overvalue innovation and undervalue the maintenance of our existing technologies–is one that ought to resonate particularly with librarians, especially those of us who have toiled in the world of catalogs and the maintenance of same.

    “The most unappreciated and undervalued forms of technological labour are also the most ordinary: those who repair and maintain technologies that already exist, that were ‘innovated’ long ago. This shift in emphasis involves focusing on the constant processes of entropy and un-doing – which the media scholar Steven Jackson calls ‘broken world thinking’ – and the work we do to slow or halt them, rather than on the introduction of novel things.”

    One of the things that struck me in this article was the connection the authors made between ‘innovation’–associated with high tech activities primarily seen as the male domain, and ‘maintenance’, the ‘women’s work’ of the age of technology.

    “We can think of labour that goes into maintenance and repair as the work of the maintainers, those individuals whose work keeps ordinary existence going rather than introducing novel things. Brief reflection demonstrates that the vast majority of human labour, from laundry and trash removal to janitorial work and food preparation, is of this type: upkeep. This realisation has significant implications for gender relations in and around technology. Feminist theorists have long argued that obsessions with technological novelty obscures all of the labour, including housework, that women, disproportionately, do to keep life on track.”

    The authors make the point that these skewed values resonate throughout our society. Notice how boring most people consider the maintenance of our physical infrastructure–roads, bridges, pipelines, etc. Of course, most of us agree that there needs to be more of it, and more resources aimed in that direction, but ho hum, talk about it in any detail? Not on your life.

    For those of us considering the data infrastructure to support the rebuilding and expansion of the data sharing that libraries have done for many decades, we see the same thing. The Open Metadata Registry (OMR to those of us who prefer to speak in acronyms), now too often dismissed as ‘old technology’, is a case in point. Back in 2004 when we received funding from the National Science Foundation, there weren’t many people thinking about data ‘infrastructure’–particularly for vocabulary data, but we were. Back in the day, we often talked about the OMR in the context of the plumbing beneath sidewalks and buildings. Few of us who are not plumbers think about plumbing — we all assume that it’s there, but is rarely a topic in non-plumber gatherings until something critical breaks, or a community is systematically poisoned.

    And even plumbers innovate, in ways that few of us understand, much less think about. The water debacle in Flint, Mich. has brought up the problems of old pipes, but not many discussions go beyond that. In the world of vocabulary management, the OMR has been building and maintaining vocabularies for well over a decade now, and we know a lot about it. In particular we know where improvements should be made, and how OMR services can best support the activities needed by the folks building instance data. We’re also thinking about how to better sustain the effort over time.

    But the OMR was built to work within an environment where there are many such services, supporting other communities looking at the same changes ahead that we see in the library data environment. For lots of reasons, that array of services hasn’t come about, though we see activity in the structural metadata world–new formats, old formats morphing, etc.–effort almost entirely devoted to semantic churning, not services. Much effort is being put into creating and publishing Linked Open Data, but very little consideration is being given to how that data will need to change over time and how the entire plumbing infrastructure of publishing and consuming that data must support the need for ongoing maintenance of both the data and the public and private vocabularies that describe that data.

    [This is the first of two posts, the second proposing some ways to move forward]

  • Denying the Non-English Speaking World

    Not long ago I encountered the analysis of BibFrame published by Rob Sanderson with contributions by a group of well-known librarians. It’s a pretty impressive document–well organized and clearly referenced. But in fact there’s also a significant amount of personal opinion in it, the nature of which is somewhat masked by the references to others holding the same opinion.

    I have a real concern about some of those points where an assertion of ‘best practices’ are particularly arguable. The one that sticks in my craw particularly shows up in section 2.2.5:

    2.2.5 Use Natural Keys in URIs
    References: [manning], [ldbook], [gld-bp], [cooluris]

    Although the client must treat URIs as opaque strings, it is good practice to construct URIs in a systematic and human readable fashion for both instances and ontology terms. A natural key is one that appears in the information about the resource, such as some unique identifier for the resource, or the label of the property for ontology terms. While the machine does not care about structure, memorability or readability of URIs, the developers that write the code do. Completely random URIs introduce difficult to detect semantic and algorithmic errors in both publication and consumption of the data.

    Analysis:

    The use of natural keys is a strength of BIBFRAME, compared to similarly scoped efforts in similar communities such as the RDA and CIDOC-CRM vocabularies which use completely opaque numbers such as P10001 (hasRespondent) or E33 (Linguistic Entity). RDA further misses the target in this area by going on to define multiple URIs for each term with language tagged labels in the URI, such as rda:hasRespondent.en mapping to P10001. This is a different predicate from the numerical version, and using owl:sameAs to connect the two just makes everyone’s lives more difficult unnecessarily. In general, labels for the predicates and classes should be provided in the ontology document, along with thorough and understandable descriptions in multiple languages, not in the URI structure.

    This sounds fine so long as you accept the idea that ‘natural’ means English, because, of course, all developers, no matter their first language, must be fluent enough in English to work with English-only standards and applications. This mis-use of ‘natural’ reminds me of other problematic usages, such as the former practice in the adoption community (of which I have been a part for 40 years) where ‘natural’ was routinely used to refer to birth parents, thus relegating adoptive parents to the ‘un-natural’ realm. So in this case, if ‘natural’ means English, are all other languages inherently un-natural in the world of development? The library world has been dominated by the ‘Anglo-American’ notions of standard practice for a very long time, and happily, RDA is leading away from that, both in governance and in development of vocabularies and tools.

    The Multilingual strategy adopted by RDA is based on the following points:

    1. More than a decade of managing vocabularies has convinced us that opaque identifiers are extremely valuable for managing URIs, because they need not be changed as labels change (only as definitions change). The kinds of ‘churn’ we saw in the original version of RDA (2008-2013) convinced us that label-based URIs were a significant problem (and cost) that became worse as the vocabularies grew over time.
    2. We get the argument that opaque URIs are often difficult for humans to use–but the tools we’re building (the RDA Registry as case in point) are intended to give human developers what they want for their tasks (human readable URIs, in a variety of languages) but ensure that the URIs for properties and values are set up based on what machines need. In this way, changes in the lexical URIs (human-readable) can be maintained properly without costly change in the canonical URIs that travel with the data content itself.
    3. The multiple language translations (and distributed translation management by language communities) also enable humans to build discovery and display mechanisms for users that are speakers of a variety of languages. This has been a particularly important value for national libraries outside the US, but also potentially for libraries in the US meeting the needs of non-English language communities closer to home.

    It’s too easy for the English-first library development community to insist that URIs be readable in English and to turn a blind eye to the degree that this imposes understanding of the English language and Anglo-American library culture on the rest of the world. This is not automatically the intellectual gift that the distributors of that culture assume it to be. It shouldn’t be necessary for non-Anglo-American catalogers to learn and understand Anglo-American language and culture in order to express metadata for a non-Anglo audience. This is the rough equivalent of the Philadelphia cheese steak vendor who put up a sign reading “This is America. When ordering speak in English”.

    We understand that for English-speaking developers http://bibframe.org/vocab/title is initially easier to use than http://rdaregistry.info/Elements/w/P10088 or even (heaven forefend!) “130_0#$a” (in RDF: http://marc21rdf.info/elements/1XX/M1300_a). That’s why RDA provides http://rdaregistry.info/Elements/w/titleOfTheWork.en but also, eventually, http://rdaregistry.info/Elements/w/拥有该作品的标题.ch and http://rdaregistry.info/Elements/w/tieneTítuloDeLaObra.es, et al (you do understand Latin of course). These ‘unnatural’ Lexical Aliases will be provided by the ‘native’ language speakers of their respective national library communities.

    As one of the many thousands of librarians who ‘speak’ MARC to one another–despite our language differences–I am loathe to give up that international language to an English-only world. That seems like a step backwards.

  • Separating ideology, politics and utility

    Those of you who pay attention to politics (no matter where you are) are very likely to be shaking your head over candidates, results or policy. It’s a never ending source of frustration and/or entertainment here in the U.S., and I’ve noticed that the commentators seem to be focusing in on issues of ideology and faith, particularly where it bumps up against politics. The visit of Pope Francis seemed to be taking everyone’s attention while he was here, but though this event has added some ‘green’ to the discussion, it hasn’t pushed much off the political plate.

    Politics and faith bump up against each other in the metadata world, too. What with traditionalists still thinking in MARC tags and AACR2, to the technical types rolling their eyes at any mention of MARC and trying to push the conversation towards RDA, RDF, BibFrame, schema.org, etc., there are plenty of metadata politics available to flavor the discussion.

    The good news for us is that the conflicts and differences we confront in the metadata world are much more amenable to useful solution than the politics crowding our news feeds. I remember well the days when the choice of metadata schema was critical to projects and libraries. Unfortunately, we’re all still behaving as if the proliferation of ‘new’ schemas makes the whole business more complicated–that’s because we’re still thinking we need to choose one or another, ignoring the commonality at the core of the new metadata effort.

    But times have changed, and we don’t all need to use the same schema to be interoperable (just like we don’t all need to speak English or Esperanto to communicate). But what we do need to think about is what the needs of our organization are at all stages of the workflow: from creating, publishing, consuming, through integrating our metadata to make it useful in the various efforts in which we engage.

    One thing we do need to consider as we talk about creating new metadata is whether it will need to work with other data that already exists in our institution. If MARC is what we have, then one requirement may be to be able to maintain the level of richness we’ve built up in the past and still move that rich data forward with us. This suggests to me that RDA, which RIMMF has demonstrated can be losslessly mapped to and from MARC, might be the best choice for the creation of new metadata.

    Back in the day, when Dublin Core was the shiny new thing, the notion of ‘dumb-down’ was hatched, and though not an elegantly named principle, it still works. It says that rich metadata can be mapped fairly easily into a less-rich schema (‘dumbed down’), but once transformed in a lossy way, it can’t easily be ‘smartened up’. But in a world of many publishers of linked data, and many consumers of that data, the notion of transforming rich metadata into any number of other schemas and letting the consumer chose what they want, is fairly straightforward, and does not require firm knowledge (or correct assumptions) of what the consumers actually need. This is a strategy well-tested with OAI-PMH which established a floor of Simple Dublin Core but encouraged the provision of any number of other formats as well, including MARC.

    As consumers, libraries and other cultural institutions are also better served by choices. Depending on the services they’re trying to support, they can choose what flavor of data meets their needs best, instead of being offered only what the provider assumes they want. This strategy leaves open the possibility of serving MARC as one of the choices, allowing those institutions still nursing an aged ILS to continue to participate.

    Of course, the consumers of data need to think about how they aggregate and integrate the data they consume, how to improve that data, and how to make their data services coherent. That’s the part of the new create, publish, consume, integrate cycle that scares many librarians, but it shouldn’t–really!

    So, it’s not about choosing the ‘right’ metadata format, it’s about having a fuller and more expansive notion about sharing data and learning some new skills. Let’s kiss the politics goodbye, and get on with it.

  • Five Star Vocabulary Use

    Most of us in the library and cultural heritage communities interested in metadata are well aware of Tim Berners-Lee’s five star ratings for linked open data (in fact, some of us actually have the mug).

    The five star rating for LOD, intended to encourage us to follow five basic rules for linked data is useful, but, as we’ve discussed it over the years, a basic question rises up: What good is linked data without (property) vocabularies? Vocabulary manager types like me and my peeps are always thinking like this, and recently we came across solid evidence that we are not alone in the universe.

    Check out: “Five Stars of Linked Data Vocabulary Use”, published last year as part of the Semantic Web Journal. The five authors posit that TBL’s five star linked data is just the precondition to what we really need: vocabularies. They point out that the original 5 star rating says nothing about vocabularies, but that Linked Data without vocabularies is not useful at all:

    “Just converting a CSV file to a set of RDF triples and linking them to another set of triples does not necessarily make the data more (re)usable to humans or machines.”

    Needless to say, we share this viewpoint!

    I’m not going to steal their thunder and list here all five star categories–you really should read the article (it’s short), but only note that the lowest level is a zero star rating that covers LD with no vocabularies. The five star rating is reserved for vocabularies that are linked to other vocabularies, which is pretty cool, and not easy to accomplish by the original publisher as a soloist.

    These five star ratings are a terrific start to good practices documentation for vocabularies used in LOD, which we’ve had in our minds for some time. Stay tuned.

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

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

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

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

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

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

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

    Diane Hillmann: Nice tagline 🙂

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

    Diane Hillmann: It’s easier that way.

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

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

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

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

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

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

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

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

  • What’s up with this Jane-athon stuff?

    The RDA Development Team started talking about developing training for the ‘new’ RDA, with a focus on the vocabularies, in the fall of 2014. We had some notion of what we didn’t want to do: we didn’t want yet another ‘sage on the stage’ event, we wanted to re-purpose the ‘hackathon’ model from a software focus to data creation (including a major hands-on aspect), and we wanted to demonstrate what RDA looked like (and could do) in a native RDA environment, without reference to MARC.

    This was a tall order. Using RIMMF for the data creation was a no-brainer: the developers had been using the RDA Registry to feed new vocabulary elements into their their software (effectively becoming the RDA Registry’s first client), and were fully committed to FRBR. Deborah Fritz had been training librarians and other on RIMMF for years, gathering feedback and building enthusiasm. It was Deborah who came up with the Jane-athon idea, and the RDA Development group took it and ran with it. Using the Jane Austen theme was a brilliant part of Deborah’s idea. Everybody knows about JA, and the number of spin offs, rip-offs and re-tellings of the novels (in many media formats) made her work a natural for examining why RDA and FRBR make sense.

    One goal stated everywhere in the marketing materials for our first Jane outing was that we wanted people to have fun. All of us have been part of the audience and on the dais for many information sessions, for RDA and other issues, and neither position has ever been much fun, useful as the sessions might have been. The same goes for webinars, which, as they’ve developed in library-land tend to be dry, boring, and completely bereft of human interaction. And there was a lot of fun at that first Jane-athon–I venture to say that 90% of the folks in the room left with smiles and thanks. We got an amazing response to our evaluation survey, and the preponderance of responses were expansive, positive, and clearly designed to help the organizers to do better the next time. The various folks from ALA Publishing who stood at the back and watched the fun were absolutely amazed at the noise, the laughter, and the collaboration in evidence.

    No small part of the success of Jane-athon 1 rested with the team leaders at each table, and the coaches going from table to table helping out with puzzling issues, ensuring that participants were able to create data using RIMMF that could be aggregated for examination later in the day.

    From the beginning we thought of Jane 1 as the first of many. In the first flush of success as participants signed up and enthusiasm built, we talked publicly about making it possible to do local Jane-athons, but we realized that our small group would have difficulty doing smaller events with less expertise on site to the same standard we set at Jane-athon 1. We had to do a better job in thinking through the local expansion and how to ensure that local participants get the same (or similar) value from the experience before responding to requests.

    As a step in that direction CILIP in the UK is planning an Ag-athon on May 22, 2015 which will add much to the collective experience as well as to the data store that began with the first Jane-athon and will be an increasingly important factor as we work through the issues of sharing data.

    The collection and storage of the Jane-athon data was envisioned prior to the first event, and the R-Balls site was designed as a place to store and share RIMMF-based information. Though a valuable step towards shareable RDA data, rballs have their limits. The data itself can be curated by human experts or available with warts, depending on the needs of the user of the data. For the longer term, RIMMF can output RDF statements based on the rball info, and a triple store is in development for experimentation and exploration. There are plans to improve the visualization of this data and demonstrate its use at Jane-athon 2 in San Francisco, which will include more about RDA and linked data, as well as what the created data can be used for, in particular, for new and improved services.

    So, what are the implications of the first Jane-athon’s success for libraries interested in linked data? One of the biggest misunderstandings floating around libraryland in linked data conversations is that it’s necessary to make one and only one choice of format, and eschew all others (kind of like saying that everyone has to speak English to participate in LOD). This is not just incorrect, it’s also dangerous. In the MARC era, there was truly no choice for libraries–to participate in record sharing they had to use MARC. But the technology has changed, and rapidly evolving semantic mapping strategies [see: http://dcpapers.dublincore.org/pubs/article/view/3622] will enable libraries to use the most appropriate schemas and tools for creating data to be used in their local context, and others for distributing that data to partners, collaborators, or the larger world.

    Another widely circulated meme is that RDA/FRBR is ‘too complicated’ for what libraries need; we’re encouraged to ‘simplify, simplify’ and assured that we’ll still be able to do what we need. Hmm, well, simplification is an attractive idea, until one remembers that the environment we work in, with evolving carriers, versions, and creative ideas for marketing materials to libraries is getting more complex than ever. Without the specificity to describe what we have (or have access to), we push the problem out to our users to figure out on their own. Libraries have always tried to be smarter than that, and that requires “smart” , not “dumb”, metadata.

    Of course the corollary to the ‘too complicated’ argument lies the notion that a) we’re not smart enough to figure out how to do RDA and FRBR right, and b) complex means more expensive. I refuse to give space to a), but b) is an important consideration. I urge you to take a look at the Jane-athon data and consider the fact that Jane Austen wrote very few novels, but they’ve been re-published with various editions, versions and commentaries for almost two centuries. Once you add the ‘based on’, ‘inspired by’ and the enormous trail created by those trying to use Jane’s popularity to sell stuff (“Sense and Sensibility and Sea Monsters” is a favorite of mine), you can see the problem. Think of a pyramid with a very expansive base, and a very sharp point, and consider that the works that everything at the bottom wants to link to don’t require repeating the description of each novel every time in RDA. And we’re not adding notes to descriptions that are based on the outdated notion that the only use for information about the relationship between “Sense and Sensibility and Sea Monsters” and Jane’s “Sense and Sensibility” is a human being who looks far enough into the description to read the note.

    One of the big revelations for most Jane-athon participants was to see how well RIMMF translated legacy MARC records into RDA, with links between the WEM levels and others to the named agents in the record. It’s very slick, and most importantly, not lossy. Consider that RIMMF also outputs in both MARC and RDF–and you see something of a missing link (if not the Golden Gate Bridge :-).

    Not to say there aren’t issues to be considered with RDA as with other options. There are certainly those, and they’ll be discussed at the Jane-In in San Francisco as well as at the RDA Forum on the following day, which will focus on current RDA upgrades and the future of RDA and cataloging. (More detailed information on the Forum will be available shortly).

    Don’t miss the fun, take a look at the details and then go ahead and register. And catalogers, try your best to entice your developers to come too. We’ll set up a table for them, and you’ll improve the conversation level at home considerably!