PS: Talking about data elements in terms of MARC codes is a symptom of
using MARC as a data model.
We use MARC as a data model because we don't have a better one. MARC is
a fine encoding/transmission format--or at least is capable of being
used as such. Sure, it's got some weird idiosyncratic archaisms and is
not the way you'd design an encoding/transmission format today, but it
can function as an encoding/transmission/serialization format.
But it's a horrible, unsystematic, irrational, ambiguous all over the
place data model.
We need a real data model. FRBR is the beginning of this--but, yes, it's
not sophisticated enough to replace "MARC as data model". Yet. It needs
to be. Or something else does.
The replacement for talking about data elements in terms of MARC fields
is not MODS or RDF or anything else--it's FRBR. Not 245$a, but
"expression title". If FRBR isn't rich enough to represent what we need
to represent (and it's not), then FRBR needs to be made richer.
Jonathan
Jonathan Rochkind wrote:
> MODS pretty much IS MARC. It's not a "re-invented" MARC, because it
> doesn't hardly re-invent anything.
>
> It turns MARC into XML, gives it XML-style tag names instead of numbers
> and letters, and makes some of the particularly unsystematic and
> irrational parts of MARC more systematic and rational, taking advantage
> of the flexibility of XML vs. MARC's usual format.
>
> Don't get me wrong, these are improvements. I see very little reason NOT
> to be using MODS instead of MARC. But if anyone's looking for radical
> change to our encoding and transmission formats, it's not MODS. If
> anyone thinks that MODS is already too radical a change---we're really
> in trouble.
>
> I don't personally think that a change in
> encoding-and-transmission-format is what we need anyway. The problem is
> that MARC ends up being used as a data model and a content standard,
> when it shouldn't be. We need improvements to data models and content
> standards, and if we had them, we could keep on using MARC, no problem,
> interchangeably with a bunch of other serialization formats. But people
> need to start trying to put MARC in it's place instead of trying to use
> it as a data model and a content standard. Maybe using MODS instead of
> MARC would help push people in that direction, just by making people see
> things in a new way.
>
> Jonathan
>
> Bernhard Eversberg wrote:
>> Eric Lease Morgan wrote:
>>>
>>>
>>> While I assert there is no "right" answer to this question, at first
>>> blush I would suggest MODS. It is an XML data structure and the
>>> element names are word, not numbers.
>>>
>> And how easy is it to talk MODS and be instantly understood, like if
>> someone says 260$c now or 700$t.
>> How do you pronounce caps inside words, BTW?
>>
>> The subject isn't new at all. 30 years ago, I attended a conference.
>> The big heads in library automation of that time were present, like Fred
>> Kilgour. I asked the question if MARC mightn't be simplified to make it
>> easier to understand and use. Someone said, well, they had thought of it
>> and tried very hard to work out something better. But they ended up
>> re-inventing MARC. MODS is another re-invented MARC, only much more
>> loquacious.
>>
>> But MARC is not the battlefront. Some improvements, like for names,
>> are conceivable. But it is interfacing that matters, all the time.
>>
>>
>> B.Eversberg
>>
>
> --
> Jonathan Rochkind
> Sr. Programmer/Analyst
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886
> rochkind (at) jhu.edu
>
--
Jonathan Rochkind
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Wed Jan 17 2007 - 14:57:19 EST