#461: Authorpages: Interface with BibauthorID backend
------------------------+---------------------------------------------------
Reporter: hweiler | Owner: hweiler
Type: defect | Status: assigned
Priority: blocker | Milestone: v1.0
Component: WebSearch | Version:
Resolution: | Keywords: Authorpages, Bibauthorid, exact search
fallback
------------------------+---------------------------------------------------
Comment (by tbrooks):
Replying to [comment:4 hweiler]:
> Replying to [comment:1 simko]:
>
> > 1) Frequent co-authors: too many are offered, listed author links are
> > loosing =Ellis, J= co-author, so they are not pointing to co-authored
> > papers with the given author, which is the whole point of the Frequent
> > co-authors box.
>
> Yes. We discussed the length of the list and forgot to actually put in
the changes in the process. Will use the variable priorly introduced for
that purpose.
Indeed we discussed this on Friday as well and I think the previous limits
are the right ones.
>
> The link behavior, like in all of the cases, is trickier: The thing used
to perform an exact author search (on coauth name) with the extension of
the author's name. We'll have to create search query that takes into
account all of the name variants. Ideas on how to construct such a query
are most welcome.
AS we were driving to PLoS on friday we had discussed an API in to allow
searching by authorID. This would be something like AID:34234 which gets
passed to BAI by s_e and then returns a hitset. This to me seems the
ideal, to allow s_e to search by AID, then generating links is trivial.
This is a non-trivial enhancement to the functionality (though one that
was definitely on the roadmap), but it is the _only_ way that it will work
other than by recID, since clearly the entire point of the clusters is
that they are not defined by any author or exact author search string.
I would tend to think that the current recID links should be made to work
correctly (which they are _NOT_ currently in citations and co-authors at
least) using just recIDs, which should be a small (and URGENT) bugfix.
Then we can implement the real solution which is to allow AID searching
through s_e which allows real link generation.
> The recid link target has been used to cope with the author name
variants. Any thoughts here on how to do this (tried "exactauthor:variant1
AND exactauthor:variant2", which somehow did not work?!)? The recid search
has been used priorly for the affiliation search links only.
>
> > 3) Frequent keywords: links are completely broken.
> >
> > 4) Citations: offered links are loosing author name again, just like
> > in the Frequent co-authors box, so user is not getting what is being
> > advertized.
>
> again: how to handle name variants?!
>
But again, these links are broken completely as is. Not an issue of name
variants. Needs to at very least use the recID method since currently
the links are nonsense.
Let me know if I can be of assistance in this as I view it as an URGENT
matter and am ready to devote time to fixing it today (and tomorrow).
> > 5) In HTML brief format, author links used to point to a search query
> > for the given author giving all his publications, not to his author
> > page. This branch changes that, which is a visible functionality
> > change, so it should be wrapped by some `CFG_WEBSEARCH_AUTHOR_LINK`
> > variable in these release candidate times, keeping the default
> > unchanged, as it used to be before. Or, better said, you can just
> > introduce a new optional parameter to bfe_authors like
> > `link_to_author_page` that people could set to 0 or 1 in their BFTs in
> > order to achieve the effect they want (either linking to author pages
> > or to publication list).
>
> AH...perfect. Will change that to use a variable in the bfe.
OK, but please note that in INSPIRE the default has always been the author
pages, so the INSPIRE behavior should remain unchanged (linking to author
pages)
--
Ticket URL: <http://invenio-software.org/ticket/461#comment:6>
Invenio <http://invenio-software.org>
