On a different note and more details:
Quoting James Weinheimer <weinheimer.ji...@gmail.com>:
What the date in the 240 is supposed to represent, although it is
highly inconsistent in practice, is to break a conflict with another
uniform title (i.e. 1xx/240 combination). They do this mostly with a
publication date (unfortunately),
Same as with authority-controlled names, right?
and I would prefer something more meaningful, e.g. the name of the
translator, and if necessary, edition statement, or something more
meaningful than a publication date.
ditto something more meaningful than date of birth.
http://kcoyle.blogspot.com/2007/09/name-authority-control-aka-name.html
But the rule is that mostly, you use the publication date of
the first manifestation of the "expression". (I can't find the rule
for this right now, since I don't have access to a lot) The only
example I can find right now is King Kong:
http://lccn.loc.gov/90715189, where if you look at the related
titles, you will see 1933, while the date of publication of this
item is 1984. "King Kong (Motion picture : 1933)"
Aha! Thanks. Although... isn't this an even more arcane bit of data
than the first date of the work? And many (including you) were
doubtful that catalogers could supply that.
In general I am having a hard time understanding how we will treat
these kinds of composite headings in any future data carrier. They
seem to be somewhat idiosyncratic, in that what data gets added is up
to the cataloger, depends on the context, and probably cannot be
generated algorithmically. This whole part about headings (access
points in RDA, I believe) has me rather stumped from a design point of
view. At the same time, if all of the individual elements are
available, and one links manifestations of a single expression, then
some system feature may be able to display this distinction to the
user without the use of individual cataloger-formed headings. This
would also mean that the records can be created without being
dependent on a particular context, which should make sharing of data
even more accurate.
kc
It has to be qualified somehow and I guess this is better than King
Kong (Motion picture : Fay Wray screaming) although this would have
much more meaning to people.
My next podcast will deal with some of these distinctions in a funny
way (I hope!). It should come out very soon, so watch for it!
Ciao,
Jim
On 03/08/2011 19:07, Karen Coyle wrote:
Quoting James Weinheimer <weinheimer.ji...@gmail.com>:
While there is an undoubted loss in semantics, with the future
evolution of MARC format, we can ask: do such losses have any
practical consequences? Although I think many subfields (although
not the information) could disappear without any essential loss,
some will have important consequences to different communities.
Jim, this is much of the motivation for the work that I have been
doing to try to identify the actual "elements" of MARC21 --
elements in the semantic sense, trying to ignore the MARC21
structure (which results in much repetition, etc.) A report on my
study is available in the recent Code4Lib journal:
http://journal.code4lib.org/articles/5468
One of the difficulties of deciding what we do and do not want to
keep in MARC, or what we want to move over to the RDA environment,
is that we have no dictionary of everything that MARC covers. For
example, what standard identifiers are available in MARC? They are
scattered all over the format, so it's hard to know. What about
things like language and date? Those appear in different fields
with somewhat different meanings.
My assumption is that a complete inventory of MARC elements is
essential for any move away from MARC. Unfortunately, I have gotten
now to the 1xx-8xx fields (the study so far is 00x and 0xx, that's
already pretty complex!) and may not have the energy to complete
the study on my own. However, what I have done so far at least sets
down some possible principles to follow.
I'm doing it all on the futurelib wiki so my process is as
transparent as I can make it:
http://futurelib.pbworks.com/w/page/29114548/MARC%20elements
kc
--
James Weinheimer weinheimer.ji...@gmail.com
First Thus: http://catalogingmatters.blogspot.com/
Cooperative Cataloging Rules:
http://sites.google.com/site/opencatalogingrules/
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
