Timestamps are in GMT/BST.
[0:30] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[0:47] * ksclarke (n=kevin@adsl-1-145-78.clt.bellsouth.net) Quit (Read error: 110 (Connection timed out))
[2:37] * ClaudiaJuergen (n=Miranda@pc5102.ub.uni-dortmund.de) has joined #duraspace
[2:37] <ClaudiaJuergen> good morning all
[6:18] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[7:42] * awoods_ (n=awoods@pool-72-83-142-207.washdc.fios.verizon.net) has joined #duraspace
[7:50] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[8:31] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[8:54] * cbeer (n=cbeer@204.152.12.166) has joined #duraspace
[8:56] <ClaudiaJuergen> hometime, bye
[8:57] * ClaudiaJuergen (n=Miranda@pc5102.ub.uni-dortmund.de) Quit ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[9:12] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[9:51] * ben_atmire (n=ben_atmi@213.219.159.242.res.static.edpnet.net) has joined #duraspace
[9:59] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[10:06] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:57] * tdonohue (i=80ae241d@gateway/web/freenode/x-jsalgnpeejvdzpgm) has joined #duraspace
[11:59] * scottatm (n=scottatm@peat.evans.tamu.edu) Quit ()
[12:00] <bradmc> Hi folks, Dspace committers mtg in a few minutes.
[12:00] <bradmc> Topics of interest this week?
[12:01] <ben_atmire> Hello bradmc, I would like to talk a bit about the OAI request from Driver
[12:03] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) has joined #duraspace
[12:04] <grahamtriggs> Not really a DSpace topic, but this might interest Brad... http://www.theregister.co.uk/2009/08/26/amazon_virtual_private_cloud/
[12:04] <bradmc> Yep, I saw that direct from amazon. Thanks.
[12:05] <bradmc> Ben, would you like to go ahead and get started, and then we'll see if we get other topic nominations from the floor.
[12:05] <ben_atmire> ok
[12:05] <ben_atmire> you probably still remember the original issue
[12:06] <ben_atmire> which was also placed on the wiki at http://wiki.dspace.org/index.php/DSpaceOAISets
[12:06] <ben_atmire> I've been talking a bit with Chris Wilper about integrating the fedora proai solution into DSpace
[12:06] <ben_atmire> and I've created a draft implementation that realizes just that
[12:06] * grahamtriggs doesn't need the implication of being on the floor, after spending last week drinking his way through the Edinburgh Fringe...
[12:07] <ben_atmire> what I got out was a solution which still uses the existing oai configuration file
[12:07] <ben_atmire> and the existing crosswalk implementations
[12:08] <ben_atmire> without having to alter any of the existing DSpace code
[12:08] <ben_atmire> just by adding in new code
[12:08] <ben_atmire> the solution can offer the current OAI implementation, and the proai implementation simultaneously
[12:08] <ben_atmire> in one or two webapps
[12:09] <bradmc> Sounds promising. I assume the next question is how / where / when to package the code, particularly around 1.6?
[12:10] <rrodgers> also - does the proai handle our DRIVER set issue?
[12:10] <bradmc> (Not expecting Stuart today, BTW; he was here at 6am yesterday, and it's 4am now)
[12:10] <grahamtriggs> ben_atmire: I presume when you say one or two webapps, you mean in addition to the main UI, but then if both OAI implementations can be in one webapp then it should also be possible to combine into the UI webapp as well
[12:10] <ben_atmire> I think if we would offer this as part of 1.6, we need to keep in mind it requires a separate database
[12:11] <ben_atmire> grahamtriggs: I currently have two OAI solutions operational in one webapp
[12:11] <ben_atmire> the default under /request and the new one in /proai
[12:12] <ben_atmire> proai can handle the DRIVER set issue, with a small intervention from the person implementing the DRIVER solution
[12:12] <rrodgers> how is OA content identified?
[12:13] <ben_atmire> there is no standardized way to identify OA content
[12:13] <ben_atmire> that's why it requires the intervention
[12:13] <ben_atmire> it's up to people maintaining the repository to decide on how to identify OA content
[12:14] <rrodgers> agreed, what I thought we needed to provide was a programmatic bridge from that way to an OAI set
[12:14] <ben_atmire> and then add in one line claiming a given item is part of an extra set (separate from the communities and collections)
[12:14] <ben_atmire> this can probably be improved to use plug-ins or something to define those special sets
[12:15] <ben_atmire> I'm reusing the HarvestedItemInfo object in the proai solution
[12:15] <ben_atmire> if the extra set would be added here, proai will take care of all the rest
[12:18] <rrodgers> OK thanks - I was trying to find out what the main motive was -(a) and early win for common infrastructure or (b) a DRIVER solution
[12:18] <ben_atmire> so if we add in an option to define extra sets given a specific item, we don't need to worry about connecting those sets to a browsable solution, containing deleted records, …
[12:18] <rrodgers> sounds like a bit of both
[12:18] <ben_atmire> that's why I've been spending some extra time on this solution
[12:19] <ben_atmire> it does come with an extra configuration file, and an extra database :(
[12:19] <ben_atmire> and an extra directory for storing metadata
[12:19] <rrodgers> (so should probably be an add-on then)
[12:19] <bradmc> Yes, add-on.
[12:20] <mhwood> How do the data get into the extra database, then?
[12:20] <ben_atmire> there are a few methods that make the bridge
[12:20] <ben_atmire> proai offers an interface
[12:20] <ben_atmire> and I created a DSpace implementation for that interface
[12:21] <ben_atmire> it lists all sets, lists all records, and gives the full metadata for one record
[12:21] <ben_atmire> it's actually http://proai.sourceforge.net/api/proai/driver/OAIDriver.html
[12:22] <ben_atmire> so there is a delay between updates of your metadata, and results in OAI
[12:22] <ben_atmire> but proai harvests dspace asynchronously
[12:23] <mhwood> Thanks.
[12:23] <ben_atmire> so since this will become an add-on, it will not need to make to 1.6 release date?
[12:24] <rrodgers> sure, provided 1.6 has the hooks you need
[12:24] <ben_atmire> I didn't have to change a single class in DSpace
[12:25] <rrodgers> That's clean ;)
[12:25] <bradmc> Sounds good.
[12:25] <mhwood> Ahh, an opportunity to nail down some of the details of packaging and distributing add-ons.
[12:25] <bradmc> Yes. Also an interesting case for publicity and approval of add-ons as well.
[12:26] <bradmc> Ben, what else do you need to proceed?
[12:26] <ben_atmire> I will need to check out how to port this to an add-on, but I think Mark will be able to help me when he's back from his holiday
[12:26] <bradmc> Other topics for today?
[12:27] <rrodgers> JIRA fun and games?
[12:27] <bradmc> I think most are aware that we covered about 1/3 of Jira issues yesterday, so we'll be continuing with that exercise next tuesday, same time.
[12:28] <bradmc> We're in the process of collating the results, but you can see the raw log at the irclog URL for this channel.
[12:28] <mhwood> I thought the pace was very fast, but probably we needed that to prevent stalling entirely on some subjects.
[12:28] <rrodgers> yep, just meant is was an opportunity to tweak process if desired
[12:28] <bradmc> Ah, let's discuss any thoughts then.
[12:29] <bradmc> I think we'll need an opportunity for re-opening certain issues if we continue the fast pace, but that's preferable to slowing down.
[12:29] <rrodgers> bradmc, +1
[12:30] <mhwood> +1
[12:30] <tdonohue> (just catching up on discussion)...I'd agree, bradmc +1
[12:31] <bradmc> Should we have a segment at the start of each session for people to re-raise jira items for a new vote?
[12:32] <mhwood> 'twould be good to have a list of the issues to be reviewed, so I can make certain that I've at least read them all recently.
[12:32] * cbeer (n=cbeer@204.152.12.166) has left #duraspace
[12:32] <bradmc> Yes, stuart did a nice job of that on the wiki for the last meeting, albeit very close to the meeting time by necessity.
[12:33] <bradmc> I'm thinking that if an item is going to be re-raised, the re-raiser is going to want to have shared their new insights in advance.
[12:33] <mhwood> Maybe re-entry of issues should happen offline.
[12:33] <bradmc> I like that; especially if we stick to Stuart's wiki page format.
[12:33] <rrodgers> so should we announce a limit (remaining 1/2 e.g) to be reviewed, so people can focus?
[12:34] <bradmc> You mean update the page to mark items already handled, and the next start point? Yes, that makes sense.
[12:34] <mhwood> Well, we'd need to be able to say which issues are in that remaining 1/2
[12:34] <tdonohue> yes, it might be nice to have a limit/range to what will be reviewed in a session, so that we can all pre-review them if we have time..
[12:35] <rrodgers> yep - we are handling them sequentially
[12:35] <bradmc> We have an approximate pace now, so we could say something like the 40 +/o issues starting at X will be reviewed.
[12:35] <bradmc> thats +/-
[12:36] <grahamtriggs> is there a case for adding some extra fields/statuses) to the JIRA instance for managing this process (ie. if we have that, we can easily pull reports off of JIRA)
[12:36] <rrodgers> that's what I had in mind
[12:36] <bradmc> I'm assuming that this is short term; by session 4 the list should be short enough to incorporate the exercise into this meeting.
[12:37] <bradmc> grahamtriggs: Maybe, although I think just getting through the list once is the thing to do at this point. I'm not sure if this is a short or long term need.
[12:38] <bradmc> Other topics for today?
[12:39] <bradmc> I assume next week may also be a little light for this meeting, but the following week we'll start to pick up speed again.
[12:40] <mhwood> Nothing else here.
[12:40] <bradmc> Shall we drop the gavel on the floor? (Graham, move over!)
[12:40] <grahamtriggs> ouch. that was my head
[12:41] <bradmc> Thanks, all.
[12:41] <tdonohue> sounds good, i got nothing either
[12:41] <rrodgers> thanks everybody
[12:41] <mhwood> Thanks all.
[12:42] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) Quit ("Leaving")
[12:42] <grahamtriggs> cheers (goes off to find the Ibuprofen)
[12:42] <tdonohue> later all..
[12:42] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[12:43] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:46] * tdonohue (i=80ae241d@gateway/web/freenode/x-jsalgnpeejvdzpgm) Quit ("Page closed")
[12:51] * ben_atmire (n=ben_atmi@213.219.159.242.res.static.edpnet.net) Quit ()
[13:26] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[14:35] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[14:46] * scottatm (n=scottatm@peat.evans.tamu.edu) has joined #duraspace
[16:34] * RichardJones (n=richard@94-194-200-240.zone8.bethere.co.uk) Quit (lindbohm.freenode.net irc.freenode.net)
[16:34] * RichardJones (n=richard@94-194-200-240.zone8.bethere.co.uk) has joined #duraspace
[17:10] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) Quit ("Leaving.")
[17:19] * mhwood (i=mwood@mhw.ulib.iupui.edu) Quit (Remote closed the connection)
[17:59] * scottatm (n=scottatm@peat.evans.tamu.edu) Quit (Read error: 145 (Connection timed out))
[19:05] * ksclarke (n=kevin@adsl-1-145-78.clt.bellsouth.net) has joined #duraspace
[20:28] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:25] * bruce (n=bruce@adsl-75-50-150-202.dsl.lsan03.sbcglobal.net) Quit (Remote closed the connection)
[22:04] * awoods_ (n=awoods@pool-72-83-142-207.washdc.fios.verizon.net) Quit (Read error: 110 (Connection timed out))
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.