James wrote:
"The upshot of all of this is: I think it is clear that finding the events would be too complex to do through automated means (although automation would certainly help human catalogers to do it). If we could say, "all conferences are now events" (translating this to MARC: all 111s are considered to be all the events) and that would be an end of it, OK, but as I have shown, there is a LOT more than that. This means that much, if not the vast majority of the work will have to be done manually."
Not even all 111s can be considered to be events. Consider entities such as these:
111 2_ ǂa Commonwealth Games ǂn (19th : ǂd 2010 : ǂc Delhi, India). ǂe Organising Committee
111 2_ ǂa Conference for the Reduction and Limitation of Armaments ǂd (1932-1934 : ǂc Geneva, Switzerland). ǂe Political Commission
111 2_ ǂa Olympic Winter Games ǂn (9th : ǂd 1964 : ǂc Innsbruck, Austria). ǂe Organizing Committee
111 2_ ǂa International Printing Machinery and Allied Trades Exhibition ǂn (10th : ǂd 1955 ǂc London, England). ǂe Educational Feature Organizing Committee
111 2_ ǂa XML Prague (Conference). ǂe Organizing Committee
111 2_ ǂa Pennsylvania Governor's Conference on Handicapped Individuals. ǂe Task Force on Sexuality
111 2_ ǂa International Population Conference. ǂe Comité préparatoire belge
Adam Schiff
University of Washington Libraries
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of James Weinheimer <[log in to unmask]>
Sent: Sunday, January 24, 2016 2:17 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] The Future of Linked Data in Libraries: Assessing BIBFRAME Against Best PracticesOn 1/23/2016 7:08 PM, Martynas Jusevičius wrote:
why should events even be in scope of the bibliographical domain? Secondly, MARC is not part of the Linked Data picture. In general, I think the answer can be only as specific as: "it depends". Mostly on usage. If you know that a book is about "United States--History--Civil War, 1861-1865", then the only thing you can state in RDF with certainty is: _:book dct:subject [ dct:title "United States--History--Civil War, 1861-1865" ] . In other words, this book is about something with this title. I've used blank nodes and Dublin Core properties here, but they could also be URIs and properties from a different vocabulary. Now maybe someone else has minted a URI for your subject concept, e.g. DBPedia. Then you can state instead: _:book dct:subject <http://dbpedia.org/resource/American_Civil_War> . If you dereference DBPedia's URI, you will find RDF types such as dbo:Event. At this point your book is explicitly about the US Civil War, in a distributed Linked Data context. Notice that no BIBFRAME specific properties or classes were necessary to state that fact. P.S. URI itself is not "the thing", it only *identifies* "the thing".
Sorry that I didn't explain myself very well. I am used to being on email lists that are populated primarily by catalogers, and I take some things for granted in my posts.
Subjects using LC subject headings are fundamentally different from other thesauri using descriptors. LC subject headings are not descriptors but utilize a different method.
In the example about the US Civil War that you give, I agree with what you say but there is a lot more to it. I'll try to explain it without the MARC format.
In the case of "United States--History--Civil War, 1861-1865" it is made up of multiple semantics--not just multiple pieces of text.
"United States" has two possible semantic interpretations. It can be either an author or geographic entity. In neither interpretation can it be an event.
Then with the "United States. History", the term "United States" can only be a geographic entity and cannot be an event. The "History" part is also not an event--although I can imagine various arguments that "the history of the United States" is an event, but I do not want to discuss that at the moment. So let's leave that possibility aside for now.
Geographic names have *many* possible semantics after names of places. For instance, "United States" (or any geographic area) can have the subdivision "Antiquities" or "Boundaries" or anything found in the list at http://www.loc.gov/aba/publications/FreeSHM/H1140.pdf. I suggest you glance at that list. Some of these *can* be considered as events, e.g. "United States--Census, 1940" or "United States--Economic conditions--18th century" while others are definitely not events, e.g. "United States--Defenses".
Some of these subdivisions (sorry for the cataloging terminology) that are definitely events, e.g. "United States--History--Civil War, 1861-1865" can be further subdivided in all kinds of ways. As I mentioned, "Bibliography" or "Registers of the dead" (using the supplementary list at http://www.loc.gov/aba/publications/FreeSHM/H1200.pdf) neither of which seem to me to be events, but possibly "United States--History--Civil War, 1861-1865--Anniversaries, etc." could be.
The way URIs are considered now in id.loc.gov is that the *entire string* is given a single URI. Therefore, "United States--History--Civil War, 1861-1865--Bibliography" has a single URI http://id.loc.gov/authorities/subjects/sh2007100437.html. In other words, having a single URI mashes together all of the semantics that were separate before.
Could "a bibliography of the US Civil War" be considered an event? I hardly think so. But if not, how do we deal with the single URI above? This shows how LC subject headings are fundamentally different from subject descriptors.
Multiply this for all the wars in all the areas of the world, all the economic events (the Soviet Union's Five Year Plans were events? I think so) plus a withering array of all kinds of other events that I cannot even imagine at the moment.
The upshot of all of this is: I think it is clear that finding the events would be too complex to do through automated means (although automation would certainly help human catalogers to do it). If we could say, "all conferences are now events" (translating this to MARC: all 111s are considered to be all the events) and that would be an end of it, OK, but as I have shown, there is a LOT more than that. This means that much, if not the vast majority of the work will have to be done manually.
It seems worth asking: Is all that worth it? Just so some developer elsewhere can add some of our stuff to his "events app"? If it is not worth it, will we place the blame on the overworked, disappearing catalogers, or on someone/something else?
Or is asking such questions simply too impolite?
James Weinheimer [log in to unmask] First Thus http://blog.jweinheimer.net First Thus Facebook Page https://www.facebook.com/FirstThus Personal Facebook Page https://www.facebook.com/james.weinheimer.35 Google+ https://plus.google.com/u/0/+JamesWeinheimer Cooperative Cataloging Rules http://sites.google.com/site/opencatalogingrules/ Cataloging Matters Podcasts http://blog.jweinheimer.net/cataloging-matters-podcasts The Library Herald http://libnews.jweinheimer.net/