Richard, et al, I first apologize if this sounds arrogant or obnoxious. I wanted to explain my issues in a way in which others may be facing the same thing and did not want or could not find a way to get their $.02 in.
I thought I would write something a little more lucid instead of rambling of the problem and see if that would assist in background/reasoning/wants. When browsing an index, such as subject, one expects some type of consistency. In DSpace, for example, there is a DC field element named "subject". It may be qualified further by the type of subject. The default DC fields included in DSpace are all associated with some type of thesaurus/controlled vocabulary or some type of national/international classification system. When one includes the "subject" without any qualifier, DSpace displays this as "keywords" in the simple display. The user assumes these are just keywords, with no association with a controlled vocabulary or association with the term "subject". The staff people inputting the metadata are extracting "keywords" from the documents themselves, and not checking any type of thesauri. In our experience here at YSU, we have three types of items being input into DSpace: Digital items that are already represented by our Library's OPAC--in this case a converted record from MARC21 to qDC; New items--staff using LCSH or ATT as the source for subject headings (i.e., they are contentiously inputting controlled headings; or, New items--staff using "key words" from the document itself. Now to browseability. It is the traditional sense of browsing an index in libraries means there will be some type of control. Whether it be author, title or subject, there may be cross references (search also under, search under, etc), or at least consistency. Libraries have spent a considerable amount of resources over the past 40 years in the automation of authority control. And in some libraries where more than one type of thesaurus is used (LCSH, MeSH, ATT) there are separate browse indexes for the subjects; in some cases a general browse index that mixes them altogether in addition to the separate indexes for each thesauri. In DSpace, while separate browse indexes for each subject would be the ultimate in desirability, I think the first step is to make the browse-ability limited to what each DSpace installation thinks should be in the browse index. For Authors, Subject, and Date fields, again this need to be true, especially if one is to use other Metadata Schemas like MODS, METS, EAD, VRA, etc. Adding the ability to list each schema, element, qualifier, would greatly enhance the search results to the user, and make the metadata more rich for the person storing there data. Separate browses for subjects is for a more mature DSpace version down the road. The enhancement of having a subject browse in 1.4 is a great enhancement already. I am thankful for this. Cordially, Jeffrey A. Trimble Systems Librarian Youngstown State University Youngstown, OH [EMAIL PROTECTED] (330) 941-2483 http://digital.maag.ysu.edu http://www.maag.ysu.edu http://jupiter.ysu.edu ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
