According to the MADS/RDF Vocabulary Description, the MODS listserv is the appropriate place for discussion of MADS/RDF. I assume that a perspective on MARC authorities is relevant.
Here's the MARC Authorities 375 field for documenting gender:
http://www.loc.gov/marc/authority/concise/ad375.html
Additional info is here:
http://www.loc.gov/standards/sourcelist/gender.html
The codes used are ISO/IEC 5218:2004, which (according to Wikipedia at least) defines these codes:
* 0 = not known,
* 1 = male,
* 2 = female,
* 9 = not applicable.
These haven't been published as Linked Data yet, but we can hope they will eventually. I assume the lack of a 375 field is equivalent to 0.
In UNIMARC authorities, the gender is encoded in the 120 $a character 0 and includes these possibilities:
a = Female (the entity in 200 is female.)
b = Male (the entity in 200 is male.)
c = Transgender (the entity in 200 has changed gender)
u = Unknown (i.e. the gender of the entity cannot be determined)
x = Not applicable (the entity in 200 does not have a gender )
In the case of George Eliot, I could believe either unknown or N/A.
Jeff
> -----Original Message-----
> From: Metadata Object Description Schema List
> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
> Sent: Tuesday, January 18, 2011 3:39 PM
> To: [log in to unmask]
> Subject: Re: [MODS] MADS/RDF for review
>
> Quoting "Young,Jeff (OR)" <[log in to unmask]>:
>
> > The birth and death dates in VIAF are all coming from authority
> > records. These are currently being parsed from headings, but also
> > pulling them from dedicated fields is on the TODO list. The "main
> > purpose" of putting this information into authority data seem
> > irrelevant.
>
>
> It may not be relevant from a purely computing standpoint, but for
> creation and interpretation I usually consider purpose to be a carrier
> of some of the meaning of the metadata. It definitely helps those
> creating the data to make decisions, and for the users who understand
> what the data is supposed to convey, it gives them some semantics for
> understand what they are seeing.
>
> Thom's data points out one of the difficulties of the MARC record,
> where the same piece of data is in both a coded and a textual form. As
> we know, every time you key the same data twice in a single record,
> you introduce a possibility of conflict. Since catalogers can't see
> the coded data well, I can imagine that it's easy to make errors.
>
> But, now we're talking about MARC on the mODS list, and that makes us
> truly off topic. :-) My bad, since I got us onto the date thing. Sorry.
>
> kc
>
> kc
>
> >
> > Jeff
> >
> >> -----Original Message-----
> >> From: Metadata Object Description Schema List
> >> [mailto:[log in to unmask]] On Behalf Of Beall, Jeffrey
> >> Sent: Tuesday, January 18, 2011 2:33 PM
> >> To: [log in to unmask]
> >> Subject: Re: [MODS] MADS/RDF for review
> >>
> >> Rebecca:
> >>
> >> Our NACO trainer said that adding the dates when establishing a
> heading
> >> was done to help break a possible future conflict. So, I still think
> >> the main purpose of dates in personal name headings is for
> >> disambiguation, whether current or future. What other purpose could
> the
> >> dates serve? Providing biographical information? That's not the
> purpose
> >> of the authority records, though.
> >>
> >> Now with authority files being merged into services such as VIAF,
> birth
> >> and death date metadata has become more valuable because of its
> >> disambiguation value.
> >>
> >>
> >> Jeffrey Beall, Metadata Librarian / Assistant Professor
> >> Auraria Library
> >> University of Colorado Denver
> >> 1100 Lawrence St.
> >> Denver, Colo. 80204 USA
> >> (303) 556-5936
> >> [log in to unmask]
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Metadata Object Description Schema List
> >> [mailto:[log in to unmask]] On Behalf Of Guenther, Rebecca
> >> Sent: Tuesday, January 18, 2011 8:06 AM
> >> To: [log in to unmask]
> >> Subject: Re: [MODS] MADS/RDF for review
> >>
> >> It is not correct that dates are only added to distinguish between
> >> similar names. It has long been LC policy that birth dates are added
> if
> >> readily available when establishing a name (and death dates when
> >> available), NOT just to break a conflict. Which means that a large
> >> number of name headings have birth dates. Institutions participating
> in
> >> the cooperative programs (NACO/PCC) are required to do this.
> >>
> >> We added field 046 in the MARC authority format last year as part of
> >> the changes for RDA. It is a general field for structured dates
> which
> >> has been available in the bibliographic format for some time (and
> new
> >> types of dates were also added there years ago). It is already being
> >> used in records coming through as part of the RDA test-- in fact I'm
> >> told that there are thousands of records with 046 fields containing
> >> birth/death dates for people. And of course it doesn't have to be
> >> limited to records prepared according to RDA but is there to be used
> >> for any records.
> >>
> >> Rebecca
> >>
> >> -----Original Message-----
> >> From: Metadata Object Description Schema List
> >> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
> >> Sent: Sunday, January 16, 2011 12:53 PM
> >> To: [log in to unmask]
> >> Subject: Re: [MODS] MADS/RDF for review
> >>
> >> Quoting "Beall, Jeffrey" <[log in to unmask]>:
> >>
> >> >> Library authority records are very odd beasts, and that oddity
> comes
> >> >> out in FRAD [1]. The record is NOT about the person, per se. It
> does
> >> >> not include information like birth and death dates, where the
> person
> >> >> lives or lived, what they were famous for...
> >> >
> >> > To be precise, many library authority records do contain birth and
> >> > death date information.
> >>
> >> I don't know if you are referring to the year information added to
> name
> >> (Smith, John, 1876-), or to other information in the record. The
> years
> >> may be present in the name heading, but only when needed to
> distinguish
> >> between similar names. This turns out to be confusing to non-
> >> librarians, who wonder why we have the years on some but not all
> names.
> >>
> >> More information will appear in notes for human readers sometimes,
> but
> >> the authority record does not have a field for birth/death dates.
> >> Dates in the notes are not coded as such, so are not equivalent to
> >> actual date information. For example, here is a note from Barbara
> >> Cartland's authority record, in which her death notice is included
> to
> >> back up the addition of "-2000" to her name:
> >>
> >> 670 __ |a Washington post, 22 May 2000: |b obit. (Dame Barbara
> >> Cartland, 98, died May 21, 2000; in London; author of 723 books
> >> published in 36 languages; born Mary Barbara Hamilton Cartland in
> >> Birmingham, England; married Alexander McCorquodale 1927, divorced
> >> 1933; in 1936 married Alexander’s cousin, Hugh McCorquodale; 1991
> Dame
> >> Commander of the British Empire; author of non-fiction as well as
> >> romance novels; step-grandmother of Princess Diana of Wales)
> >>
> >> or in this case, where the note shows that the birth year was taken
> >> from "p. 4 of cover" (not sure what that means...) and gives the
> place
> >> of birth:
> >>
> >> 670 __ |a Cecil Rice, Venice, sunlight and water, 2006: |b p. 4
> of
> >> cover (Zoe Cooper; b. 1963 in Leamington Spa, England)
> >>
> >> While the notes MAY have some birth/death information, it's not a
> >> machine-usable form of that data. There is a lot of really good
> >> information in notes, but it's just not coded in a way to be usable
> for
> >> any kind of computation, which is a real shame.
> >>
> >> kc
> >>
> >> >
> >> >
> >> > Jeffrey Beall
> >> > Metadata Librarian / Assistant Professor Auraria Library
> University
> >> of
> >> > Colorado Denver 1100 Lawrence St.
> >> > Denver, Colorado 80204
> >> > (303) 556-5936
> >> > [log in to unmask]
> >> >
> >> >
> >> >
> >> >
> >>
> >> --
> >> Karen Coyle
> >> [log in to unmask] http://kcoyle.net
> >> ph: 1-510-540-7596
> >> m: 1-510-435-8234
> >> skype: kcoylenet
> >
>
>
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
|