Libray of Congress/LC Subject Headings

I am disappointed by the way Zotero handles LC Subject Headings. Is it by design that it breaks them into their component terms? This loses a lot of valuable information. Please consider that there is a big difference between, for example, "Medicine --Europe --Philosophy --History --16th century" as a linked phrase, and a disjointed list of its parts in no particular order. Jumbled tags won't much help you find similar books in a real library, at least not without going back and looking the first book up all over again. Why punch holes in this standardized and very well-thought out system? I think it's a serious flaw. Does it concern anyone else? Can't it at least be instructed to import the whole keyphrase, as well as its pieces?

Thank you
  • I think having tags like "Medicine --Europe --Philosophy --History --16th century" would be exceedingly awkward in the current UI.

    OTOH, I would like to see Zotero in general towards integrating linked data, which would include lcsh subject heading uris.

    But I'm not sure how they would integrate this into what is now just simple string-based tagging system.
  • I don't have any opinion on that, but just out of curiosity:
    Why is
    ""Medicine --Europe --Philosophy --History --16th century""
    different than the individual keywords?
    I get the same search results (not that many...) if I search LOC for them in any given order.
    Once again - I'm not saying this isn't maybe super important, just curious to understand.
  • MG6
    edited July 31, 2009
    It's not awkward at all: all of my 1700 records from Endnote imported that way and it looks fine. It loses the "--", but that's trivial, and perhaps what you object to.

    The reason it's important is that the LC keywords are *hierarchical.* The history of the philosophy of medicine is distinct from general philosophy or history, or the philosophy of medicine, or the history of medicine, I think we could all agree. "History" can mean have many distinct meanings, between the different disciplines.

    It would be cool if a librarian would chime in. It seems to me that MARC records record this hierarchy for a good reason.
  • But a tag system is not hierarchical.
  • then maybe a tag system isn't appropriate.
  • in any case, this information is valuable to me, and obviously others. it's not right to just drop it entirely out of belief in the power of tagging.
  • let me conclude by saying that there are literally centuries of practice behind these systems. they have endured this long for a reason.
  • My point in saying that tagging isn't hierarchical is to suggest that it makes no sense at all to try to integrate a hierarchical system into one that is not. They are two fundamentally different ways of organizing information.

    I'm not a tagging zealot; I think they have obvious and definite limits. But I also tire of the position that only overblown library traditions are adequate to information management in the 21st century.

    As I said above, though, my preference would be a separate system that integrated URIs as subjects. That would allow people to link to LCSH or other hierarchical subjects, wikipedia concepts, etc.
  • I think some might tire of the suggestion that the old ways are wrong and "overblown," and should be abandoned. They have uses you might, to some, appear unwilling to acknowledge or understand. I think a method of importing the information into a note, at the very least, would be an acceptable compromise. I think turning the strings into tags which, if unattractive in their length, mimic the LC headings is another. It doesn't need to be an either-or, I think?
  • At least until the rest of the physical world adopts your forward-looking ideas on information management, those of us who research in libraries are stuck with what you find obsolete.
  • edited July 31, 2009
    gee, no need for sniping.
    I think there is two different issues here:
    1. I think it makes very little sense to import the entire LOC subject headings as tags. Because that would mean that if you look for
    "Medicine --Europe --Philosophy --History --16th century"
    You don' t get
    "Medicine --Europe --Philosophy --History --17th century"
    So for the purpose of dealing with tags, it seems certainly appropriate to cut them into pieces.
    I would be quite upset if I got those clunky tags in Zotero.

    2. However, they do contain other information (that cannot be, in any useful way, handled with tags) and so it might indeed be worth considering to import them, as MG6 suggests, as a note.

    As for "modernity" vs. "tradition" - I am less upset by tradition than Bruce, but I do think that some parts of academic work really haven't come to grips with information technology and I think "it's been used for a long time" in itself is no argument whatsoever, since the availability of computerized catalogues do change a _lot_.
    Now, that's not weighing in on the debate itself - it's just pointing out that emphasizing how long something has been done is no argument at all
    - as an academic immigrant I never cease to be amused, e.g., by my US friends who continue to insist in putting two spaces behind a period - another one of those practices that used to make sense but are a bit ridiculous since modern word processors came about...
    (and I do think hierarchical titles are a lot less important - though arguably not obsolete - now that you can just do a boolean keyword search and get all relevant results for the joint set of 6 keywords).
  • I am trying very hard not to be snipey, I assure you. I'm sorry if I appeared so. I don't think it helps. Far from being sarcastic, I was trying to make a sincere argument: an academic often needs to go from one's notes to an actual, brick and mortar library, and it would be very convenient to have these headings at hand. The old ways aren't going anywhere, I promise you. There are a lot of "old-fashioned" libraries that haven't put all of their holdings into digital catalogs, and very likely never will: it's not cost-effective, when only a handfull of people access the materials. There are also some libraries and archives that don't have any computer catalogs at all. I recognize that is perhaps hard to believe, but it's a fact. Please try to keep this in mind? It's a fabulous thing you're doing, but I do often get the feeling that not everyone keeps the big, messy world in mind. Zotero has to be flexible enough to adapt to reality, since reality can't be made to adapt to it.
  • I think adamsmith's assessment is correct. There are two separate and not particularly related issues here, and the current tag behavior is as it should be. For MG6's primary use case, the LOC subject headings appear to be essentially call numbers. Call number functionality in Zotero is currently rather limited, and it might make sense to combine call numbers with other identifiers such as PubMed ID or ISBN in a UI similar to creator editing that allowed you to enter as many as you wanted (as has been discussed elsewhere). LOC Subject Heading could be one of the available identifiers, and translators could populate that field automatically in addition to saving individual tags. Ideally, of course, an identifier system would be extensible, as Bruce suggests.
  • Dan: they're not call numbers or identifiers. They're subject headings that look like plain text, but are hierarchically structured data, with the levels delimited using the "--".

    See Karen Coyle's post (and related commented) on the new LOC linked data representation of this to get a sense.
  • I understand what they are, but if 1) we're not going to implement hierarchical tags, 2) there's not a great other place to put the data, and 3) MG6's main concern in this request appears to be going to a physical library and finding resources based on the subject headings stored with the Zotero item, then putting them in an id/call number field, where at least they'd be identified as LOC data, seems like a possibility. The other option proposed so far in this thread is putting them in a note, which is easily worse.

    An extensible mechanism for external identifiers and what you're suggesting also aren't necessarily different things. Many of the external identifiers people would want will have associated URIs.

    For what it's worth, Zotero 2.0 has the (rudimentary) beginnings of more advanced relation support—i.e., there's a DB table with subject, predicate, and object columns. It's currently used only to track links between library and group items, but the idea is for it to eventually be used to associate Zotero items with external resources.
  • Thanks for thinking this through. Would we hopefully have room for normal call numbers, too? I really like that idea about having as many as you want (for different libraries). I'd love it if both the call number for the record you're looking at and the LC stuff both imported automatically. Of course we'd be on our own for anything more than that.

    The field delimiter looks like a "--" on the typical page for patrons, but in the MARC data, I believe there are alphabetic tabs separating each level.

  • For what it's worth, Zotero 2.0 has the (rudimentary) beginnings of more advanced relation support—i.e., there's a DB table with subject, predicate, and object columns. It's currently used only to track links between library and group items, but the idea is for it to eventually be used to associate Zotero items with external resources.
    How do you deal with the fact that, at least in RDF, an object may be a string or a URI?
  • How do you deal with the fact that, at least in RDF, an object may be a string or a URI?
    I suspect we could just store either and determine it programmatically, but whether we need to depends on how this ends up being used. This table alone wouldn't suffice for things like custom field support. In what other applicable cases would strings be used for objects?

    At the moment the only thing stored is a URI for one item, "owl:sameAs", and a URI for another item.
  • To follow up on Dan's (admittedly old) comment here, is there any work being done to create a separate field for LOC subject headings? That does seem like the most feasible way of integrating this helpful data into zotero. It would be great to have available!
  • The multiple call numbers field as mentioned would be quite nice as well. I often have multiple LOC-system call numbers, and not rarely do I have Russian-style call numbers as well. Is there room for making this a multiple entries field like creators?
  • If we did that, translators like MARC/Alpha could usefully also pay attention to the "local call number" field. That way I'd get my own librariy's (Dewey) number alongside the LoC number when I import.
Sign In or Register to comment.