[openbiblio-dev] Next JISC openbiblio 2 sprints

[Jim Pitman]

Mark, good to see these plans, some comments inline below.

> FRONTEND UI
> The current bibserver code relies on a mix of python and javascript to
> serve up the frontend. However, without javascript, it is farily
> rudimentary. In addition, future plans to enable automatic pulling of
> interesting data about a record at time of view are best done on javascript. 

I guess this means AJAX? 
Microsoft Academic Search and Google Scholar provide citation data. From Microsoft
we can citation data in real time via their API, for which I have a primitive python parser which could
probably be redone in javascript. I also have code  to scrape Google Scholar for citation data, but they may not be 
so cooperative about letting us do that. What other sources did  you have in mind? 

> EDITABILITY
> Updating records with any sort of useful info such as links out to
> other resources requires the UI to be able to save data back. I have
> got this experimentally working and want to continue building it in
> conjunction with the frontend UI improvements.

I also would like to see this capability. But I am concerned that this is difficult, and increases considerably
the burden on a bibserver maintainer to manage permissions and access. I think we should see widespread deployment of
very basic essentially read-only bibserver and get  feedback from that before raising the stakes too much with permissons management. 
There are all kinds of issues around integration of access permissions for the bibserver with local access permissions. e.g. in my department 
I have departmental logins, university logins, and then one could use google or okfn logins. Noone wants another login just for a bibserver account. 
So I see the main issue around editing of records to be the socio-technical one of how the permissions will be managed for particular bibserver installations
without any increased admin overhead on whoever is currently responsible for managing access to computers for the
organization hosting the bibserver. Solving this problem is much more difficult than provision of the frontend
UI, and a frontend editing UI will be largely useless without solving the permissions problem.
The most optimistic usecase I imagine is that cottagelabs is willing to manage permissions on a large scale
as part of a SaaS offering. Is that the case?  e.g. for a few thousand people in the probability community, can
cottagelabs manage all the authentication and logins, email, privacy, lost passwords, ....?  If so at what cost per year?
If not cottagelabs, then who is willing to do this? Until some agent steps up to play this role,  I think we should be stingy about committing
resources to editing capability, and generous with committing resources to connect bibserver search and display capabilities with
data sources which already provide editing capability, like BibSonomy, Zotero, Mendeley, CiteUlike, Open Scholar, JabRef, .....
It will be a long time before we can compete directly with any of these for gaining accounts of individual users. 

> PARSER SEPARATION
>
> The current parsers that we have are available via /parse, but should
> be separated out as a stand-alone service. documentation of their
> operation will also help others to write and maintain parsers. Propose
> Etienne takes charge of this.

Strong support from me. I have already started using the BibTeX parser as a standalone tool for command line access to
BibTeX stores for my own research group, and would like to do the same for other sources. Finding ways to integrate these
parsers into e.g. typical LaTeX/BibTeX workflows and other desktop tasks of individual scholars may be very fruitful.
I foresee a workflow where biblio curators may use the parsers directly on their machines, without direct connection
to a BibServer, to acquire data from remote sources, convert it to BibJSON, do some preprocessing with e.g. Google Refine or
other biblio processing tools which I have been developing, then upload the product of such efforts to a BibServer for display
and sharing.

> DOCUMENTATION
> We have booted some dev docs space at readthedocs, and now need to
> fill it with useful information. We also need to continue the blog
> posts, how-tos, videos, screencasts. Propose this is a combination of
> Mark, Etienne, Rufus on the code side, and Peter and Jim on the videos / how-tos side.

OK. I'll be glad to contribute to text documentation which I think is very important. I'm not so
keen on videos, but there is Peter's strength, and others will appreciate that.

> COMMUNITY
> We have a listing of various open datasets, and some example
> collections are on the way. Also, via this and the open-bibliography
> list we have lots of very helpful people telling us of more datasets.
> We also have thedatahub group managed by Adrian. Propose Naomi follows
> up with these and looks for people interested in running a bibserver
> and advertising it on bibkn.org, or outputting BibJSON, or opening up
> more data, or agreeing to open biblio principles. Also Naomi and Mark
> to maintain blog posting on openbiblio.net and meeting JISC requirements.
> EVENTS
> Naomi is already moving forward with co-ordinating sprint meetings and
> a larger event in combination with DevCSI, and she will be taking this
> forward and looking for beneficial opportunities with other coord team
> members / events.

All good.

Many thanks Mark for all your efforts!

--Jim
----------------------------------------------
Jim Pitman
Professor of Statistics and Mathematics
University of California
367 Evans Hall # 3860
Berkeley, CA 94720-3860

ph: 510-642-9970  fax: 510-642-7892
e-mail: pitman at stat.berkeley.edu
URL: http://www.stat.berkeley.edu/users/pitman