On Mon, Oct 11, 2010 at 09:54:41AM -0400, Mike Rylander wrote: > On Mon, Oct 11, 2010 at 8:56 AM, Galen Charlton <[email protected]> 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 :)
