Not sure if this belongs here, or in help, but hee goes.
I want to extend Lookup.php functionality to allow searching by title and author. This will result in almost always receiving multiple hits. My proposed solution is in the event of multiple hits to display a list of the hits similar to the LOC search page, allow the user to make a selection, and then post the selected document's parameters to the various fields. But this requires that the array ($ar) of MARC records received to be maintained from one page to another - a registered session varianble. Seems straight forward enough, but I am concerned with space requirements at the server. Any of the developers have any thoughts on this?
If this works out, it will also handle the case of multiple hits on LCCN entries with multiple documents. Something I run into regularly.
Fred
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A session variable is fine so long as you limit the number of items that can go into it -- what if somebody accidentally searches for "house" or "smith"?. Say you allow 20 MARC records to be saved in the session, then, assuming .5k per record, you'll use 10k in the session file. I don't think that should cause any problem.
You could allow for more results by keeping track of where you are at and loading the next 20 (or whatever) on user request.
You could make it go further by not storing the complete MARC record, just the fields you want to display along with some unique identifier. When the user wants to add particular records to the DB, you can look up the unique identifiers and load the full records from the server.
FWIW, 0.6.0 will be storing session data in the database, so space for it won't be a separate concern for administrators.
Micah
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Micah. as it turns out I dont need to store anything. Found an alternative solution.
Seperate (but related) matter:
--------------------------
I have a new release about ready. It will handle multiple hit searches in a reasonable way. But I am holding it up while I try to get a cutter code generator working for use with dewey and local call numbers. Personally I like the cutter-sanborn tables and currently I use a standalone program from OCLC for that. But using it is clumsy for the average library worker, and I would prefer something as a part of OpenBiblio.
I have implemented a simple method based on what is reputed to have been used at one time by US LOC. Works, but it is crude and the codes don't match cutter - sanborn very well.
Do you, or any others, know of something for cutter codes that is callable from within a PHP script? I would prefer not to spend too much time on re - inventing the wheel.
Fred LaPlante
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, I'm an engineer , not a librarian, so I probably am using the wrong name for this 'thing'. I am referring to the 2nd part of the call number. The first part specifies the subject area: PZxx.xx or 813.xx for fiction. The second is typically a alpha-numeric designation for the author & title: M1694p for a book by McNaught titled "Perfect". What documentation I have referrs to this part as a "cutter". Probably named for the guy that came up with the scheme back around 1900 to sort out large collections of books on a single subject.
Fred LaPlante
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure if the following link is of any use to you (you have to enable Pop-ups -- yuk!), but in many University Libraries in Bavaria a modified form of the LC Classification Scheme has been adopted (it is called the Regensburger Verbundklassifikation = Regensburg Union Classification) for which we need the Cutter-Sanborn tables. An internal DOS-like program has been developed for these tables in Regensburg, but the University of Eichstaett offers an online-variant which I usually use for classifying: http://nonbook.ku-eichstaett.de/cgi-bin/cutterjo.pl?win=b
chris dot dagleish at gmx dot de
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fred, I've got Lookup configured in my home system and it works very well for some things. However, for my z39.50 lookup, I'm actually using the AMICUS system in Canada. It's got a ton of information, with one minor problem... It regularly gives back multiple results for the same item. So when you redo the search with the other fields filled in, it doesn't actually narrow the search down at all and I end up with all the same results.
Is there any way to have it store a unique identifier for each listed result to avoid that problem? A hidden field in the form would probably work for this, assuming there is some sort of unique identifier.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey, no need to appologize. If I wasn't interested in comments, I would have kept the lookup program to myself. I enjoy questions like yours because it gives me the necessary motivation to making the program even more useful.
I have seen occasions where the number of hits was too great to even display. a recent search for a work of charles Dickens comes to mind. I think there were several hundred hits.
I guess I am not sure how the unique identifier would help. You need to help me there. Do you think that simply having more than 2 input fields would be helpful. US LoC z3950 page has 3 fields, but I could easily have more, and could probably have the number of fields be selectable in the lookup_conf.php file.
Fred LaPlante
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, if each returned result had a unique identifier of some sort, you could just do the second search on that identifier and be certain that you'd always end up with exactly one result. It's the same idea as having a primary key in a database table... it gives you something that will always be unique. I don't know if a z3950 search can give you that though... Maybe I'll play with it tonight and see if I can come up with anything for you.
The reason it's a problem for us is because the AMICUS system (from what my wife tells me) contains all the records from all the member libraries, which is a good number of libraries around Canada. Since a lot of the books we own are in more than one library, and not every library catalogues exactly the same way, we seem to keep getting extra hits.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I see what you mean. Most databases would have such a ky of course, but to the best of my knowledge, there is no such key returned in the Z3950 protocol. but perhaps more to the point, there is a limited number of search attributes supported. You can see the entire list at http://www.loc.gov/z3950/lcserver.html#usea for US LoC. If you server has a different set of atributes suported that can be used and I will be happy to add that capability.
But, again, would additional attrubutes beyond the current 2 be helpful? I have been considering adding 1018 - name of publisher, just haven't gotten around to it.
Fred
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Chris,
I'd like to pursue this issue a bit more. So I have registered with the AMICUS Z39.50 service assuming that you use that service rather than the limited, more public, NLC Z39.50 service they also offer.
It would also be useful to have a couple of book title / author combinations for which your problem occurs. I am hoping to find some sort of combination of Title, author, publisher, etc that would make a particular volume unique. I used to think that an ISBN would fit the bill, but that ballon burst some time ago.
Fred
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure if this belongs here, or in help, but hee goes.
I want to extend Lookup.php functionality to allow searching by title and author. This will result in almost always receiving multiple hits. My proposed solution is in the event of multiple hits to display a list of the hits similar to the LOC search page, allow the user to make a selection, and then post the selected document's parameters to the various fields. But this requires that the array ($ar) of MARC records received to be maintained from one page to another - a registered session varianble. Seems straight forward enough, but I am concerned with space requirements at the server. Any of the developers have any thoughts on this?
If this works out, it will also handle the case of multiple hits on LCCN entries with multiple documents. Something I run into regularly.
Fred
A session variable is fine so long as you limit the number of items that can go into it -- what if somebody accidentally searches for "house" or "smith"?. Say you allow 20 MARC records to be saved in the session, then, assuming .5k per record, you'll use 10k in the session file. I don't think that should cause any problem.
You could allow for more results by keeping track of where you are at and loading the next 20 (or whatever) on user request.
You could make it go further by not storing the complete MARC record, just the fields you want to display along with some unique identifier. When the user wants to add particular records to the DB, you can look up the unique identifiers and load the full records from the server.
FWIW, 0.6.0 will be storing session data in the database, so space for it won't be a separate concern for administrators.
Micah
Thanks Micah. as it turns out I dont need to store anything. Found an alternative solution.
Seperate (but related) matter:
--------------------------
I have a new release about ready. It will handle multiple hit searches in a reasonable way. But I am holding it up while I try to get a cutter code generator working for use with dewey and local call numbers. Personally I like the cutter-sanborn tables and currently I use a standalone program from OCLC for that. But using it is clumsy for the average library worker, and I would prefer something as a part of OpenBiblio.
I have implemented a simple method based on what is reputed to have been used at one time by US LOC. Works, but it is crude and the codes don't match cutter - sanborn very well.
Do you, or any others, know of something for cutter codes that is callable from within a PHP script? I would prefer not to spend too much time on re - inventing the wheel.
Fred LaPlante
I don't think I can be of any help as your post was the first time I'd really heard of cutter codes. None of my libraries use them, afaik.
Hopefully somebody else knows,
Micah
well, I'm an engineer , not a librarian, so I probably am using the wrong name for this 'thing'. I am referring to the 2nd part of the call number. The first part specifies the subject area: PZxx.xx or 813.xx for fiction. The second is typically a alpha-numeric designation for the author & title: M1694p for a book by McNaught titled "Perfect". What documentation I have referrs to this part as a "cutter". Probably named for the guy that came up with the scheme back around 1900 to sort out large collections of books on a single subject.
Fred LaPlante
I am not sure if the following link is of any use to you (you have to enable Pop-ups -- yuk!), but in many University Libraries in Bavaria a modified form of the LC Classification Scheme has been adopted (it is called the Regensburger Verbundklassifikation = Regensburg Union Classification) for which we need the Cutter-Sanborn tables. An internal DOS-like program has been developed for these tables in Regensburg, but the University of Eichstaett offers an online-variant which I usually use for classifying:
http://nonbook.ku-eichstaett.de/cgi-bin/cutterjo.pl?win=b
chris dot dagleish at gmx dot de
Sorry to drag up an old issue...
Fred, I've got Lookup configured in my home system and it works very well for some things. However, for my z39.50 lookup, I'm actually using the AMICUS system in Canada. It's got a ton of information, with one minor problem... It regularly gives back multiple results for the same item. So when you redo the search with the other fields filled in, it doesn't actually narrow the search down at all and I end up with all the same results.
Is there any way to have it store a unique identifier for each listed result to avoid that problem? A hidden field in the form would probably work for this, assuming there is some sort of unique identifier.
Hey, no need to appologize. If I wasn't interested in comments, I would have kept the lookup program to myself. I enjoy questions like yours because it gives me the necessary motivation to making the program even more useful.
I have seen occasions where the number of hits was too great to even display. a recent search for a work of charles Dickens comes to mind. I think there were several hundred hits.
I guess I am not sure how the unique identifier would help. You need to help me there. Do you think that simply having more than 2 input fields would be helpful. US LoC z3950 page has 3 fields, but I could easily have more, and could probably have the number of fields be selectable in the lookup_conf.php file.
Fred LaPlante
Well, if each returned result had a unique identifier of some sort, you could just do the second search on that identifier and be certain that you'd always end up with exactly one result. It's the same idea as having a primary key in a database table... it gives you something that will always be unique. I don't know if a z3950 search can give you that though... Maybe I'll play with it tonight and see if I can come up with anything for you.
The reason it's a problem for us is because the AMICUS system (from what my wife tells me) contains all the records from all the member libraries, which is a good number of libraries around Canada. Since a lot of the books we own are in more than one library, and not every library catalogues exactly the same way, we seem to keep getting extra hits.
OK, I see what you mean. Most databases would have such a ky of course, but to the best of my knowledge, there is no such key returned in the Z3950 protocol. but perhaps more to the point, there is a limited number of search attributes supported. You can see the entire list at http://www.loc.gov/z3950/lcserver.html#usea for US LoC. If you server has a different set of atributes suported that can be used and I will be happy to add that capability.
But, again, would additional attrubutes beyond the current 2 be helpful? I have been considering adding 1018 - name of publisher, just haven't gotten around to it.
Fred
Chris,
I'd like to pursue this issue a bit more. So I have registered with the AMICUS Z39.50 service assuming that you use that service rather than the limited, more public, NLC Z39.50 service they also offer.
It would also be useful to have a couple of book title / author combinations for which your problem occurs. I am hoping to find some sort of combination of Title, author, publisher, etc that would make a particular volume unique. I used to think that an ISBN would fit the bill, but that ballon burst some time ago.
Fred