Re: Early Confusion with MARC::Record + more confusion
On Sun, Nov 16, 2003 at 08:25:41AM -0600, Ed Summers wrote: > > Is the LC server the "definitive" Z39.50 database? If I suck down a record > > from there, send it to my database, add more information, etc., etc., how > > does it get back to the LC? Does it? Would the way I'd contribute be > > to simply run and promote my own Z39.50 server? > > I guess you could say LC has the definitive Z39.50 databasee, since they do > so much original cataloging. OCLC also has a huge database (WorldCAT) which > is incredible because of the holdings data it contains (records which tell > you what libraries have a particular title). > > Z39.50 is a mechanism for *discovery* only. If you want to run your own > Z39.50 server you might want to check out IndexData's SimleServer [1]. Just to clarify a bit: Z39.50 can be used for searching and retrieval of records from compliant databases, by means of Z39.50 servers and clients. One usually thinks of retrieving bibliographic records in MARC format via Z39.50, but the protocol is, strictly speaking, format-agnostic. I belive there are Z39.50 servers offering access to GILS records, for instance. When you search LC via Z39.50, you are searching the same underlying bibliographic data as when you search via the web-based OPAC. I believe one can expose XML data via Z39.50 as well. As for who has a definitive database, that's a complex question. OCLC loads tapes of LC's cataloging, so you could consider OCLC a superset of LC. Many institutions modify catalog records acquired from OCLC before loading into a local database, so it's difficult to say if there is a definitive form of a given record. LC's cataloging copy is generally a very good starting point. Since they are the creators and maintainers of the Library of Congress Subject Headings and the Library of Congress Classification, their use of these headings and class numbers could be considered definitive, but again, many institutions adapt the class numbers to fit into local shelf-listing schemes. Cataloging rules don't stipulate procedures and outputs with the same degree of specificity as e.g. networking protocols. LC promulgates its own interpretations of AACR2 (Anglo-American Cataloging Rules) because there are many important specific cases not covered by AACR2 which must be resolved. Some institutions follow the LCRIs in toto. Many institutions choose to follow some of them. Some institutions may ignore them altogether. It is understood and accepted that local practice should play a role in understanding how to apply cataloging rules and standards in each setting. I would say that the lack of complete specificity, the reliance on local practice, and on the cataloger's judgement, are good things. First, catalogers should catalog to meet the needs of their users. Second, bibliographic records in their end use are in great measure understood and resolved by the human mind and not by other programs, which might choke on the discrepancies. You are picking things up very quickly. I hope this little rant was helpful in providing further background for understanding the cataloging world you are now exploring. Chuck Bearden
Lint.pm and 250$b
When I ran Lint on a file of records, one of the errors I received was "250: Subfield _b is not allowed." According to the most recent documentation, 250$b is $b - Remainder of edition statement (NR). I do not know when this change took place, but it has been around for as long as I can remember (though my memory only reaches back to 2000), and according to a colleague, it was in place for a while before that. Thank you for your assistance, Bryan Baldus Cataloger Quality Books, Inc. The Best of America's Independent Presses 1-800-323-4241x460 [EMAIL PROTECTED]
Clarification on MARC::Simple Intent
As part of my first messages to the list, I blurbed:
Is anyone interested in a MARC::Simple sort of module, that would
"use English"-ize all the tags themselves ($record->author_name("Logan,
Robert K.") and $record->author_date("1939-"), which would just be
wrappers around MARC::Field and the relevant tag numbers).
To which Ed replied:
You will notice that some of these already exist. author(), title(),
edition(), publication_date(). I think it could be worthwhile to
extend these. What did you have in mind? Remember doing this for all
the MARC tags is probably not a sane thing to do :)
My assumption at the time was that the above MARC::Record methods also
applied to MARC::Field objects, allowing creations like this:
my $author = MARC::Field->new(
'100',1,'',
a => 'Logan, Robert K.',
d => '1939-'
);
my $title = MARC::Field->new(
'245','1','4',
a => 'The alphabet effect /',
c => 'Robert K. Logan.'
);
to be re-written as:
my $author = MARC::Field->new;
$author->author_name('Logan, Robert K.');
$author->author_data('1939-');
my $title = MARC::Field->new;
$title->something("The alphabet effect /';
$title->authority( $author->author_name );
Is that something anyone would be interested in? I suspect there are a huge
amount of problems with the approach (most prominently that the idea of
using
tag numbers was to reduce typing in the first place), but has anyone ever
had some non-MARC-expert intern try to modify some code and screw it up?
Would "English"'d methods like this be helpful?
--
Morbus Iff ( i've got the creme filling )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
How Far Does "Different Data Formats" Apply?
In MARC::Doc::Tutorial, it mentions: Note to the curious: the C method is actually an alias to the MARC::File::USMARC C method. Having separate C methods is a design feature of the MARC class hierarchy, since it allows extensions to be built that translate MARC::Record objects into different data formats. How far does "different data formats" apply? Only to MARC subsets? What if I wanted to make MARC::File::MODS? MARC::File::DublinCore? Would those be considered valid data formats for extension? -- Morbus Iff ( shower your women, i'm coming ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
[patch] Accept # as Blank Indicator
In the LC's brochure, a blank indicator is referred with a # character,
and followed with this explanation: "It is the convention to represent a
blank, or undefined, indicator position by the character "#"." If that's
the case, MARC::Field should accept the following as equivalent:
MARC::Field->new('100','1','', a=>'Logan, Robert K.', d=>'1939-'),
MARC::Field->new('100','1','#', a=>'Logan, Robert K.', d=>'1939-'),
This is relatively trivial; on line 77 of MARC::Field, replace:
if ( $indicator !~ /^[0-9 ]$/ ) {
with:
if ( $indicator !~ /^[0-9 #]$/ ) {
Thoughts?
--
Morbus Iff ( cheese and rice saves )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Re: Clarification on MARC::Simple Intent
On Tue, Nov 18, 2003 at 07:52:04PM -0500, Morbus Iff wrote:
> my $author = MARC::Field->new;
> $author->author_name('Logan, Robert K.');
> $author->author_data('1939-');
>
> my $title = MARC::Field->new;
> $title->something("The alphabet effect /';
> $title->authority( $author->author_name );
>
> Is that something anyone would be interested in? I suspect there are a huge
> amount of problems with the approach (most prominently that the idea of
> using
> tag numbers was to reduce typing in the first place), but has anyone ever
> had some non-MARC-expert intern try to modify some code and screw it up?
> Would "English"'d methods like this be helpful?
Personally, I don't like the idea of adding this methods to MARC::Field.
MARC::Field is a generic class for representing a MARC field, and shouldn't
have methods in it that are specific for a particular flavor of field. Also,
we've taken pains to keep the MARC::Record class as simple as possible, and
this would add a fair amount of complexity for little gain.
It might however be worthwhile pursuing the addition of MARC::Record::Simple
which subclasses MARC::Record, and MARC::Field::Author, MARC::Field::Title,
... which subclass MARC::Field. Just a thought.
//Ed
Re: How Far Does "Different Data Formats" Apply?
On Tue, Nov 18, 2003 at 08:00:26PM -0500, Morbus Iff wrote: > How far does "different data formats" apply? Only to MARC subsets? What if > I wanted to make MARC::File::MODS? MARC::File::DublinCore? Would those be > considered valid data formats for extension? Yes, this was always the hope that these different formats would be added. See MARC::File::XML for an example of how to do this. //Ed
Re: [patch] Accept # as Blank Indicator
On Tue, Nov 18, 2003 at 08:11:39PM -0500, Morbus Iff wrote:
> MARC::Field->new('100','1','', a=>'Logan, Robert K.', d=>'1939-'),
> MARC::Field->new('100','1','#', a=>'Logan, Robert K.', d=>'1939-'),
I don't like this. The # is used simply as a typographical convention in LC's
online docs. It has nothing to do with the actual content found in MARC
records.
//Ed
Re: [patch] Revised MARC::Doc::Tutorial
Ed and everyone else: I've finished my fiddling with the Doc::Tutorial: correcting grammar, renumbering the recipes for easier maintenance, and yadda yadda yadda. It's been committed to CVS. -- Morbus Iff ( i am the horrible hogglewart ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Re: [patch] warn, not croak, on 010 non-tag access.
At 8:59 PM -0600 11/17/03, Ed Summers wrote: >On Mon, Nov 17, 2003 at 09:15:22PM -0500, Morbus Iff wrote: >> > Since MARC tags less than 010 can not have indicators or subfields, >> > not allowing those ::Field methods to be called on those tags make sense. >> > However, this should be a warn(), not a croak(), otherwise looping >> > code will need to conditionally check tag numbers before continued >> > processing. >> >> Any thoughts on this patch? > >I think this sounds like a good change, that users (especially new ones) will >appreciate. Best of all it is a loosening of behavior so existing MARC::Record >users will be able to upgrade with no pain. Committed to CVS. -- Morbus Iff ( damn you richards! i will have my revenge! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Re: [patch] Accept # as Blank Indicator
On Tue, Nov 18, 2003 at 07:50:39PM -0600, Ed Summers wrote:
> On Tue, Nov 18, 2003 at 08:11:39PM -0500, Morbus Iff wrote:
> > MARC::Field->new('100','1','', a=>'Logan, Robert K.', d=>'1939-'),
> > MARC::Field->new('100','1','#', a=>'Logan, Robert K.', d=>'1939-'),
>
> I don't like this. The # is used simply as a typographical convention in LC's
> online docs. It has nothing to do with the actual content found in MARC
> records.
I think Ed is right. As I recall, OCLC used to use an underscore for
blank indicator positions, but now they seem to be using the doodad
represented in this image:
http://www.oclc.org/bibformats/images/specchar/blank.gif
The OCLC conventions are probably much more widely known than the LC
ones simply because most libraries doing copy cataloging use OCLC as
their utility.
The point about the hash sign as a typographic convention is also worth
noting. That raises the (for me largely idle) question of whether a
blank space ought to be acceptable as the value for an indicator
position.
Chuck
Re: Clarification on MARC::Simple Intent
On Tue, Nov 18, 2003 at 07:52:04PM -0500, Morbus Iff wrote: > Is that something anyone would be interested in? I suspect there are a huge > amount of problems with the approach (most prominently that the idea of > using > tag numbers was to reduce typing in the first place), but has anyone ever > had some non-MARC-expert intern try to modify some code and screw it up? > Would "English"'d methods like this be helpful? It really depends on who you anticipate using the module. I suspect for working catalogers who have to scrape subfields and indicators from under their fingernails at the end of a day, the non-English'd methods are faster and easier. So it seems to me, and I'm 6 or 7 years out of practice as a cataloger. I don't have a good sense of how many non-catalogers and non-library-staff want to work directly with MARC data. I'm certain that you aren't the only one. My assumption is that most folks will be interested in getting data out of MARC for use in systems that make more sense for their purposes, but not in writing it back to MARC. If you decide to write something for inclusion in the MARC:: family of modules, I would suggest that you do some form of usability testing (be it merely informal polling of potential users) to see if their understanding of the semantics of your method names corresponds to your intentions. That's where I would expect problems to arise. Chuck
