Re: MARC records, and inheritance
Ed, I am just beginning to think about these things, but it seems to me that the MARC Record is a storage format for things are in reality quite different objects, bibliographic records, holdings, name authority, etc. The methods for handling the format all work fine, of course, across these types of objects. But I don't think it should be possible to process records of one type, when they should be another type. For instance, a holding record has no title fields at all. I think, maybe, the title method should throw an exception, or error when you try to grab the 245 of a holding or other record. (or call a user defined error handler) As I think about this, I am not sure that inheritance is the right tool -- I am beginning to think maybe that there should be records of Bib, Holding, NameAuthority, Community, etc which have their own methods, and which contain a marc record. Cheers, Rick At 08:01 PM 3/14/2004 -0600, Ed Summers wrote: Hi Enrico: On Sun, Mar 14, 2004 at 02:47:26PM -0500, Enrico Silterra wrote: I think that having various derived classes of MARC records. Holding, Bib Records, Name Authority, etc would be useful. Interesting question. MARC::Record should handle holdings, authority, classification, and community records just fine since they are all structurally the same. The type of record could be determined by looking at position 6 in the leader. But I'm wondering why you think having MARC::Record::Bibliographic MARC::Record::Authority (etc) would be useful. MARC::Records generic methods already work fine for all these types of MARC records. Enabling MARC::Lint (which does deal with the semantics of the tags) to understand authority, classification, community records would be cool. In fact it's on the shortlist of things to do if you are interested [1]. //Ed [1] http://rt.cpan.org/NoAuth/Bug.html?id=4813 ** Enrico Silterra Meta Data Engineer 107-E Olin Library Cornell University Ithaca NY 14853 Voice: 607-255-6851 Fax: 607-255-6110 E-mail: [EMAIL PROTECTED] http://www.library.cornell.edu/cts/ **
Re: MARC records, and inheritance
On Mon, Mar 15, 2004 at 09:21:49AM -0500, Enrico Silterra wrote:
For instance, a holding record has no title fields at all. I think, maybe,
the title method should throw an exception, or error when you try to grab
the 245 of a holding or other record. (or call a user defined error handler)
Perhaps, but there are really only a handful of methods that are specific
to bibliographic records. I'm not sure that adding ways that MARC::Record
can fail is worth a lot of time and effort. If you are interested in
doing this sort of checking it can easily be done in your program by checking
position 6 in the leader.
if ( substr( $record-leader(), 6, 1 ) !~ /^[acdefgijkmoprt]$/ ) {
die uhoh, this ain't a bibliographic record\n;
}
As I think about this, I am not sure that inheritance is the right tool --
I am beginning to think maybe that there should be records of Bib,
Holding, NameAuthority, Community, etc which have their own methods,
and which contain a marc record.
I understand where you are going with this, but I'm not a big fan of the
bibliographic specific methods in MARC::Record in the first place, and am of
the opinion that adding more would not be a good idea. The meaning of tags,
while pretty stable, could change at any time...and the tags mean different
things in different flavors of MARC anyway.
Were you processing a bunch of MARC data that had bib/authority/holdings
records interspersed? I still think it would be cool if MARC::Lint could
grok authority, holdings (etc) records in addition to bib records. Of course
there are other people who use MARC::Record, who may agree with you :) This
is just the first time I've heard it come up in the last four years.
If I haven't scared you off, and you end up using MARC::Record for a project
would you be willing to send a couple of sentences describing your work so we
could add it to the website?
//Ed
MARC records, and inheritance
Beginning to use perl to parse MARC records, and thinking about the different types of MARC records. I think that having various derived classes of MARC records. Holding, Bib Records, Name Authority, etc would be useful. I am not quite sure of a good way of reading in the records and returning the correct type. My initial thought is to over-ride the next method on file, to examine the record, and return a record of the correct derived type, instead of MARC. Thanks a lot for your thoughts. Rick Silterra ** Enrico Silterra Meta Data Engineer 107-E Olin Library Cornell University Ithaca NY 14853 Voice: 607-255-6851 Fax: 607-255-6110 E-mail: [EMAIL PROTECTED] http://www.library.cornell.edu/cts/ **
Re: MARC records, and inheritance
Hi Enrico: On Sun, Mar 14, 2004 at 02:47:26PM -0500, Enrico Silterra wrote: I think that having various derived classes of MARC records. Holding, Bib Records, Name Authority, etc would be useful. Interesting question. MARC::Record should handle holdings, authority, classification, and community records just fine since they are all structurally the same. The type of record could be determined by looking at position 6 in the leader. But I'm wondering why you think having MARC::Record::Bibliographic MARC::Record::Authority (etc) would be useful. MARC::Records generic methods already work fine for all these types of MARC records. Enabling MARC::Lint (which does deal with the semantics of the tags) to understand authority, classification, community records would be cool. In fact it's on the shortlist of things to do if you are interested [1]. //Ed [1] http://rt.cpan.org/NoAuth/Bug.html?id=4813
