Open varnum opened 8 years ago
bertrama
commented
8 years ago %5B%5D decodes to []. The variable name I'm aiming at isn't lookfor, it's lookfor[]. Same thing with type[].
Looks to be understood perfectly the way it is in this case. To verify manually, try an advanced search in Mirlyn:
Title Starts With: Dictionary of information and library management ISSN/ISBN: 0713675918
varnum
commented
8 years ago Ahh... My mistake.
Still, the Mirlyn advanced search generated by filling in those two fields fails the same way. It treats it as an empty search, with the error message "Your search - - did not match any resources."
I guess I can't blame Umlaut for that.
varnum
commented
8 years ago I'm moving this into the beta milestone. Links from Umlaut to Mirlyn are giving no results, when a simple everywhere title search will pull up the item. I think we talked about this earlier this week, and simply didn't assign this item to the milestone. @bertrama
bertrama
commented
8 years ago I'll need an actual specification if you want it to do something different. And examples of the desired behavior you'd like to see. The example I have been using works fine for me. And the behavior makes sense to me.
What doesn't make sense to me is only doing title searches when the openurl has more specific information. If the openurl says "Get me the book with 'this title' and 'that isbn' becomes get me "any book with that in the title". Well. That can break down quickly.
Compare:
varnum
commented
8 years ago Those examples both work very well.
The one I cited at the top of this thread, though -- https://earleyj.www.lib.umich.edu/testapp/mgetit/go/163 -- doesn't. It's for a book chapter in "Dictionary of Information and Library Management", ISBN: 0713675918. The Mirlyn search link is to http://mirlyn.lib.umich.edu/Search/Home?bool%5B%5D=AND&fqor-publishDateTrie%5B%5D=2006&lookfor%5B%5D=dictionary+of+information+and+library+management&lookfor%5B%5D=0713675918&method=atom&page=0&type%5B%5D=title_starts_with&type%5B%5D=isn which pulls up an empty page, with an empty search box. A title search for "Dictionary of Information and Library Management" succeeds in pulling up the item. (The ISBN search fails.)
Other examples where the "search the catalog" link fails to find the journal title (by title) are: https://earleyj.www.lib.umich.edu/testapp/mgetit/go/618 https://earleyj.www.lib.umich.edu/testapp/mgetit/go/619
From what testing I've done, I think a title search for the item is more reliable. I've had a rough time with standard number searches in my tests; by whatever set of chances, they simply haven't succeeded.
bertrama
commented
8 years ago How do you define reliable, then?
For permalink 163, that citation isn't even the same thing as the mirlyn record. The titles are different, and the ISBNs are different. From a data integrity standpoint, that's about as different as "Dewey defeats Truman" is from "Truman defeats Dewey". And, yes, as a human looking at the record for 163, and looking at the 2006 publication with the isbn in the citation, I can see that they're related, but unless we put that into the catalog I don't think we should be watering down our service so much that we find similar things for a known-citation-search. We should make it easier to recover, when you get there, but I don't think we should start off with the bar so low.
That said. American scientist doesn't show up for a title starts with American scientist. I don't know why that is, but it's problematic to be sure. Ratcheting back to title with text wrapped in quotes might make sense. Also, Mirlyn can't reason about dates very well, so dropping the publication date from the citation for journals also makes sense.
These issns are in the solr index, but the mirlyn front-end isn't finding them. That's another problem, and I'm willing to work around it in the short term, but I think it's a poor choice to just give up on them in the long-term.
varnum
commented
8 years ago I get your point about the exact citation not leading to a reliable record. I think you are right.
However, from a usability perspective, I think getting the user to a Mirlyn screen that reports that the search looked for "" and found nothing is not helpful. It looks to the user like the link is broken, not that there's nothing there.
Fixing Mirlyn is probably beyond our scope, but I'm uncomfortable sending users (and from my testing, most cases when I follow a "search the catalog" link results in something similar) to an apparently bad location. Can the search query (even if not the field) be sent in such a way that Mirlyn populates the search box with it?
Ken Varnum Senior Program Manager for Discovery, Delivery, and Library Analytics Library Information Technology | University of Michigan Library varnum@umich.edu | @varnum | 734-615-3287 http://www.lib.umich.edu/users/varnum
On Wed, Aug 31, 2016 at 1:28 PM, Albert Bertram notifications@github.com wrote:
How do you define reliable, then?
For permalink 163 https://earleyj.www.lib.umich.edu/testapp/mgetit/go/163, that citation isn't even the same thing as the mirlyn record. The titles are different, and the ISBNs are different. From a data integrity standpoint, that's about as different as "Dewey defeats Truman http://mirlyn.lib.umich.edu/Search/Home?checkspelling=true&inst=aa&showsearchonly=false&oft=false&lookfor=%22Dewey+defeats+Truman%22&type=all&submit=Find&use_dismax=1" is from "Truman defeats Dewey http://mirlyn.lib.umich.edu/Search/Home?checkspelling=true&inst=aa&showsearchonly=false&oft=false&lookfor=%22Truman+defeats+Dewey%22&type=all&submit=Find&use_dismax=1". And, yes, as a human looking at the record for 163, and looking at the 2006 publication with the isbn in the citation, I can see that they're related, but unless we put that into the catalog I don't think we should be watering down our service so much that we find similar things for a known-citation-search. We should make it easier to recover, when you get there, but I don't think we should start off with the bar so low.
That said. American scientist doesn't show up for a title starts with American scientist. I don't know why that is, but it's problematic to be sure. Ratcheting back to title with text wrapped in quotes might make sense. Also, Mirlyn can't reason about dates very well, so dropping the publication date from the citation for journals also makes sense.
These issns are in the solr index, but the mirlyn front-end isn't finding them. That's another problem, and I'm willing to work around it in the short term, but I think it's a poor choice to just give up on them in the long-term.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mlibrary/mgetit/issues/24#issuecomment-243838686, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ7bL_LVstKh6cifYaLrTBfKAH6jSTytks5qlbnbgaJpZM4JiK7e .
varnum
commented
8 years ago I think we should talk about the catalog link's desired behavior at tomorrow's Umlaut team meeting. Albert, would you be able to talk briefly about what it's currently doing and what kinds of alternatives there are for changing the behavior? @bertrama
The catalog link from this record -- https://earleyj.www.lib.umich.edu/testapp/mgetit/go/163 -- goes to http://mirlyn.lib.umich.edu/Search/Home?fqor-publishDateTrie%5B%5D=2006&lookfor%5B%5D=dictionary+of+information+and+library+management&lookfor%5B%5D=0713675918&method=atom&page=0&type%5B%5D=title_starts_with&type%5B%5D=isn
The "lookfor" value isn't understood when Mirlyn gets it. I think the "=" is redundantly encoded?
http://mirlyn.lib.umich.edu/Search/Home?fqor-publishDateTrie=2006&lookfor=dictionary+of+information+and+library+management&lookfor=0713675918&method=atom&page=0&type=title_starts_with&type=isn
That doesn't actually result in a search, but it puts the right text in the search box in Mirlyn.