Re: [CODE4LIB] Why does the MARC to DC crosswalk refuse to use Creator?

[Guenther, Rebecca]

The reason we used DC Contributor instead of Creator is because the semantics 
do not map well to MARC creators/contributors. Creators in MARC can be in 1XX 
and 7XX; since 1XX is not repeatable, additional creators go in 7XX. 
Contributors in Dublin Core play a secondary role in the resource ("An entity 
responsible for making contributions to the resource.") vs. Creator ("An entity 
primarily responsible for making the resource.").If we simply mapped the name 
in 1XX to Creator and the name in 7XX to Contributor, these may or may not be 
correct in terms of semantics. In MARC primary vs. secondary contributions are 
not what distinguish recording in 1XX vs 7XX, but the particular contribution 
that was made may be included in the role subfield ($e in textual form or $4 in 
coded form). Unfortunately we find that many MARC records do not record the 
role, but that is because of previous cataloging policy, not anything in MARC.  
 Another point is that whether the contribution is primar!
 y or secondary may vary depending on the type of material, so giving the 
specific contribution may be more useful in the long run (for instance, an 
illustrator may be considered a secondary contribution in the book world, but 
if the resource is in a museum it may be considered the primary contribution).  

It might be noted that some time ago (the year that the DC conference was in 
Florence, I can't remember exactly when that was) the Dublin Core Usage Board 
(of which I was then a member) attempted to combine creator and contributor 
(and publisher) to become one DC element (Agent), but implementers objected to 
it, so the proposal was withdrawn. But that was recognition that the 
distinction being made might not have been the best way to go. That was also a 
factor in mapping MARC to DC this way. 

Rebecca

Date:Mon, 18 Apr 2011 14:35:35 -0700
From:"Cowles, Esme" 
Subject: Re: Why does the MARC to DC crosswalk refuse to use Creator?

It looks like it's using Contributor instead.  So I'm guessing the sticking 
point is that it's hard to figure out what Contributors are primary, so it's 
safer to just punt and put them all in Contributor instead.

-Esme
--
Esme Cowles 

"During my service in the United States Congress, I took the initiative in
 creating the Internet." -- Al Gore

On Apr 18, 2011, at 5:13 PM, Luciano Ramalho wrote:

> I am mystified by the discovery that the MARC to DC Crosswalk does not
> map *any* MARC tag to the DC Creator element!
>
> http://www.loc.gov/marc/marc2dc.html
>
> Does anyone know the reasoning behind this strange decision?
>
> --
> Luciano Ramalho
> programador repentista || stand-up programmer
> Twitter: @luciano

Rebecca S. Guenther
Senior Networking and Standards Specialist
Network Development and MARC Standards Office
Library of Congress
101 Independence Ave SE
Washington, DC 20540
+1 202 707 5092 (voice)
+1 202 707 0115 (fax)
r...@loc.gov

Re: [CODE4LIB] distributed library alpha server up, feedback welcome

[Markus Fischer]

Hi Elliot

congrats, you did it!

Wish you all the best for the further development!

Markus

Am 23.04.2011 23:27, schrieb Elliot Hallmark:

All,

It was at the end of last year that I came here saying I was writing an open
source ILS for a distributed (book sharing) library.  While I had lots of
enthusiasm and time for it at the time, our development computer didn't have
the capacity to run a solr based discovery front end.  Even though the back
end was ready for feedback (though still very alpha), I dallied in posting
the IP because there was no discovery layer.

In the interest of moving forward, and since a complex discovery layer may
not be necessary for a while (not for<  100 books), here is the IP.  Please
check it out and give feed back.  Play around with whatever, this data isn't
real.

http://72.48.75.76

If this IP changes, I'll let y'all know on this thread.

Soon I would like to use this system at our private alternative
schoolin hopes that it would
facilitate folks letting us use their excellent
books, since they would be lending them, not donating them.  Having a
database keeping track of who owns the books would give a little peace of
mind.  in the future, setting up a network of libraries would be easy.

notes:

1. This is a distributed library, where a book enters the system through a
primal loan (from owner to library), and is due back at some point.  The
book or item can be further lent to a regular borrower, or to another
library (which inherits lending privilages).  extending lending privilages
must be done through the administrative back end, so it wouldn't happen
accidentally.

2. The "discovery layer" is severely crippled because I don't want to write
a indexer for our MARC records unless it becomes necessary (ie, better
searching is needed but writing a VuFind driver or integrating with Kochief
isn't yet feasible).  All books entered in this system also have MARC
records associated with them, so a solr or other front end can be added
later.

3. If you'd like to try uploading a MARC record, email it to me and I'll put
it up for anyone to enter through the cataloging app.

4. This is written in django.  Hooray for python!

5. This is not at all perfect yet.  here is my todolist so far (please add
to it):

when checking a book out, do not allow a due date later than the current
lease on the book.
subtitle, does this really need to be limited to 100 characters?
create an end of day script that:
sends emails to books that are due back soon
sends emails to books that are overdue
activate fines model and add an Fine.calcuate() method
make a legit zipcode field. current one accepts<5 digits

thanks for reading,
Elliot

Re: [CODE4LIB] distributed library alpha server up, feedback welcome

[Elliot Hallmark]

>
> Another thing that differentiates you from other small libraries
> attempting this sort of thing is your contacting of this list. Most of
> the readers here are used to big-data problems, where they're trying
> to make sense of the storage, maintenance, and display of millions of
> records, so it's a bit of work to scale the mind down to a situation
> such as yours.


True, my issues are completely different from those usually tackled here.
 But, still, some folks here may potentially be interested in the
capabilities this circulation system offers.  Also, y'all know what problems
can arise when thousands upon thousands of records accumulate, and I have no
idea what may go awry with this as it handles unexpected cases.  So, you
might have insights for me.


related to indexing records in the app:

Yes, as an intermediate between a title list and a solr catalog (VuFind,
Kochief), I could write a quick app that stores subject, author and pub date
from the MARC records and then do search with icontains queries.  That would
be then next biggish step.

@Dave.

Django is not a CMS, but a package of python libraries one would use to
write a CMS.  The poor use of the database would be my own fault, because I
write the queries (or python code which is compiled into SQL).  For
instance, every blog with a headline that contains (case sensitive)
 "Lennon" is executed with
Blog.objects.filter(entry__headline__contains='Lennon')

read more here if you like:
http://docs.djangoproject.com/en/dev/topics/db/queries/

Also, any host will support php, but only *most* of them support django at
the level of the cheapest possible plan.  At the second cheapest level,
pretty much any established host supports django.

University of Texas is switching to django for all of their internal DB
stuff like accounting and payroll for reasons that are obvious to anyone who
has used django.

Re: [CODE4LIB] distributed library alpha server up, feedback welcome

[Elliot Hallmark]

Interesting point about the checkout history.  Not displaying it
automatically is probably a good idea.  I wouldn't drop that info though, or
obscure it in the DB.

[CODE4LIB] Job Announcement: Information Architects in the DC Metro area to work for well known Federal Agency (Fort Meade)

[Patty De Anda Gates]

LAC Group seeks two Information Architects in the DC Metro area (Fort Meade, 
MD) to work for a well known Federal Agency. The IA's responsibilities include 
using advanced technical skills in designing, creating, evaluating, maintaining 
and inputting information into data management systems and Web and Intranet 
pages by using professionally accepted protocols. Must have expertise related 
to complex software or Web-based programs with direct application to the 
library or information disseminating setting.
Responsibilities:

 *   Use advanced technical skills in designing, creating, evaluating, 
maintaining and inputting information into data management systems and Web and 
Intranet pages by using professionally accepted protocols
Qualifications

 *   Must have graduated from an accredited university with a Master's degree 
in Library/Information Science, Information Management or Computer Science, 
with at least one (1) year of experience in development, evaluation and 
maintenance in off-the-shelf software or Web-based programs with direct 
application to the library or information disseminating setting
 *   Must have experience in the technical aspects of data management systems 
and/or Web page design, development and maintenance.


TO APPLY: In order to be considered please submit a cover letter and resume. To 
read more details and to apply please visit this link: 
http://bit.ly/InfoArchitectFortMeade




To view all of our currently open positions please visit: 
http://lac-group.com/lac-group/careers/

LAC Group is an Equal Opportunity/Affirmative Action employer and values 
diversity in the workforce.


Patty

Patty De Anda Gates
Communications & Projects Associate
323.302.9439 - direct
323.852.1083 - main
323.852.1093 - fax

LAC Group, 6500 Wilshire Boulevard, Suite 2240, Los Angeles, CA 90048
LAC on LinkedIn | LAC 
on 
Facebook
 | LAC on Twitter  | LAC Group Newsletter 
Sign-up
lac-group.com

The information contained in this e-mail message is confidential.  If you are 
not the intended recipient, any dissemination or copying is strictly 
prohibited.  If you think that you have received this e-mail message in error, 
please contact the sender.

Re: [CODE4LIB] distributed library alpha server up, feedback welcome

[Brice Stacey]

Props for actually making it. I remember your original email to the
list, it was brutal :P

I would suggest implementing renewals. This is a favorite for most
patrons. But also imagine the scenario where a book is due to the
original lender but doesn't mind letting you keep it longer. Currently,
you must recatalog the item. With renewals, you could just renew the
book instead. This feature would kill 2 birds with 1 stone.

Brice Stacey
Digital Library Services
University of Massachusetts Boston
brice.sta...@umb.edu
617-287-5921

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Elliot Hallmark
Sent: Saturday, April 23, 2011 5:27 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] distributed library alpha server up, feedback
welcome

All,

It was at the end of last year that I came here saying I was writing an
open
source ILS for a distributed (book sharing) library.  While I had lots
of
enthusiasm and time for it at the time, our development computer didn't
have
the capacity to run a solr based discovery front end.  Even though the
back
end was ready for feedback (though still very alpha), I dallied in
posting
the IP because there was no discovery layer.

In the interest of moving forward, and since a complex discovery layer
may
not be necessary for a while (not for < 100 books), here is the IP.
Please
check it out and give feed back.  Play around with whatever, this data
isn't
real.

http://72.48.75.76

If this IP changes, I'll let y'all know on this thread.

Soon I would like to use this system at our private alternative
schoolin hopes that it would
facilitate folks letting us use their excellent
books, since they would be lending them, not donating them.  Having a
database keeping track of who owns the books would give a little peace
of
mind.  in the future, setting up a network of libraries would be easy.

notes:

1. This is a distributed library, where a book enters the system through
a
primal loan (from owner to library), and is due back at some point.  The
book or item can be further lent to a regular borrower, or to another
library (which inherits lending privilages).  extending lending
privilages
must be done through the administrative back end, so it wouldn't happen
accidentally.

2. The "discovery layer" is severely crippled because I don't want to
write
a indexer for our MARC records unless it becomes necessary (ie, better
searching is needed but writing a VuFind driver or integrating with
Kochief
isn't yet feasible).  All books entered in this system also have MARC
records associated with them, so a solr or other front end can be added
later.

3. If you'd like to try uploading a MARC record, email it to me and I'll
put
it up for anyone to enter through the cataloging app.

4. This is written in django.  Hooray for python!

5. This is not at all perfect yet.  here is my todolist so far (please
add
to it):

when checking a book out, do not allow a due date later than the current
lease on the book.
subtitle, does this really need to be limited to 100 characters?
create an end of day script that:
   sends emails to books that are due back soon
   sends emails to books that are overdue
activate fines model and add an Fine.calcuate() method
make a legit zipcode field. current one accepts <5 digits

thanks for reading,
Elliot

Re: [CODE4LIB] distributed library alpha server up, feedback welcome

[Doran, Michael D]

> University of Texas is switching to django for all of their internal DB
> stuff like accounting and payroll for reasons that are obvious to anyone who
> has used django.

Huh?  Django may be great, but this seems highly unlikely.

-- Michael

# Michael Doran, Systems Librarian
# University of Texas at Arlington
# 817-272-5326 office
# 817-688-1926 mobile
# do...@uta.edu
# http://rocky.uta.edu/doran/

From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Elliot 
Hallmark [permafact...@gmail.com]
Sent: Monday, April 25, 2011 1:58 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] distributed library alpha server up, feedback welcome

>
> Another thing that differentiates you from other small libraries
> attempting this sort of thing is your contacting of this list. Most of
> the readers here are used to big-data problems, where they're trying
> to make sense of the storage, maintenance, and display of millions of
> records, so it's a bit of work to scale the mind down to a situation
> such as yours.


True, my issues are completely different from those usually tackled here.
 But, still, some folks here may potentially be interested in the
capabilities this circulation system offers.  Also, y'all know what problems
can arise when thousands upon thousands of records accumulate, and I have no
idea what may go awry with this as it handles unexpected cases.  So, you
might have insights for me.


related to indexing records in the app:

Yes, as an intermediate between a title list and a solr catalog (VuFind,
Kochief), I could write a quick app that stores subject, author and pub date
from the MARC records and then do search with icontains queries.  That would
be then next biggish step.

@Dave.

Django is not a CMS, but a package of python libraries one would use to
write a CMS.  The poor use of the database would be my own fault, because I
write the queries (or python code which is compiled into SQL).  For
instance, every blog with a headline that contains (case sensitive)
 "Lennon" is executed with
Blog.objects.filter(entry__headline__contains='Lennon')

read more here if you like:
http://docs.djangoproject.com/en/dev/topics/db/queries/

Also, any host will support php, but only *most* of them support django at
the level of the cheapest possible plan.  At the second cheapest level,
pretty much any established host supports django.

University of Texas is switching to django for all of their internal DB
stuff like accounting and payroll for reasons that are obvious to anyone who
has used django.

[CODE4LIB] Google Book Search and Millennium

[Patrick Berry]

Hi,

We're working on "integrating" links to Google Books from Millennium.  I'm
not a fan of rewritting things from scratch, so I've borrowed heavily from
those that already have this working.  Props to the gbsclasses.js folks,
MSU, and Temple.  One thing I noticed is that IE 9 (perhaps earlier versions
as well) do not work with the code in use at MSU and Temple on the
bib_display.html templates.

I've done some clean-up on a static example:
http://www.csuchico.edu/~pberry/google-books/

Questions? Comments? DMCA notices?

Pat in Chico

Re: [CODE4LIB] distributed library alpha server up, feedback welcome

[Elliot Hallmark]

@brice:  good point, its on the list now

@michael:

>> University of Texas is switching to django for all of their internal DB
> >stuff like accounting and payroll for reasons that are obvious to anyone
who
> >has used django.

>Huh?  Django may be great, but this seems highly unlikely.

I may very well not have the correct information. But (just in theory) it
would be the work of an hour to map any database schema into django and then
use the python shell to navigate your database instead of raw sql.  HUGE
improvement right there (human readable inner joins, simple 'or'
relationships in queries, and on and on).  as an added bonus, all the data
you pull out is then immediately accessible to other python functions and
libraries.

I'm not saying they are writing a pretty web interface.

Also, I could have been misinformed or misunderstood the UT austin CS
student I heard this from.

[CODE4LIB] Code4lib North approaching, hackfest ideas wanted!

[John Fink]

Hey folks,

Code4Lib North is fast approaching! It's on for May 5-6, and we need your
hackfest ideas for our full day hackfest. If you've got any, please send
them along to me at john.f...@gmail.com -- I'd love to hear them and get
people working on them. Thanks!

jf

Re: [CODE4LIB] Google Book Search and Millennium

[Gabriel Farrell]

Nice work, Patrick. You reminded me I never mentioned on this list the
III Refworks Export script I put up on GitHub (see the code for props
to those who did most of the work). It's at
https://github.com/gsf/refworksexport. Maybe we should start
collecting these under a "iiihacks" GitHub org.

On Mon, Apr 25, 2011 at 5:48 PM, Patrick Berry  wrote:
> Hi,
>
> We're working on "integrating" links to Google Books from Millennium.  I'm
> not a fan of rewritting things from scratch, so I've borrowed heavily from
> those that already have this working.  Props to the gbsclasses.js folks,
> MSU, and Temple.  One thing I noticed is that IE 9 (perhaps earlier versions
> as well) do not work with the code in use at MSU and Temple on the
> bib_display.html templates.
>
> I've done some clean-up on a static example:
> http://www.csuchico.edu/~pberry/google-books/
>
> Questions? Comments? DMCA notices?
>
> Pat in Chico
>

Re: [CODE4LIB] Why does the MARC to DC crosswalk refuse to use Creator?

[Luciano Ramalho]

Thank you very much Rebecca, Karen and Esme for your replies. It is
really a privilege to be able to ask a question here and get answers
like these.

Regarding the DC Creator issue, I probably nave a different
perspective on DC than many here, because my first contact with DC was
not as a librarian but as a content management specialist. In the
content management community DC is widely adopted, but a lot (most) of
the metadata one finds in a CMS is new, born digital and often created
by users directly inside the system itself (think of a blog post).
Also, in a CMS most metadata is generated by users without any
knowledge of cataloging best practices, so the simplicity of
unqualified DC is adequate. These factors make it very desirable to
have a simple Creator attribute, which is often a very important
search criteria for users. That is why I found it strange that LC
chose not to map any tag to Creator.

Now with my librarian hat on, and your explanations, the reasoning is
very clear.

Thanks a lot!

Cheers,

Luciano


On Mon, Apr 25, 2011 at 11:58 AM, Guenther, Rebecca  wrote:
> The reason we used DC Contributor instead of Creator is because the semantics 
> do not map well to MARC creators/contributors. Creators in MARC can be in 1XX 
> and 7XX; since 1XX is not repeatable, additional creators go in 7XX. 
> Contributors in Dublin Core play a secondary role in the resource ("An entity 
> responsible for making contributions to the resource.") vs. Creator ("An 
> entity primarily responsible for making the resource.").If we simply mapped 
> the name in 1XX to Creator and the name in 7XX to Contributor, these may or 
> may not be correct in terms of semantics. In MARC primary vs. secondary 
> contributions are not what distinguish recording in 1XX vs 7XX, but the 
> particular contribution that was made may be included in the role subfield 
> ($e in textual form or $4 in coded form). Unfortunately we find that many 
> MARC records do not record the role, but that is because of previous 
> cataloging policy, not anything in MARC.   Another point is that whether the 
> contribution is prim!
 ar!
>  y or secondary may vary depending on the type of material, so giving the 
> specific contribution may be more useful in the long run (for instance, an 
> illustrator may be considered a secondary contribution in the book world, but 
> if the resource is in a museum it may be considered the primary contribution).
>
> It might be noted that some time ago (the year that the DC conference was in 
> Florence, I can't remember exactly when that was) the Dublin Core Usage Board 
> (of which I was then a member) attempted to combine creator and contributor 
> (and publisher) to become one DC element (Agent), but implementers objected 
> to it, so the proposal was withdrawn. But that was recognition that the 
> distinction being made might not have been the best way to go. That was also 
> a factor in mapping MARC to DC this way.
>
> Rebecca
>
> Date:    Mon, 18 Apr 2011 14:35:35 -0700
> From:    "Cowles, Esme" 
> Subject: Re: Why does the MARC to DC crosswalk refuse to use Creator?
>
> It looks like it's using Contributor instead.  So I'm guessing the sticking 
> point is that it's hard to figure out what Contributors are primary, so it's 
> safer to just punt and put them all in Contributor instead.
>
> -Esme
> --
> Esme Cowles 
>
> "During my service in the United States Congress, I took the initiative in
>  creating the Internet." -- Al Gore
>
> On Apr 18, 2011, at 5:13 PM, Luciano Ramalho wrote:
>
>> I am mystified by the discovery that the MARC to DC Crosswalk does not
>> map *any* MARC tag to the DC Creator element!
>>
>> http://www.loc.gov/marc/marc2dc.html
>>
>> Does anyone know the reasoning behind this strange decision?
>>
>> --
>> Luciano Ramalho
>> programador repentista || stand-up programmer
>> Twitter: @luciano
>
> Rebecca S. Guenther
> Senior Networking and Standards Specialist
> Network Development and MARC Standards Office
> Library of Congress
> 101 Independence Ave SE
> Washington, DC 20540
> +1 202 707 5092 (voice)
> +1 202 707 0115 (fax)
> r...@loc.gov
>



-- 
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano