[metadataLibrarians] DC subject.other
Thomale, J
j.thomale at ttu.edu
Tue Mar 28 07:15:05 PST 2006
Jane,
Refinements for "subject" are not standard Dublin Core, so there is
quite probably not a right way (or even a "recommended" way) to do it.
DSpace uses subject element refinements to delineate various encoding
schemes--most of which (LCSH, MESH, DDC, LCC, and UDC) *are* specified
in the DC Library Application Profile. DSpace does it the way it does,
of course, because it stores its metadata in a flat database table
rather than in XML (and thus cannot use attributes to describe
elements).
Although "other" is not an encoding scheme specified in DC-Lib, the
DSpace documentation says to use it for storing terms that come from a
local controlled vocabulary. On the other hand, "subject" without any
qualifications stores uncontrolled subject terms.
Although there is probably not a controlled vocabulary per se for your
birth-death-marriage entries, it sounds like you have--or are working
toward--your own standard way of encoding them. Thus, since they do have
some modicum of "control" exercised over them, then subject.other is
probably "okay" from that perspective.
But I would say that the way you're encoding the terms is definitely not
standard--using repetitions of the same element to store different data
is usually not the best way to do it, unless you put some sort of label
in the data itself. For instance, this:
subject.other = 1932
subject.other = 1995
subject.other = 1951
makes it hard to differentiate between the different dates. Although I
suppose you could presume that the earliest date is the birth, the next
is the marriage, and the latest is the death, if you have only two
dates, you couldn't determine whether the later date is marriage or
death.
To rectify this, you could do:
subject.other = b 1932
subject.other = d 1995
subject.other = m 1951
or something similar. However, for the sake of consistency, when all
pieces of data belong to one term or entry, it's better to put it
together in a single field:
subject.other = 1932, 1995, 1951
When you have only one or two dates, then, location within the above
list would determine what kind of date each one is:
subject.other = 1932, 1995,
or
subject.other = 1932, , 1951
It really depends on how you want the field to be indexed and searched,
how you want the entry to be displayed, and what kind of pre-processing
your system can do on the data before it's indexed, searched, and/or
displayed. At my institution we've been testing/experimenting with
DSpace, but I have no real hands-on experience with it yet, so I'm sure
you know better than I do what you can do with it in that regard.
So--with all of that said, my final thoughts are:
Storing birth-death-marriage information is definitely not standard for
DC or for DSpace, and is probably something that is relatively unique to
your metadata. Of the default DSpace metadata elements, it seems like
subject.other is the best place to store it (unless you have the
knowledge and ability to customize the DSpace metadata registry, in
which case you could create your own custom element). If you've found a
way to encode the data that works well for your collection and supports
the functionality that you require, then great. Standardize on that
format. Document it. Try to normalize the metadata so that all
birth-death-marriage entries are in that format. Make sure that the
people entering metadata know how to properly encode those entries. That
way, you've got your bases covered--if/when you need to export the
metadata in a different schema, you'll have the knowledge and the data
integrity to map it reliably. If someone else needs to work with your
data, you'll have it documented so that they know what it is and what it
means.
Does that help?
Jason Thomale
Metadata Librarian
Texas Tech University Libraries
> -----Original Message-----
> From: metadatalibrarians-bounces at lists.monarchos.com
> [mailto:metadatalibrarians-bounces at lists.monarchos.com] On
> Behalf Of Jane Kelsey
> Sent: Monday, March 27, 2006 4:13 PM
> To: metadatalibrarians at lists.monarchos.com;
> metadatalibrarians-request at lists.monarchos.com
> Subject: [metadataLibrarians] DC subject.other
>
> Greetings:
>
> My project partner and I have a question on entry form for DC
> subject.other
>
> What is the best way to use this field. We have used it with:
> birth-death-marriage as an entry.
>
> We have also used it as a repeating field with birth in the
> first field, death in the second field and so on.
>
> Is the correct way dependent upon our software as to the best format?
>
> We are using DSpace.
>
> We have written a best practices guide, but are finding
> inconsistencies and working to resolve them. We are finding
> it a bit challenging today.
>
> Thanks in advance for any guidance.
>
> Jane Kelsey
> Government Documents Librarian
> Kansas State Historical Society
> 6425 SW. 6th Ave.
> Topeka, KS 66615-1099
> 785-272-8681 ext. 308
> JKelsey at kshs.org
>
> _______________________________________________
> metadatalibrarians mailing list
> metadatalibrarians at lists.monarchos.com
> http://lists.monarchos.com/listinfo.cgi/metadatalibrarians-mon
archos.com
>
>
More information about the metadatalibrarians
mailing list