[OPEN-ILS-DEV] Making Evergreen a bit more social

[Dan Scott]

On Mon, Oct 11, 2010 at 09:54:41AM -0400, Mike Rylander wrote:
> On Mon, Oct 11, 2010 at 8:56 AM, Galen Charlton <gmc at esilibrary.com> wrote:
> >> Also in the yet-to-add camp is the actual UI for adding a rating,
> >> review, or tag to a given item. I've sketched out a rough schema for
> >> each, but the schema built in some assumptions that I'm now questioning.
> >> For example, I put "approver" and "approval_date" columns on the
> >> social.user_review table, thinking that libraries would want to approve
> >> every user-generated review before it is publicized, but I'm leaning
> >> towards providing a user-flagging mechanism instead (so that users'
> >> reviews would be published immediately, but other users could flag the
> >> review as offensive and that would push it into an assessment queue).
> >
> > I believe that some libraries will want to manually approve every review before it is published, but I too would prefer that the default be to publish reviews immediately with a mechanism to allow other users to flag offensive or spam reviews - the more responsive the review interface is, the more likely it will actually be used.  Giving the moderation system hooks for dictionaries and filters (e.g., Akismet) would also help address concerns about inappropriate content sneaking in.
> >
> 
> And related, Dan, are you familiar with the infrastructure provided by
> OpenILS::Application::Actor::Friends?  It provides what amounts to a
> bidirectional authorization system, where users can "friend" one
> another and then give their friends specific permissions/abilities,
> such as picking up or placing holds in proxy, viewing specific private
> bookbags, etc.  It's even wired in to some parts, though with no UI
> there's not much one can do with it ... yet! :)
 
Huh, I remember seeing that go in, but it _completely_ slipped my mind -
probably because I hadn't seen evidence of it integrated into many
places. That would be awesome!

I'm hoping (along the lines of the heterogeneous system interoperability
that Galen brought up) that it will become possible to "follow" a person at
another library system, if you like their reviews or ratings or whatnot.
A basic version would be nothing more than pulling in that person's Activity
Stream feed and displaying it in your own account page. So perhaps there
are complementary models where O:A:Actor:Friends provides additional
capabilities within the same Evergreen instance, while something more
basic gives you your world-wide network of friends. In that case,
Evergreen doesn't need to run at every library; we just need every
library system to implement Activity Streams :)

It's fun thinking about the future, thanks for letting me indulge, and
for letting me know about some of the bits you've been working on to
make that future happen!

> >>  * Figuring out how to match bibs between systems so that once
> >>    everybody has Activity Streams for their bibs, we can start to
> >>    aggregate reviews / ratings / tags between library systems
> >
> > And this could extend beyond Evergreen libraries - for example, it could be useful to exchange tags and reviews with SOPAC users.
> >
> 
> OpenLibrary bib ID?  (There's the Ohio hegemony as well, but ...)

For sure that would help. OpenLibrary is good for books, and the openly
available data is a huge advantage on that front, but DVDs / videos /
journals / puppets (not kidding!) / etc are a harder nut to crack
(Freebase? dbpedia? Dunno). You could throw in xISBN and ThingISBN and
the like to eliminate some of the distinctions by editions (insert
arguments about some editions actually containing different prefaces,
etc here), too, but the discovery part is still hard.

One completely dumb approach might be to provide identifier-to-bib
lists of all bibs in your library, based on a judicious selection of
http://www.loc.gov/marc/bibliographic/bd01x09x.html

OpenLibrary IDs:
{
  "OLnum1": [20],
  "OLnum2": [5],
  etc
}

ISBNs:
{
  "isbn1": [1, 20],
  "isbn2": [5],
  etc
}

ISSNs:
{
  "issn1": [6, 10],
  "issn2": [9],
}

(Arrays for the bib IDs because we (shock) do have duplicate bibs in our
systems, and note that a given bib could appear in multiple lists, and
even appear multiple times in the same list (for 10-digit vs. 13-digit
ISBNs, etc)

... etc. Then centralized systems could crunch all of the data and spit
out correspondences, and decentralized systems could subscribe to each
other's concordance lists and work it out on their own if they preferred
to avoid centralization.

This is a big issue to solve. One would think it has already been
solved, it seems like such a basic problem; pointers from people in the
know would be appreciated!

Thanks for the quick feedback; like I said, it's fun to think about.
Possibly even more fun to think about than it is to implement :)