Re: [important] copyrightdate is not loaded into biblio table
Hi, Paul - You asked for opinions about the copyrightdate:
So, we have 2 solutions (both being easy to code) : * modify the DB structure to have a char, and copyrightdate would be : "c1968, reedited 1985, something else 1995" in my sample. (con : Maybe a little too many info for OPAC ?) * modify the import tool to extract the 1st "date" in the string (mean, the 1st time where 4 digits are found) : "1968" in my sample. (con : risk to choose a date that is not really a copyrightdate)
Which solution do readers of this list prefer ?
My first reaction is that there's no such thing as too much information, even in an OPAC, which would indicate that your first solution is the best. However, what about searching? For example, if I want to find books about space stations published since 1993, can I do that if the copyrightdate column contains "c1993" or "reedited 1993?" Stephen
Stephen Hedges wrote:
Hi, Paul -
You asked for opinions about the copyrightdate:
So, we have 2 solutions (both being easy to code) : * modify the DB structure to have a char, and copyrightdate would be : "c1968, reedited 1985, something else 1995" in my sample. (con : Maybe a little too many info for OPAC ?) * modify the import tool to extract the 1st "date" in the string (mean, the 1st time where 4 digits are found) : "1968" in my sample. (con : risk to choose a date that is not really a copyrightdate)
Which solution do readers of this list prefer ?
My first reaction is that there's no such thing as too much information, even in an OPAC, which would indicate that your first solution is the best. However, what about searching? For example, if I want to find books about space stations published since 1993, can I do that if the copyrightdate column contains "c1993" or "reedited 1993?"
Stephen
In the MARC part of the DB, the complete 260c field will be stored, of course. So it's possible for the librarian to find what you asked. The numeric value is only for the koha-DB. This one is used in opac search (although it should be possible & easy to add MARC search in opac too), and in some lists. For example, when you search for a book, the list shows title, author, copyrightdate & nb of items. with this explanation, do you change your mind & agree with rosalie ? OTHERS : please feel free to argue. Even if it's a minor point from a functionnal point of view, it's an important one, as the decision, once taken, can't be rolled back easily. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Stephen Hedges wrote:
Hi, Paul -
You asked for opinions about the copyrightdate:
So, we have 2 solutions (both being easy to code) : * modify the DB structure to have a char, and copyrightdate would be : "c1968, reedited 1985, something else 1995" in my sample. (con : Maybe a little too many info for OPAC ?) * modify the import tool to extract the 1st "date" in the string (mean, the 1st time where 4 digits are found) : "1968" in my sample. (con : risk to choose a date that is not really a copyrightdate)
Which solution do readers of this list prefer ?
My first reaction is that there's no such thing as too much information, even in an OPAC, which would indicate that your first solution is the best. However, what about searching? For example, if I want to find books about space stations published since 1993, can I do that if the copyrightdate column contains "c1993" or "reedited 1993?"
Stephen
In the MARC part of the DB, the complete 260c field will be stored, of course. So it's possible for the librarian to find what you asked. The numeric value is only for the koha-DB. This one is used in opac search (although it should be possible & easy to add MARC search in opac too), and in some lists. For example, when you search for a book, the list shows title, author, copyrightdate & nb of items.
with this explanation, do you change your mind & agree with rosalie ?
OTHERS : please feel free to argue. Even if it's a minor point from a functionnal point of view, it's an important one, as the decision, once taken, can't be rolled back easily. Since the decision won't be rolled back, I think it would be better to go for the richest (first) solution : you'll always find someone later who will have some special need and will went as much information as
Le mar 08/07/2003 à 12:00, paul POULAIN a écrit : possible. My 2 cts. Nicolas
-- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (3)
-
Nicolas Morin -
paul POULAIN -
Stephen Hedges