This is perhaps only tangentially RDA-related. But it's Friday and Karen Coyle's latest post sort of inspired me to keep thinking along these lines. I hope they are at least forward-looking enough to merit consideration on this list.
Another advantage that I see to formulating cataloging data as RDF-like triples is that it would enable cataloging agencies to share data more effectively. Currently we can share records or, in some circumstances (such as controlled access points) a few special fields. But we pretty much have to share the whole record, and it is very difficult with records that have been curated by successive institutions to determine who added what, and why. And the extent to which we can automate record comparison and selection is rather limited, in my opinion. But if each "field" in a record was coded as a triple, we would be able to share data on a much more granular level. To take up Karen's example, the statement: Shichinin no samurai -- was directed by -- Akira Kurosawa Could be reified: MIT -- provided an access point to -- Shichinin no samuria: Shinchinin no samurai -- was directed by -- Akira Kurosawa In both of these examples, we should understand the words as tokens for machine-resolvable URIs, so a parser running across these statements would be able to "find out" about each element in the triple, and make some rules-based decisions about how to treat the statement. For example, a library could decide to accept or ignore what MIT has to say about this particular work; or what MIT has to say about access points; or what MIT has to say at all, and their catalog could be configured to ignore or accept that particular statement if it encountered it. Nor would decisions such as these wouldn't have to be made on an institution-by-institution basis: we could have another triple stored on the network: MIT -- participates in -- NACO And the decision could be to accept all "provide access point" predicates IF the subject is "a NACO participant". I think the technology is already there to do something like this, but we have so much institutional inertia (not to mention zillions of MARC records that would need to be converted somehow), I'm not sure if it's likely to happen. But if it was possible to convert MARC data into RDF-like statements, we could move away from what I see as a lot of the unnecessary work of thinking about and comparing *records* instead of thinking about data points. Instead of building and maintaining large stores of records, or trying to perform the Sisyphysian task of making a single standard for the one "best" record in each and every circumstance is, we could focus on building networks of cataloging institutions who have shared needs or interests (similar userbases, collections, etc.) and getting the best (that is, most appropriate to the particular needs of our institutions) data available. Pipe dream? Perhaps, but hopefully some food for thought, Ben ________________________________________ From: Resource Description and Access / Resource Description and Access [[email protected]] On Behalf Of Karen Coyle [[email protected]] Sent: Friday, March 05, 2010 1:42 PM To: [email protected] Subject: Re: [RDA-L] Question about RDA relationships (App. J) Quoting Bernhard Eversberg <[email protected]>: > > About any particular book, there can be many "statements" out in the > open world of the Web. Provided there is a stable, reliable, unique, > universally used identifier, going with every suchj statement, you're > very nearly there. I made the mistake of using a term without identifying it, sorry. In semantic web terms, this is a "statement": Herman Melville -- is author of -- Moby Dick It is a 3-part data construct. The full description of a book will be made up of many statements. The big difference between what we do today and the "recordless" view is that each of these statements is able to be used independently of the context in which it was created. Making up an example (always dangerous), let's say that the Wikipedia article about Melville has the information that he wrote Moby Dick, and a library bibliographic record has him as the author of Moby Dick, and an essay on American literature has the same information. The idea of the semantic web "statement" is that these could all be structured in the same way. That would mean that a query on the web (a semantic query, not a keyword search) could ask: who wrote Moby Dick? and it would come up "Herman Melville, and here's a bunch of places that talk about him as author of that book." While library records today have that same information, it doesn't make sense outside of the record so you can't share it or link to it in other contexts. We have separate fields for the author and the book, and the connection between them is that they are in the same record. But take them out of the record and the connection is lost. In the semantic web view, each statement makes a connection between two things, and you can string the statements together to make a web of statements. (Sorry this is getting pedantic -- I'm trying to make it interesting, really!) Here's the example from my recent Library Technology Report: "Akira Kurosawa was the director of Shichinin no samurai (also known as the Seven Samurai), which was adapted as The Magnificent 7, directed by John Sturges." Shichinin no samurai -- was directed by -- Akira Kurosawa Shichinin no samurai -- has alternate title -- Seven Samurai Shichinin no samurai -- was adapted as -- The Magnificent 7 The Magnificent 7 -- was directed by -- John Sturges In today's record, we would code this somewhat like: 100 $a Kurosawa, Akira $e director 245 $a Shichinin no samurai 246 $a Seven Samurai 500 $a Adapted as "The Magnificent 7" 730 $a Magnificent 7 The information about Sturges would be in the record for Magnificent 7, so the user would have to go to that record to get that information. In the Semantic Web the user could navigate directly to that information because it would be linked due to its structure and identity, just as a hyperlink today takes you to the other document using Web protocols. The key thing here is that you are creating an unending (hopefully!) network of links, not separate records. For us today, without the record around our fields, the meaning of the relationships between the fields don't exist. So if you were to take the 730 out of the record and try to do something with it, you can't -- you have to drag the whole record around with it for it to have meaning, so it isn't very usable. All of that said, the "statement" form can obviously be derived from a record that looks something like what we do today. It becomes much more useful if the relationships are better expressed than we do now: after all the 246 and 730 could mean many different things. Humans reading our records generally figure them out, but for machine processing we will get better results if those relationships are clearer. This is probably a very flawed description of something that is extremely hard to describe. I hope I haven't just made things worse. -- Karen Coyle [email protected] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
