I still maintain that it's not the format that makes the difference,
it's the content. As I said in my ALA talk in 2000:
"If your content is good, if it is consistent, you have what you need
to feed different record formats or different systems. If your content
is not based on standards and if your coding of the content is
irregular, no record format can save you."
http://www.kcoyle.net/marcdead/marcdead.html
I agree that a record format can be insufficient to support well-coded
content, but I really think we need to start with the content question
and let the record format follow. Dublin Core and ONIX both have some
serious content issues even though they are serious metadata standards.
I don't know if the same problems have been evidenced in the METS-using
community.
kc
On Thu, 2004-01-29 at 04:28, Bernhard Eversberg wrote:
> Roy Tennant has revised his last year's death sentence for MARC. It may now,
> writes he in LJ January 1004, die quietly of old age.
> http://www.libraryjournal.com/article/CA371079
>
> But of course, something must be done to open the secretive MARC world up. What
> Tennant envisions is, however, rather daunting. He is airing LC's METS schema as
> a concept to store multi-format data within one container.
>
> Something like this will, IMHO, not be invading local systems. METS is meant as a
> *Transfer Syntax*, not as an internal database schema (the same was true for MARC
> when it was first designed). Think of updating complexities! What's needed is
> import and export facilities that can ingest and generate, for example, ONIX data
> or METS-wrapped stuff or XML tagged data in general. As long as a system can
> ingest and generate everything that comes along or is asked for, its internal
> structure is nobody else's business. Be it MARC or whatever.
> In principle, all that's needed for a local system is the capability to ingest
> and generate MARC - which all of them are already doing - AND a conversion
> software that can switch between MARC and everything else. This intermediary
> converter tool would (ideally) be completely independent of local systems and
> thus be universally applicable. Not a very new idea though.
>
> Regards, B.E.
>
>
> Bernhard Eversberg
> Universitaetsbibliothek, Postf. 3329,
> D-38023 Braunschweig, Germany
> Tel. +49 531 391-5026 , -5011 , FAX -5836
> e-mail [log in to unmask]
--
-------------------------------------
Karen Coyle
Digital Library Specialist
http://www.kcoyle.net
Ph: 510-540-7596 Fax: 510-848-3913
--------------------------------------
