, February 03, 2010 4:56 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Systems v Cataloging was: RDA and granularity
Ah, but MARC already IS an exchange format, isn't it? Isn't that what
we claim it is? Well, I'm kind of being unfair, because we all know
it's no longer just that. What
Weinheimer Jim schrieb:
As Tim Berners-Lee said in that wonderful interview that we
discussed on one of these lists several months back, to
enter this new world, all you have to do is put your data
out in a format that is usable for others (e.g. not in
a pdf file) and let others know about
Bernhard Eversberg wrote:
snip
But we can do that without giving up internal use of MARC.
We need never expose MARC to anybody out there, all we need
is useful exports and services. And these can be changed any time
without changing internal formats. But first of all, as we
noted yesterday, right
Weinheimer Jim wrote:
Yes, we need what is called an Exchange Format, ...
Look at WorldCat, they already offer exports (citations) in
formats suitable for ReferenceManager or EndNote:
TY - CONF
DB - /z-wcorg/
DP - http://worldcat.org
ID - 148699707
LA - English
T1 - The maritime world
Bernhard Eversberg wrote:
snip.
Look at WorldCat, they already offer exports (citations) in
formats suitable for ReferenceManager or EndNote:
TY - CONF
DB - /z-wcorg/
DP - http://worldcat.org
ID - 148699707
LA - English
T1 - The maritime world of ancient Rome : proceedings of The Maritime
Weinheimer Jim schrieb:
Who knows what some clever people in India or South Africa could do with our
records?
Well, I should have added that virtually all ILS's *do* already have
exports in human-readable form: What else are their OPAC title displays?
Mostly they are labeled these days, very
Ah, but MARC already IS an exchange format, isn't it? Isn't that what
we claim it is? Well, I'm kind of being unfair, because we all know
it's no longer just that. What I've been suggesting for a while is that
MARC has in fact become our technical element vocabulary. (By
vocabulary here I do
Daniel CannCasciato wrote:
snip
Karen Coyle wrote in part:
all of the needs are user needs . . .
Brava!
/snip
Pardons, but this is not correct. If we are to manage the collection (whatever
the collection happens to be), we will need tools, and some of these tools
will be designed for
Bernhard Eversberg wrote:
snip
Some metadata creators are inclined to follow no rules except
their own, not disclosing what these are.
But OK, we should not be pointing fingers at them but try very
hard to make sense of everything they might come up with,
creating a grand mashup (resisted to write
Daniel CannCasciato wrote:
snip
Karen Coyle wrote in part:
all of the needs are user needs . . .
Brava!
/snip
Jim Weinheimer replied:
Pardons, but this is not correct. If we are to manage the collection
(whatever the collection happens to be), we will need tools, and some
of these tools will
Of Bernhard Eversberg
[...@biblio.tu-bs.de]
Sent: Tuesday, February 02, 2010 5:13 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Systems v Cataloging was: RDA and granularity
Weinheimer Jim wrote:
Again, I think these are the directions we should take instead of coming up
with yet another
and Access
[rd...@listserv.lac-bac.gc.ca] On Behalf Of Bernhard Eversberg
[...@biblio.tu-bs.de]
Sent: Tuesday, February 02, 2010 10:01 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Systems v Cataloging was: RDA and granularity
Jonathan Rochkind wrote:
Well, if you ask Google, they'd say
Jonathan Rochkind quoting some Google Books person wrote:
the first thing we discovered was that the 'machine readable' part of the MARC
acronym was not so much so.
A few thousand library systems out there to the contrary?
Jonathan Rochkind then wrote in part:
Part of making this sort of
Daniel CannCasciato wrote:
Jonathan Rochkind quoting some Google Books person wrote:
the first thing we discovered was that the 'machine readable' part of the MARC acronym was not so much so.
A few thousand library systems out there to the contrary?
I don't have the energy to have this
Bernhard said:
Dumb down RDA and MARC so we have only one element for keyword indexable
text, and a few indispensable codes and dates.
The ISBD has more that one element, but it would satisfy that need quite
handily.
An ISBD manual with MARC21 examples would meet our needs far better
than the
@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Systems v Cataloging was: RDA and granularity
I think perhaps this makes more sense if you understand that what is
meant by machine readable is more like machine interpretable or
machine comprehensible. Certainly, machines can read and index a MARC
record in an ILS
Melodie Frances asked:
Can anyone explain WHY it's so hard to get info from MARC?
Amen sister.
Most of our Revelation programs still work just fine thank you.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___}
Melodie Frances asked:
Can anyone explain WHY it's so hard to get info from MARC?
We need not expose MARC to anyone who doesn't want/like/understand it.
What we need are good services and tools that can access MARC but send
out flavors of DC in XML or whatever just as well as plain old ISBD.
For
I appreciate John Myers example. This conversation has itself been
lacking in granularity. But one of the things it points out is that
we're not necessarily talking about MARC. The spotty use of uniform
titles for translations is a result of cataloging policy decisions, not
a limit imposed by
Quoting Frances, Melodie mfran...@gtu.edu:
Can anyone explain WHY it's so hard to get info from MARC?
Because it's a format contemporary programmers mostly don't
understand? And nobody else but libraries uses that kind of format?
Much of the coding has a semantic value -- 100 is like
Message-
From: Resource Description and Access / Resource Description and Access
[mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of McGrath, Kelley C.
Sent: Tuesday, February 02, 2010 8:37 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Systems v Cataloging was: RDA and granularity
I think
Jonathan Rochkind said:
The one way to sum up the larger general issue is that MARC has
effectively become our 'element vocabulary', but one documented as a
'transmission format' instead, not originally designed to fill the
'element vocabulary' function it has come to fill, and not adequate
Kevin:
I think you've definitely got it. :-)
Consider the question that always comes up about our legacy data--what
will we do with it if MARC becomes just one of any number of formats
we might exchange? What if we could consider possibilities like mapping
on the fly from MARC to RDA? Or
No Mac, the vocabularies don't assume anything of the kind. If you
check out some of the work we've done with the Deutsche
Nationalbibliothek (in the Content Type and Media Type vocabularies at:
http://metadataregistry.org/vocabulary/show/id/45.html and
Diane I. Hillmann wrote:
No Mac, the vocabularies don't assume anything of the kind. If you
check out some of the work we've done with the Deutsche
Nationalbibliothek (in the Content Type and Media Type vocabularies at:
http://metadataregistry.org/vocabulary/show/id/45.html and
I am going to suggest that we can not take the position that systems
and cataloging have different needs, or even that they are different
activities. This is a mistaken idea that arose from the unique
situation of MARC vis-a-vis AACR, which was itself an historical
accident. When computers
Karen,
I'm not going to disagree with you, but I will confess some confusion
about what you are saying, since my impression of one of the purposes of
RDA was to extract it as a content-only standard from the muddle in
AACR2 which itself inherits the mixed content/carrier/display framework
of
Not monolithic, but broken into logical components. The element
vocabulary is a logical component that needs to exist, and can then be
used by multiple choices of record formats and multiple choices of how
to display things or what to do with them. The existence of a coherent
element
What Jonathan said.
kc
Quoting Jonathan Rochkind rochk...@jhu.edu:
Not monolithic, but broken into logical components. The element
vocabulary is a logical component that needs to exist, and can then be
used by multiple choices of record formats and multiple choices of how
to display things or
At 10:45 AM 2/1/2010, Jonathan Rochkind wrote:
Not monolithic, but broken into logical components. The element
vocabulary is a logical component that needs to exist, and can then
be used by multiple choices of record formats and multiple choices
of how to display things or what to do with
Quoting John Attig jx...@psu.edu:
At 10:45 AM 2/1/2010, Jonathan Rochkind wrote:
So what we have been discussing is the coherence of the RDA and MARC
element vocabularies. Do you have a functional definition of what
makes an element vocabulary coherent?
First, I need to say that I am not
Underlying Karen's various points is the basic reality that while
computers are very good for certain things (collating and presenting
large amounts of data) they are hopeless at understanding the nuances
of human languages and so if we're going to bother investing in
human-authored catalog
Karen Coyle wrote in part:
all of the needs are user needs . . .
Brava!
Catalogers have
to understand how today's catalog works, just as they have always had
to understand the technology for which they were creating data, going
back to book catalogs and then card catalogs.
33 matches
Mail list logo
