Timestamps are in GMT/BST.
[6:37] -hubbard.freenode.net- *** Looking up your hostname...
[6:37] -hubbard.freenode.net- *** Checking Ident
[6:37] -hubbard.freenode.net- *** Found your hostname
[6:38] -hubbard.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:23] * robint (81d746b9@gateway/web/freenode/ip.129.215.70.185) has joined #duraspace
[9:33] * robint (81d746b9@gateway/web/freenode/ip.129.215.70.185) Quit (Quit: Page closed)
[12:49] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has joined #duraspace
[12:49] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[13:04] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:27] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:18] * scottatm (~scottatm@voyager108.evans.tamu.edu) has joined #duraspace
[18:30] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:46] <tdonohue> Hi all, just a quick reminder that we have our first ever DSpace Developers Virtual Summit starting in 15mins via Skype (with #duraspace IRC backchannel): https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit
[19:47] * grahamtriggs (~Graham@cpc18-stev6-2-0-cust239.9-2.cable.virginmedia.com) has joined #duraspace
[19:52] * kshepher1 is now known as kshepherd
[19:55] * kshepherd shares an office and probably can't talk much but will lurk and listen
[19:55] <tdonohue> Countdown at 5 mins until DSpace Devs Virtual Summit, Day 1. FYI, Skype & Phone call in instructions are up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit#DevMtg2012-02-27-VirtualSummit-ConnectionInstructions
[20:02] <tdonohue> Hi all, just waiting on more folks to start our Virtual Summit discussion: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit
[20:07] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:08] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit
[20:11] <tdonohue> Going to start taking notes here on discussion, which has already started...
[20:12] <tdonohue> Discussion starting about Github code management (sharing code for each institution via github & pullin in each others code). Graham suggests having a clear "release project/tag" for institutions to fork more easily
[20:12] <tdonohue> Peter wants to generally share OSU code via GitHub & encourage others to fork & pull code from each other, etc
[20:14] <tdonohue> Maybe an area we need some "best practices" about how to fork DSpace from GitHub, etc.
[20:15] <tdonohue> Questions: How do you develop a new feature locally (for your institution) and then pull it back into central DSpace (for a future release)?
[20:16] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[20:18] * hpottinger (~hpottinge@216.106.51.181.reverse.socket.net) has joined #duraspace
[20:18] <tdonohue> Andrea - forked DSpace Github for 1.7.2 for their local code for customizations. Thinks you should be able to potentially "rebase" onto 1.8.x (to attempt to reapply your local changes to 1.8)
[20:18] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[20:20] <tdonohue> Peter - to keep GitHub history cleaner -- put source code changes in your DSpace fork. But, config changes put in a separate "config repository" (so that you aren't committing/sharing your DB password, etc)
[20:23] <tdonohue> Andrea -- can also separate out projects via Maven, rather than putting all in DSpace source tree. Just use Maven dependencies to link together.
[20:24] <aschweer> https://github.com/aschweer has a couple examples for small extra maven projects that could be used as a dependency
[20:25] <kshepherd> https://github.com/kshepherd/Curation has my "curation stuff as maven proj"
[20:25] <kshepherd> same idea
[20:25] <aschweer> yup kshepherd I got that idea from you
[20:26] <tdonohue> Peter -- another topic to cover: Common/ThirdParty Business Logic API. But, obviously not always as high a priority at individual institutions (as it may not always be in their existing needs)
[20:30] <tdonohue> Several feel Business Logic API is not of immediate need at institutions, but they would likely use it if it was there. But, as Andrea mentions, we really may want some use cases before building a Business Logic API (to help in design)
[20:30] <tdonohue> Peter: Has anyone used REST API? Especially in Production?
[20:33] <tdonohue> None it seems. Followup: Anyone interested in using a REST API in general, esp if more reliable? Is it a matter of no one wanting to be the "guinea pig" / early adopter?
[20:35] <tdonohue> Peter: Maybe we need to create some sample "embed code" (Javascript) to show off how to embed DSpace content into your website. Could put this up onto demo.dspace.org
[20:36] <tdonohue> This embed code could use the REST API, and would allow for a sample use case, etc
[20:37] <kshepherd> just a quick comment re: "REST API" -- when thinking of use cases, it's also good to consider the RESTful APIs we already make available: SWORDv2 for deposit/workspace/retrieval/endpoint resolution/etc stuff, Solr for search/browse/retrieve, etc.
[20:37] <PeterDietz> https://wiki.duraspace.org/display/GSOC/DSpace+ClientUI+built+on+RESTful+API+-+GSoC+2011
[20:37] <kshepherd> so my thinking about REST API tends to be around admin functions that aren't already covered by sword, solr, etc
[20:38] <kshepherd> (though it would be great to have the full suite of functionality)
[20:44] <tdonohue> MarkW : REST API should just expose what DSpace holds/does. Things like config submission are on the client side
[20:48] <tdonohue> REST API may just have a very 'thin' layer over SWORD (for deposit) and over Solr (for search/browse).
[20:50] <tdonohue> REST API should not invent new 'conventions' for deposit, etc.
[20:51] <tdonohue> Users could choose to write apps directly against SWORD/SWORDv2 or Solr. Or they could use the DSpace REST API, which just is a thin wrapper over these interfaces.
[20:53] <tdonohue> Question: Do I need to create a SWORD package beforehand (and how do I do this)? Answer: SWORD is content agnostic. With v2 you can actually pass multiple files (doesn't need to be a single ZIP or similar).
[20:54] <hpottinger> kshepherd: can you share that right-click SWORD client?
[20:54] <tdonohue> Kim : In theory we probably should be embedding a header that has a link to the SWORD interface for DSpace.
[20:54] <PeterDietz> http://swordapp.org/2011/09/right-click-deposit-project/
[20:54] <hpottinger> ty Peter
[20:55] <kshepherd> hpottinger: sure, i'm just documenting and screencasting some demos for it right now, but you can download a Win7 installer from my github as of right now
[20:56] <tdonohue> REST API should just use SWORD directly. It shouldn't reinvent anything, and packaging should be left up to client side
[20:59] <hpottinger> kshepherd: screencasts and demos would be helpful, too, if you can share those
[21:01] <tdonohue> REST API could be used initially more as a 'read only' API? Provide something like content reports, statistics, etc.?
[21:01] <tdonohue> Kim - Skylight actually just goes directly against Solr (which is RESTful itself)
[21:03] <grahamtriggs> As we are talking REST, and handing off to the underlying search engine, this is an interesting read: http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
[21:03] <mhwood> DS-552
[21:05] <mhwood> Oops, no kompewter. https://jira.duraspace.org/browse/DS-552 "Servlet to deliver repository size statistics"
[21:12] <hpottinger> so, discovery/solr will be "out of the box" for DSpace?
[21:14] <tdonohue> Kim -- should look at what Fedora has done with their mature REST API. It is used in conjunction with RSearch (or whatever). Perform search with one, and then call REST API with the discovered ID.
[21:16] <tdonohue> Kim -- is 'RESTful' DSpace really just SWORD + Solr/Elastic Search + Admin REST API + whatever other RESTFul interfaces needed.
[21:18] <tdonohue> Is it too complex to have that many RESTful interfaces
[21:19] <PeterDietz> my 2 cents to is not make DSpaceREST too complex. HAve all your sword client talk directly to dspace-sword, not to the rest-api sword wrapper.
[21:20] <kshepherd> (Mark W pointed out the benefit of central authZ if we wrap all the RESTful stuff under one service)
[21:20] <hpottinger> I can do webcam, if need be
[21:21] <grahamtriggs> Not really - if you want to have all of that functionality exposed RESTful-y, then you have the same number of endpoints, regardless of what application / standard it falls under
[21:21] <kshepherd> grahamtriggs++
[21:24] <PeterDietz> ahh kompewter never booted because we changed offices this week. And I don't have the kompewter bot set to auto-start
[21:24] <kshepherd> but the authZ point Mark made has got me thinking a bit more..
[21:25] * tdonohue call has officially ended, but if there's more discussion/thoughts that come up RE: REST API, etc., I'll still be lurking around for a while.
[21:25] <mhwood> Let me guess: expose authZ RESTfully and rig e.g. Solr to query it.
[21:26] <kshepherd> heh, well, that still involves 'rigging' solr, which is just as bad as rigging solr to talk to dspace-api for authZ
[21:27] <hpottinger> ow, Authz via Solr, makes my face hurt
[21:29] <hpottinger> kshepherd: does skylight do anything currently with DSpace stats views?
[21:29] <kshepherd> no, not much point, since the collections/sets we expose via Skylight don't get "hits" in Dspace istelf
[21:30] <hpottinger> ah, yes... hrm...
[21:30] <kshepherd> (DSpace and XML/JSP UI is for backend admin only in the scenario we're working towards)
[21:32] <hpottinger> and you're probably using something standard for statistics reporting, then, AWstats, Web Trends, that kind of thing
[21:32] <kshepherd> hpottinger: would not be hard to do, if you wanted to, though... but as Peter D pointed out, there are some things like resolving constants (object type) and vars (collection ID) that make keeping context tricky
[21:32] <kshepherd> hpottinger: yeh pretty much, and GA for analytics/trends
[21:33] <hpottinger> here's what I was hoping to do: figure out a way to get individualized usage stats to contributors
[21:33] <kshepherd> heh, yeah, good luck ;)
[21:34] <hpottinger> it's gonna happen, somehow, I really think it's part of the social contract of repositories
[21:34] <kshepherd> "but digitalcommons used to do it!" yeah, i'm used to hearing that one ;)
[21:35] <mhwood> Didn't Rochester's Researcher Pages do something like that?
[21:35] <hpottinger> problem on our end of things is that we're a librarian-mediated deposit shop...
[21:35] <kshepherd> yes, good point, i don't know whether they based 'contributor' on creator/contributor metadata, or on submitter ID though
[21:36] <hpottinger> so, first, we'd have to figure out *who* to send the reports to :-)
[21:36] <kshepherd> we've got our research pubs management software integrated with dspace as its 'fulltext backend' repo, so we do actually have clear relationships between our researchers and pubs in DSpace
[21:36] <KevinVdV> Needs to run, until later
[21:36] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Chicks dig it)
[21:36] <kshepherd> so that's one step in teh right direction :)
[21:39] <hpottinger> so, can I ask kshepherd what you're using for research pubs management?
[21:39] <kshepherd> Symplectic
[21:40] <kshepherd> it's very very good. not sure how much uptake it has in the US.. it's a UK company
[21:41] <hpottinger> thanks, am going to pass a note around here and see what the library folk say
[21:51] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[21:55] <tdonohue> FYI -- graham now works for Symplectic ;)
[21:57] <kshepherd> yeah i wasn't sure whehter to drop him in it or not ;)
[21:59] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[22:00] <hpottinger> I'd gathered Graham works there, from his Twitter feed ;-) but I'm woefully ignorant of the services Simplectic provides
[22:13] * hpottinger (~hpottinge@216.106.51.181.reverse.socket.net) has left #duraspace
[23:01] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has left #duraspace
[23:04] * hpottinger (~hpottinge@216.106.51.181.reverse.socket.net) has joined #duraspace
[23:14] * grahamtriggs (~Graham@cpc18-stev6-2-0-cust239.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
[23:54] * hpottinger (~hpottinge@216.106.51.181.reverse.socket.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.