Re: [ot] Targeted Spam Harvesting from *lib lists?

[Morbus Iff]

I thought twice about sending this, mostly from the "should I contribute
more to the signal/noise damage I've created", but wanted to clarify:
 * The smiley at the end was intentional and deliberate; without
   it, it makes me seem upset. With it, I hoped to express only
   that "it wasn't cool" not "OHMIGOD! PERL4LIB IS EVILLL!".
   The "name-calling" was not meant to be knife-in-the-back,
   but a poke-in-the-rib.
 * My take on spam is jovial, not anger, something I've written
   about before: http://www.disobey.com/dnn/2003/01/index.shtml#001433
   In re-reading, I still agree with everything I said.
 * The fact that I got a spam on something I'm interested in
   should make me happy - it is, in fact, something I'm interested
   in (I like movies, I want to know about new movies; I like magazines,
   I want more free subscriptions; I'm researching cataloging, bring
   on the catalog emails). The fact that it was unsolicited (and
   HTML) were the only negatives.
 * My initial question ("has anyone else gotten...") was intended
   as a gauge to the level of unsolicited: if EVERYONE had seen
   something from this guy, then it was probably a web scrape
   of some sort (as Ed suggested). But the exact targeting
   of the email to my question suggested a more focused,
   human-controlled-yet-automated mailing (suggesting also
   a designed-for-this-purpose application, or a mailing list
   or archive reader/lurker). I wouldn't have sent an email
   *whatsoever* if I had received something that said "hey
   morbus, saw your question $here. look at $this! only
   $price for $x months! yeah, baby, yeah!".
With that said to sandwich my public OT, I'll hush on the matter -
continued discussion, if any, is welcome to email me privately.
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
My book, Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: [ot] Targeted Spam Harvesting from *lib lists?

[Chuck Bearden]

On Wed, Nov 19, 2003 at 11:20:41AM -0600, Ed Summers wrote:
> On Wed, Nov 19, 2003 at 11:50:05AM -0500, Morbus Iff wrote:
> > Has anyone encountered targeted spam from perl4lib or oss4lib posts?
> > I've posted numerous times to perl4lib, and once to oss4lib. Just now,
> > I suddenly got a spam for "BowkerLink", which submits to Ulrich's
> > Periodicals Directory, something right in line with my earlier
> > questions. Besides friends/IM, I've not publicly stated my
> > research into cataloging, so I can only suspect it's an
> > incredibly odd coincidence, or there are some asshole
> > lurkers on the list. ;)
> 
> Spam is a global problem, and not something isolated to this list. As a 
> seasoned Perl user you are no doubt aware of how easy it is to scrape email 
> addresses from the webpages. While this list isn't moderated (emails
> reviewed before posting), we are a polite and friendly bunch. Let's not
> start calling people names.
>
> If you have any concerns with the way the perl4lib list is being 
> managed please contact Ask Bjorn Hansen at perl.org (ask at 
> develooper.com). 

I'll second Ed's remark on list decorum.  In the three or four years I
"ran" the list, I was only once ever tempted to intervene, and that 
was due to nothing more heinous than an off-topic thread around the 
holidays, which actually took care of itself.  That fact speaks to 
the character of the list and its members, whom I think we owe the
presumption of innocence.  I daresay Morbus Iff didn't have them in
mind.

However, I think Morbus Iff's point was the targeted nature of the 
spam.  That really is an odd coincidence, and I have a hard time 
imagining that Bowker emails ads at random.  I can't recall having 
gotten anything from them myself, at least not in recent years.

Chuck

Re: [patch] Accept Letters as Indicator

[Chuck Bearden]

On Wed, Nov 19, 2003 at 08:57:52AM -0600, Anne Highsmith wrote:
> Yup, looks like it. This is a new one on me, who haven't really studied
> MARC since I escaped from MARBI in 1992. Maybe this is a USMARC->MARC 21
> change, i.e. something that came in with MARC 21? Or was it a change in
> the ANSI or ISO standards? I don't think lowercase alphabetics were
> valid indicators in USMARC, which is why I'm positing a change
> somewhere, although my memory may be deficient. In any case, the LOC
> statement as to current standard seems quite clear.

ANSI Z39.2-1994 defines "Indicator" thus:

  Indicator-A one-character data element that is associated with a 
data field and that supplies additional information about the 
field. When indicators are present, they are the first data 
elements in the field. (p. 3)

The standard doesn't say what kind of character is permissible in an
indicator.  They do explicitly say that tags are alpha-numeric: "A 
tag shall contain three alphabetic or numeric ASCII graphic 
characters" (p. 4).

I haven't forked over the Swiss francs to buy ISO 2709, so I can't say
if they explicitly allow alphabetic characters as indicators.

Doesn't it seem strange how much I still seem to care about MARC, given
that I haven't cataloged (or supported catalogers) in at least five
years?  Should I be concerned?

Chuck

Re: [patch] Accept # as Blank Indicator

[Chuck Bearden]

On Wed, Nov 19, 2003 at 07:43:52AM -0500, Morbus Iff wrote:
> >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 LC also uses $ to represent sub-tags (I think that's what
> they're called; just woke up... the $a/$b things). But, I
> seem to see _a and _b more often. Which is more prevalent?

They are called subfields.  A variable data field (01X-8XX in USMARC
Bibliographic) comprises a 3-character tag, two indicators, and one 
or more subfields.

Well, if I were representing a MARC field in longhand, I would use the
dollar-sign with the alpha-num character identifying it.  I think the
underscore is used in MARCBreaker pretty-print.  I've also seen the
vertical bar used in other applications.  My feeling is that the 
dollar-sign is the most common, unless you are trying to emulate the 
output of a particular app (e.g. MARCBreaker) that follows a 
different convention.

Chuck

Re: [patch] Accept Letters as Indicator

[Morbus Iff]

>Yup, looks like it. This is a new one on me, who haven't really studied
>MARC since I escaped from MARBI in 1992. Maybe this is a USMARC->MARC 21
>change, i.e. something that came in with MARC 21? Or was it a change in
>the ANSI or ISO standards? I don't think lowercase alphabetics were
>valid indicators in USMARC, which is why I'm positing a change
>somewhere, although my memory may be deficient. In any case, the LOC
>statement as to current standard seems quite clear.
As Ed said, and I'm slowly starting to agree with for different reasons, 
does anyone absolutely need the alphabetics as an indicator? More importantly:

 * what should MARC::Record read and write as a baseline?
   MARC? USMARC/MARC21? UniMARC? I don't even know the
   differences between them, but is MARC21 backwards
   compatible with MARC? Is anyone who's anyone ALWAYS
   using the latest LC MARC standard? Is that the same
   assumption that should be placed on MARC::Record?
 * If someone is ONLY using MARC, and they MARC::Lint,
   will they expect MARC-rules ("no alpha indicators") or
   MARC21 rules ("alpha indicators"). How badly will this
   break Lint scripts? A MARC record shouldn't be validated
   against MARC21 rules (especially if another program
   expects non-alpha's under MARCs, but gets a linted and
   "correct" MARC21 with alphas).
Note to readers: When I say "MARC", I mean "the one that no one remembers 
allowing alphabetic indicators". When I say "MARC21", I collectively mean 
"USMARC/MARC21" or "the one Anne quoted that says alphas are dandy". I 
suspect I'm using one of those terms incorrectly - cluestick happily.

--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
My book, Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: [patch] Accept Letters as Indicator

[Anne Highsmith]

Yup, looks like it. This is a new one on me, who haven't really studied
MARC since I escaped from MARBI in 1992. Maybe this is a USMARC->MARC 21
change, i.e. something that came in with MARC 21? Or was it a change in
the ANSI or ISO standards? I don't think lowercase alphabetics were
valid indicators in USMARC, which is why I'm positing a change
somewhere, although my memory may be deficient. In any case, the LOC
statement as to current standard seems quite clear.

Anne L. Highsmith
Consortia Systems Coordinator
5000 TAMU
Evans Library
Texas A&M University
College Station, TX   77843-5000
[EMAIL PROTECTED]
979-862-4234
979-845-6238 (fax)

>>> Morbus Iff <[EMAIL PROTECTED]> 11/19/03 08:43AM >>>
Anne L. Highsmith says:
 >Quoting from "MARC 21 Specifications for Record Structure,
 >Character Sets, and Exchange Media RECORD STRUCTURE",
 >http://www.loc.gov/marc/specifications/specrecstruc.html#varifields 
 >"Indicators may be any ASCII lowercase alphabetic, numeric, or
blank"

So, if that's the case, then MARC::Field is partially incorrect
in its implementation of only digits and a blank, as per the
following line ("if indicator is NOT a digit or a space..."):

  if ( $indicator !~ /^[0-9 ]$/ ) {

Correct?




-- 
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/ 
Mac OS X Hacks:
http://amazon.com/exec/obidos/ASIN/0596004605/disobeycom 
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: Clarification on MARC::Simple Intent

[Chuck Bearden]

On Wed, Nov 19, 2003 at 09:16:20AM +0100, Tajoli Zeno wrote:
> Hi to all,
> 
> At 01.52 19/11/03, 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?
> 
> 
> In fact I don't subscribe this type of changes.
> Why ?
> Because they hard coded in the module the USMARC/MARC21 standard.
> 
> There different flouvers of MARC, the Library of Congress mantains USMARC 
> .
> For example I use Unimarc, mantained from IFLA.
> 
> A concise Unimarc  is avaible from: 
> http://www.ifla.org/VI/3/p1996-1/concise2.pdf
> A full Unimarc  is avaible from: 
> http://www.ifla.org/VI/3/p1996-1/sec-uni.htm
> 
> The differences between MARC21 and Unimarc are  many; a good documentation 
> is avaible from:
> http://www.loc.gov/marc/unimarctomarc21.html .
> From example there are differences also in the Record Leader !!.

Morbus Iff will correct me if I'm wrong, but I don't think the changes
he proposed were to replace the full field/subfield/indicator interface
available through MARC::Record.  The MARC::Simple module would be an
optional adjunct to the other MARC:: modules.  It would not change the
way MARC::Record functions.

Your post does suggest the need perhaps to be able to qualify
MARC::Simple with a particular flavor.  It does also illustrate some of
the extensibility problems arising from the use of field- and
subfield-specific methods with English'd names.  

Chuck

Re: [ot] Targeted Spam Harvesting from *lib lists?

[Ed Summers]

On Wed, Nov 19, 2003 at 11:50:05AM -0500, Morbus Iff wrote:
> Has anyone encountered targeted spam from perl4lib or oss4lib posts?
> I've posted numerous times to perl4lib, and once to oss4lib. Just now,
> I suddenly got a spam for "BowkerLink", which submits to Ulrich's
> Periodicals Directory, something right in line with my earlier
> questions. Besides friends/IM, I've not publicly stated my
> research into cataloging, so I can only suspect it's an
> incredibly odd coincidence, or there are some asshole
> lurkers on the list. ;)

Spam is a global problem, and not something isolated to this list. As a 
seasoned Perl user you are no doubt aware of how easy it is to scrape email 
addresses from the webpages. While this list isn't moderated (emails
reviewed before posting), we are a polite and friendly bunch. Let's not
start calling people names.

If you have any concerns with the way the perl4lib list is being managed please 
contact Ask Bjorn Hansen at perl.org (ask at develooper.com). 

//Ed

Re: MARC::Record::update_leader()

[Ed Summers]

On Wed, Nov 19, 2003 at 05:00:53PM +, Ben Soares wrote:
> update_leader() used to be really handy when you read in a MARC::Record from 
> somewhere, changed or added a few fields.  Then to update the leader to 
> reflect those changes you only had to call $record->update_leader() and not 
> have to do any tedious and possibly incorrect calculations yourself to set 
> the leader using $record->leader($text).

update_leader() is called automatically when you output a record. No need
to call it.

//Ed

Re: MARC::Record::update_leader()

[Morbus Iff]

>update_leader() used to be really handy when you read in a MARC::Record from
>somewhere, changed or added a few fields.  Then to update the leader to
>reflect those changes you only had to call $record->update_leader() and not
>have to do any tedious and possibly incorrect calculations yourself to set
>the leader using $record->leader($text).
>
>but thought that update_leader() ought (and used) to do this for you (indeed
>we're not 100% sure our calculations are right, but they seem to work!).
MARC::File::USMARC will automatically create a leader for you if you
don't specify one - perhaps you could blank out the existing leader (or
to do as MARC::Record->new does, create a leader of 24 spaces), then
save as_usmarc, hoping to trigger the automatic creation?
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
My book, Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: MARC::Record::update_leader()

[Ben Soares]

Hello,

MARC::Record::leader() doesn't have the same function as update_leader().

leader() seems to be a setter/getter method, but to set you need to know 
what you're setting to beforehand.

update_leader() used to be really handy when you read in a MARC::Record from 
somewhere, changed or added a few fields.  Then to update the leader to 
reflect those changes you only had to call $record->update_leader() and not 
have to do any tedious and possibly incorrect calculations yourself to set 
the leader using $record->leader($text).

I'm currently using a colleague's calculations (from the UKMARC manual):

my $reclen = length($marc->as_usmarc())+24;
my $baseaddr = 24+(scalar($marc->fields())*12)+1;
$marc->set_leader_lengths(sprintf("%05d", $reclen), 
  sprintf("%05d", $baseaddr));

but thought that update_leader() ought (and used) to do this for you (indeed 
we're not 100% sure our calculations are right, but they seem to work!).

Any more clues?

Ben


On Wed, 19 November, 2003 16:42, Ed Summers wrote:
> On Wed, Nov 19, 2003 at 04:22:41PM +, Ben Soares wrote:
> > I see there's an update_leader() method in MARC::File::USMARC, but I
> > can't work out how you're supposed to use it.  At first glance at the
> > code, it looks like update_leader() and _build_tag_directory() have
> > fallen out of MARC::Record and ended up in MARC::File::USMARC by
> > accident?
>
> See MARC::Record::leader().
>
> //Ed

-- 
Ben Soares tel: +44 (0)131-651 1238
EDINA, Edinburgh University Data Library   fax: +44 (0)131-650 3308
Main Library Building, George Square email: [EMAIL PROTECTED]
Edinburgh EH8 9LJ, Scotland, UKwww: http://edina.ac.uk/

"Hmmm, that makes no sense to me...
 But then you are very small, perhaps you're right." -- Treebeard

[ot] Targeted Spam Harvesting from *lib lists?

[Morbus Iff]

Has anyone encountered targeted spam from perl4lib or oss4lib posts?
I've posted numerous times to perl4lib, and once to oss4lib. Just now,
I suddenly got a spam for "BowkerLink", which submits to Ulrich's
Periodicals Directory, something right in line with my earlier
questions. Besides friends/IM, I've not publicly stated my
research into cataloging, so I can only suspect it's an
incredibly odd coincidence, or there are some asshole
lurkers on the list. ;)


--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
My book, Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: MARC::Record::update_leader()

[Ed Summers]

On Wed, Nov 19, 2003 at 04:22:41PM +, Ben Soares wrote:
> I see there's an update_leader() method in MARC::File::USMARC, but I can't 
> work out how you're supposed to use it.  At first glance at the code, it 
> looks like update_leader() and _build_tag_directory() have fallen out of 
> MARC::Record and ended up in MARC::File::USMARC by accident?

See MARC::Record::leader().

//Ed

MARC::Record::update_leader()

[Ben Soares]

Hi all,

Whatever happened to the update_leader() method in MARC::Record?

I see there's an update_leader() method in MARC::File::USMARC, but I can't 
work out how you're supposed to use it.  At first glance at the code, it 
looks like update_leader() and _build_tag_directory() have fallen out of 
MARC::Record and ended up in MARC::File::USMARC by accident?

Any clues?

Thanks,

Ben
-- 
Ben Soares tel: +44 (0)131-651 1238
EDINA, Edinburgh University Data Library   fax: +44 (0)131-650 3308
Main Library Building, George Square email: [EMAIL PROTECTED]
Edinburgh EH8 9LJ, Scotland, UKwww: http://edina.ac.uk/

"Hmmm, that makes no sense to me...
 But then you are very small, perhaps you're right." -- Treebeard

Re: USEMARCON v1.4 [was Re: Clarification on MARC::Simple Intent]

[Ed Summers]

On Wed, Nov 19, 2003 at 10:29:42AM +, Ben Soares wrote:
> I haven't used it so can't really say anything from experience, but it's 
> developed on behalf of the British Library so it's from a highly credible 
> source.

Thanks for the pointer to USEMARCON. I hadn't heard about it, and the topic
of UNIMARC/MARC21 has definitely come up in the past.

> Would perl wrappers around the toolkit be something worth considering?

Good idea! I just downloaded it. It does have a license agreement, which would
have to be looked at pretty closely, but it seems pretty lenient at first
glance. It's c++ so it should be fast, and would be a nice experiment in 
building a Perl wrapper. Any takers? I bought Extending and Embedding Perl [1]
last year, and have been looking for a good excuse to use it :)

//Ed

[1] http://www.manning.com/jenness/ 

-- 
Ed Summers
aim: inkdroid
web: http://www.inkdroid.org

Any fool can write code that a computer can understand. Good programmers
write code that humans can understand. [Martin Fowler]

Re: [patch] Accept Letters as Indicator

[Andy Lester]

> Perhaps, but we've yet to have anyone complain :)

That's pretty much the strategy we've had on features in MARC::Record,
and my strategy for any module: If someone needs it, I'll put it in.  If
they don't, I won't.

xoa

-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: [patch] Accept Letters as Indicator

[Ben Soares]

This sounds more like a specification than a feature and so should probably 
be added?

Ben


On Wed, 19 November, 2003 15:14, Ed Summers wrote:
> On Wed, Nov 19, 2003 at 09:43:51AM -0500, Morbus Iff wrote:
> >  if ( $indicator !~ /^[0-9 ]$/ ) {
>
> Perhaps, but we've yet to have anyone complain :) I guess it would
> be ok to loosen this behavior if you have a pressing need for it. But I
> would steer away from adding features just for the sake of adding them.
> This is where MARC.pm went down the wrong path IMHO.
>
> //Ed

-- 
Ben Soares tel: +44 (0)131-651 1238
EDINA, Edinburgh University Data Library   fax: +44 (0)131-650 3308
Main Library Building, George Square email: [EMAIL PROTECTED]
Edinburgh EH8 9LJ, Scotland, UKwww: http://edina.ac.uk/

"Hmmm, that makes no sense to me...
 But then you are very small, perhaps you're right." -- Treebeard

Re: [patch] Accept Letters as Indicator

[Ed Summers]

On Wed, Nov 19, 2003 at 09:43:51AM -0500, Morbus Iff wrote:
>  if ( $indicator !~ /^[0-9 ]$/ ) {

Perhaps, but we've yet to have anyone complain :) I guess it would
be ok to loosen this behavior if you have a pressing need for it. But I would
steer away from adding features just for the sake of adding them. This is where
MARC.pm went down the wrong path IMHO.

//Ed

Re: [patch] Accept # as Blank Indicator

[Ed Summers]

On Wed, Nov 19, 2003 at 07:43:52AM -0500, Morbus Iff wrote:
> The LC also uses $ to represent sub-tags (I think that's what
> they're called; just woke up... the $a/$b things). But, I
> seem to see _a and _b more often. Which is more prevalent?

LC's MARCMaker/MARCBreaker utilities use $ if I remember right. 
It's mainly a typographical convention that should have little bearing
on how MARC::Record works.

//Ed

[patch] Accept Letters as Indicator

[Morbus Iff]

Anne L. Highsmith says:
>Quoting from "MARC 21 Specifications for Record Structure,
>Character Sets, and Exchange Media RECORD STRUCTURE",
>http://www.loc.gov/marc/specifications/specrecstruc.html#varifields
>"Indicators may be any ASCII lowercase alphabetic, numeric, or blank"
So, if that's the case, then MARC::Field is partially incorrect
in its implementation of only digits and a blank, as per the
following line ("if indicator is NOT a digit or a space..."):
 if ( $indicator !~ /^[0-9 ]$/ ) {

Correct?



--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Mac OS X Hacks: http://amazon.com/exec/obidos/ASIN/0596004605/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Re: [patch] Accept # as Blank Indicator

[Anne Highsmith]

Quoting from "MARC 21 Specifications for Record Structure,
Character Sets, and Exchange Media

RECORD STRUCTURE", 
http://www.loc.gov/marc/specifications/specrecstruc.html#varifields

"Indicators may be any ASCII lowercase alphabetic, numeric, or blank"

Period. As mentioned by others, the '#' or '_' is simply a typographic
convention for representing a blank. So yes, blank spaces are valid
indicator values.

Anne L. Highsmith
Consortia Systems Coordinator
5000 TAMU
Evans Library
Texas A&M University
College Station, TX   77843-5000
[EMAIL PROTECTED]
979-862-4234
979-845-6238 (fax)

>>> Chuck Bearden <[EMAIL PROTECTED]> 11/18/03 10:50PM >>>
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: [patch] Accept # as Blank Indicator

[Colin Campbell]

On Tue, Nov 18, 2003 at 10:50:22PM -0600, Chuck Bearden <[EMAIL PROTECTED]> wrote:
> 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:
> 
I'd second that. I've seem software that generated serious problems
through confusing the the typographical conventions with the data. Also
the fact the space is enclosed in quotes is doing the same thing for the
Human reader that LOC's hash is doing (showing it is a space not a null
string)
Colin

-- 
  Colin Campbell 
  Technical Services Consultant
  Sirsi Ltd
  [EMAIL PROTECTED]

Re: [patch] Accept # as Blank Indicator

[Morbus Iff]

>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 LC also uses $ to represent sub-tags (I think that's what
they're called; just woke up... the $a/$b things). But, I
seem to see _a and _b more often. Which is more prevalent?

-- 
Morbus Iff ( evil is my sour flavor )
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

USEMARCON v1.4 [was Re: Clarification on MARC::Simple Intent]

[Ben Soares]

On Wed, 19 November, 2003 08:16, Tajoli Zeno wrote:
>
> In fact I don't subscribe this type of changes.
> Why ?
> Because they hard coded in the module the USMARC/MARC21 standard.
>
> There different flouvers of MARC, the Library of Congress mantains USMARC
> .
> For example I use Unimarc, mantained from IFLA.
>
> A concise Unimarc  is avaible from:
> http://www.ifla.org/VI/3/p1996-1/concise2.pdf
> A full Unimarc  is avaible from:
> http://www.ifla.org/VI/3/p1996-1/sec-uni.htm
>
> The differences between MARC21 and Unimarc are  many; a good
> documentation is avaible from:
> http://www.loc.gov/marc/unimarctomarc21.html .
>  From example there are differences also in the Record Leader !!.
>
> Bye
>
>
> Zeno Tajoli
> [EMAIL PROTECTED]
> CILEA - Segrate (MI)
> 02 / 26995321

Hi all,

Are people on the list aware of the USEMARCON software 
 which claims to 
convert from one of many flavours of MARC to another?

There was a recent announcement of the latest version which I will forward 
below.

I haven't used it so can't really say anything from experience, but it's 
developed on behalf of the British Library so it's from a highly credible 
source.

Would perl wrappers around the toolkit be something worth considering?

Cheers,

Ben
-- 
Ben Soares tel: +44 (0)131-651 1238
EDINA, Edinburgh University Data Library   fax: +44 (0)131-650 3308
Main Library Building, George Square email: [EMAIL PROTECTED]
Edinburgh EH8 9LJ, Scotland, UKwww: http://edina.ac.uk/

"Hmmm, that makes no sense to me...
 But then you are very small, perhaps you're right." -- Treebeard



--  Forwarded Message  --

Subject: New version of MARC converter software
Date: Fri, 14 November, 2003 09:58
From: "Ashton, Jan" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

MARC CONVERSION SOFTWARE - USEMARCON Plus v1.4
USEMARCON is a software application that allows users to convert
bibliographic records from one MAchine-Readable Cataloguing (MARC) format
 to another. In 1995, a project
  funded by the European
 Union was set up to address the issue of differing MARC formats. The
 project was successfully completed in 1997 with the development of the
 USEMARCON (User Controlled Generic MARC Converter) software. On behalf of
 the British Library and CERL (the Committee of European Research
 Librarians) Crossnet Systems Limited
 enhanced the application to introduce new
functionality which allowed the program to be integrated more closely with
other applications for conversions, e.g. as part of a Z39.50 server.

The software has now been further developed and adapted by ATP Library
Systems Ltd, Finland to an API format. Following testing at Helsinki
University and the British Library (v1.3), this latest version of USEMARCON
(Version 1.4) makes USEMARCON more suitable for integration in other
software, mainly fast on-the-fly conversions in Z39.50 clients and
multi-threaded Z39.50 servers. The British Library and ATP Library Systems
Ltd is making the new v1.4 software and related documentation available
 free of charge to users and application developers in order to promote
 usage of USEMARCON. Potential users are, however, asked to complete a
 freeware licence to cover the use of the software.

For further information and to download the software, please visit the
British Library web site at
http://www.bl.uk/services/bibliographic/usemarcon.html

Users can also visit the newly set up USEMARCON discussion board
 to talk with other users or
developers who may be working on similar issues or projects.

For further information please contact:
ATP Library Systems Ltd, Finland by e-mail  or
visit their web site at 

or contact

The British Library
Bibliographic Standards & Systems
Boston Spa, Wetherby
West Yorkshire LS23 7BQ
United Kingdom
Tel: + 44 (0) 1937 546585
Fax: + 44 (0) 1937 546586
Email: [EMAIL PROTECTED] 



**

Opening 14 November 2003 at the British Library Galleries :

"Chinese Printmaking Today", artworks by leading Chinese artists 1980-2000

*

The information contained in this e-mail is confidential and may be legally
privileged. It is intended for the addressee(s) only. If you are not the
intended recipient, please delete this e-mail and notify the
[EMAIL PROTECTED] : The contents of this e-mail must not be disclosed or
copied without the sender's consent.

The statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the British Library. The
British Library does not take any responsibility for the views of the
author.

*

Re: Clarification on MARC::Simple Intent

[Tajoli Zeno]

Hi to all,

At 01.52 19/11/03, Morbus Iff wrote:

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?


In fact I don't subscribe this type of changes.
Why ?
Because they hard coded in the module the USMARC/MARC21 standard.
There different flouvers of MARC, the Library of Congress mantains USMARC 
.
For example I use Unimarc, mantained from IFLA.

A concise Unimarc  is avaible from: 
http://www.ifla.org/VI/3/p1996-1/concise2.pdf
A full Unimarc  is avaible from: 
http://www.ifla.org/VI/3/p1996-1/sec-uni.htm

The differences between MARC21 and Unimarc are  many; a good documentation 
is avaible from:
http://www.loc.gov/marc/unimarctomarc21.html .
From example there are differences also in the Record Leader !!.

Bye

Zeno Tajoli
[EMAIL PROTECTED]
CILEA - Segrate (MI)
02 / 26995321