Timestamps are in GMT/BST.
[12:20] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[12:20] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[12:20] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[12:21] [freenode-connect VERSION]
[12:21] <grahamtriggs> see this piece of string? ;) Actually, the aim is for the DSpace User Group, mid October
[12:21] <RichardJones> ah right
[12:21] <RichardJones> no chance
[12:22] <RichardJones> would like to do something with the identifiers
[12:22] <RichardJones> might be able to allocate some time to that in September
[12:26] <grahamtriggs> ok... well, we can move the topic on. Anyone?
[12:37] <mdiggory> I'm wondering if we are scheduled for 16:00 ET if we shouldn't just wait until then...
[12:44] <grahamtriggs> I guess so. I wonder why we thought it was now? I'm blaming you
[12:50] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[13:13] * mdiggory (n=mdiggory@69-224-235-152.bn02785.sndg02.wayport.net) Quit ()
[13:33] * RichardJones (n=richard@94-194-200-240.zone8.bethere.co.uk) Quit (Read error: 110 (Connection timed out))
[13:37] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[13:38] * cwilper (n=cwilper@74-44-156-57.dsl1-erie.roch.ny.frontiernet.net) Quit ("Ex-Chat")
[13:59] * cwilper (n=cwilper@74-44-156-57.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[14:45] * bradmc (n=bradmc@dhcp-18-111-6-157.dyn.mit.edu) Quit ()
[15:24] * ieb (n=ieb@78-105-202-108.zone3.bethere.co.uk) Quit ()
[15:40] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[15:41] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit (Client Quit)
[15:41] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[15:54] * jat_ysu (n=jeffreyt@maag127.maag.ysu.edu) has joined #duraspace
[16:03] <kshepherd> morning all
[16:03] <mhwood> Good afternoon.
[16:04] <kshepherd> oh, hrm, for some reason i thought it was a 'NZT friendly" meeting today ;)
[16:04] <kshepherd> maybe i'm mixed up
[16:04] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) has joined #duraspace
[16:04] <grahamtriggs> We've all been there today Kim
[16:04] <kshepherd> heh
[16:05] <grahamtriggs> Although I don't think there is such a thing as 'NZT friendly' time - unless it's the middle of the night everywhere else
[16:05] <kshepherd> heh, true, well, 8am is friendlier than 4am, relatively speaking
[16:06] <grahamtriggs> howdy Richard
[16:06] <rrodgers> hey grahamtriggs
[16:06] <mdiggory> hehe now its good afternoon for me
[16:09] <rrodgers> are we expecting our fearless leader (brad)?
[16:09] <grahamtriggs> he's already legged it
[16:10] <jat_ysu> legged in? Do we do the hokey-pokey now? leg in leg out.. Sorry...I've been at the office since 7: am
[16:10] <mhwood> "(11:48:17) bradmc: Can someone run the committer's mtg on #duraspace this afternoon, please?"
[16:11] <grahamtriggs> no - legged 'it' - as in 'done a runner'. Go and get some coffee
[16:11] <rrodgers> you volunteering mhwood ? ;)
[16:12] <grahamtriggs> I'm not, but it looks like you already have ;)
[16:12] <mhwood> OK, I'll do that, but I have to leave at the 1-hour mark.
[16:13] <mhwood> So: topics?
[16:13] <mdiggory> I'm waiting for stuartlewis, hoping he's coming online today? Seems that we should be focusing on 1.6. activities mostly
[16:13] <rrodgers> agreed - kshepherd - did you have a gander at embargo?
[16:13] <kshepherd> i'd expect him in the next few mins.. might be finding a carpark or something if he decided to go to the office first
[16:14] <jat_ysu> I have two things I need assistance with in the documentation department
[16:14] <grahamtriggs> kshepherd: why, have you only got two parking bays? ;)
[16:14] <mdiggory> So yes 1.6 activies (Stats, Embargo, Services,...)
[16:14] <kshepherd> still haven't had time to have a proper look sorry Richard, but i've managed to 'reserve' today [and most of yesterday] for 1.6 development which is good.. should be able to test some implementations and give some feedback by the weekend
[16:14] <kshepherd> grahamtriggs: auckland tends to only have 2 free parking spaces for 1.1 milion people, yeah ;) not even joking, really..
[16:15] <grahamtriggs> sounds just like central london (just with more sheep)
[16:15] <rrodgers> no worries kshepherd - Larry is doing a re-spin for weekend
[16:15] * ben_atmire (n=ben_atmi@62.235.147.46) has joined #duraspace
[16:15] <mhwood> 1.6, documentation, anything else?
[16:16] <rrodgers> firming up Sweden?
[16:16] <mdiggory> yes, this is why I was hoping for stuartlewis... thats mostly his domain
[16:16] <kshepherd> rrodgers: cool, if there's anything new since you sent me the last code, just forward me an update
[16:19] <kshepherd> just txt'd him a reminder ;)
[16:19] <mdiggory> I will fill the space...
[16:19] <grahamtriggs> gr8, updates in txt spch
[16:20] <mdiggory> 1.6 Service and Statistics.... I can report that I've not gotten any feedback on my branch ;-)
[16:21] <kshepherd> the UsageEvent->Solr logger service is all going?
[16:21] <mdiggory> I've been testing the dspace-services with dspace 1.6 and suspect that it may be best to get it into the trunk where others can take it into consideration in their designs for other changes
[16:22] <rrodgers> for example?
[16:22] <mdiggory> Yes, I am able to log events into solr from dspace using the implementation in the branch
[16:22] <mdiggory> rrodgers: for instance if Larry Stone wants UsageEvents to pass objects etc, this is part of the changes
[16:23] <mdiggory> but its more dramatic than just changing UsageEvent, UsageEvent is replaced with the 2.0 EventService
[16:23] <rrodgers> OK - bu tthat isn't part of embargo
[16:23] * mdiggory scratches head...
[16:24] <mdiggory> But Larry did comment on the UsageEvent work in regards to some of his work at Harvard
[16:24] <rrodgers> OK, but is any destined for 1.6?
[16:25] <mdiggory> ok, to simplify, I'd just like to make sure that inserting the UsageEvent/Services into the trunk would be an acceptable activity fromt he group
[16:25] <kshepherd> i like it
[16:26] <jat_ysu> mdiggory--will this affect the Event System Configuration in the config file? I have a reason for asking this.
[16:26] <mdiggory> not the existing EventManager, it just impacts UsageEvent ATM
[16:26] <rrodgers> I'd like to understand the implications of doing so - it's new code, therefore not heavily tested, so I'd like to understand what the 1.6 benefit is
[16:27] <mdiggory> I'm still formulating a best approach for transitioning EventManager... ATM, that looks more like a Event Consumer to bridge the two systems
[16:27] <mdiggory> so, yes, I am avoiding change EventManager in 1.6
[16:27] <rrodgers> I'm all in favor of introducing 2.0 structure where it buys us stuff...
[16:28] <mdiggory> With the dspace-services, we introduce the 1.x users with an environment that they can add their own "services" to
[16:29] <mhwood> This is branch 'dspace-1.6.x-services'?
[16:29] <mdiggory> It clarifies how the 2.0 relates to 1.x, the 2.0 services come with their own fairly complete JUnit tests
[16:30] <mdiggory> it is a combination of dspace-1.6.x-services branch and the modules/dspace-services
[16:30] <mdiggory> To clarify, modules/dspace-services is the Kernel and Service manager for dspace 2.0
[16:30] <mdiggory> and the following default services
[16:31] <mdiggory> RequestService, SessionSerivce, CachingService and EventService
[16:32] <mdiggory> the branch uses the dspace-services as a dependency and wrapps the webapplications with the ServletFilter required to make the environment available to the webapplication
[16:33] <mdiggory> thus dspace-services are only available to webapplications, not CLI environment.
[16:33] <mdiggory> but thats open to adaptation in the future
[16:34] <mdiggory> generally, its important to recognize that the ultimate goal in transitioning from 1.6 to 2.0 is that "there will be only one" dspace instance running on a dspace.dir, but this is not yet a restiction that 1.6 can make
[16:35] <mdiggory> so the dspace-services work different in 1.6 than in 2.0, and each webapplication has its one Kernel running
[16:35] <grahamtriggs> except there won't be - there can't be - only one instance running, if you care about HA
[16:35] <mdiggory> HA?
[16:35] <mdiggory> hahahaha
[16:35] <grahamtriggs> high availability
[16:35] <mdiggory> yes
[16:35] <mdiggory> ok
[16:35] <stuartlewis> Morning - appologies for being late :(
[16:35] <mdiggory> morning stuartlewis
[16:36] <mdiggory> grahamtriggs: I agree, that HA needs to be considered in the 2.0 design especially in the BiomedCental case
[16:37] <rrodgers> So is the design in flux?
[16:37] <mdiggory> and that may be a qestion of what is distributed into a cluster
[16:37] <rrodgers> in this regard?
[16:37] <mdiggory> webapps or Kernel etc
[16:37] <mdiggory> not any more than DSpace 1.x design has been in flux
[16:39] <mdiggory> you need to recognize that in 2.0 the ServiceManager and the Service api buffer the application developer from much of any flux in the underlying implementation.
[16:39] <mdiggory> how the Kernel and the Manager are deployed and used are separated from how they are accessed in the application
[16:40] <grahamtriggs> mdiggory: I'm really concerned that it needs to be considered in the 1.6 design!! I'm really expecting to be able to upgrade to 1.6 (where the adoption of 2.0 sits is a very separate issue)
[16:40] <stuartlewis> What's the current subject? (jumped in late)
[16:40] <mdiggory> So what I am proposing to place into 1.6 and begin to get people using would only change in configuration, not in programming api
[16:41] <stuartlewis> Bringing 2.0-style services into 1.6?
[16:41] <mdiggory> yes
[16:42] <mdiggory> dspace-services and the prototype branch I have created for the solr based stats service
[16:42] <stuartlewis> grahamtriggs: So you think it is a bad idea to do this? (just trying to make sure I understand everyones positions)
[16:42] <mdiggory> grahamtriggs: I'm not sure how this would make it difficult for you to upgrade
[16:43] <mdiggory> most of it is deployed separately... its very modular and I'm tempted to suggest you could leave it all behind if you so wanted to
[16:43] <mdiggory> just by enabliing or disabling it in webapp
[16:44] <rrodgers> If one did so, you would sacrifice what depends on it - like stats?
[16:44] <mdiggory> yes, you are correct in that regard...
[16:45] <mdiggory> Let me clarify why I chose this route
[16:45] <mdiggory> We looked at UsageEvent and said... it sure would be great to have multiple consumers/listeners...
[16:45] <mdiggory> I said... thats what the DSpace 2.0 EventService does
[16:46] <grahamtriggs> the solr stuff maybe, but simply leaving aside the kernel and services stuff? I'm not entirely sure about all the implications - including the maintenance/replication of state in the cluster (particular wrt to the CachingService)
[16:46] <mdiggory> if we just drop the storage and metadata stuff, then that can be used for this
[16:47] <mdiggory> grahamtriggs: are you clustering?
[16:47] <grahamtriggs> yes
[16:47] <mdiggory> what parts are you clustering.
[16:48] <rrodgers> I guess I'm wondering if it's feasible to have an 'early access' 2.0 release that injects the service mgr etc into 1.6, and still distribute an unbound version
[16:48] <rrodgers> Along the lines of what mdiggory was just suggesting
[16:48] <grahamtriggs> the dspace.dir sits on a cluster file system, the webapps hosted in clustered Tomcats (and all the functionality of -oai, -sword are rolled into the same webapp as the UI)
[16:49] <grahamtriggs> the only thing that isn't 'clustered' is the execution of the cron tasks - and that's only because I never got the heartbeat stuff figured out in time when we rebuilt the servers
[16:49] <mdiggory> It would require the following for statistics in the unbound version... we would need to accept UsageEvent as having just one consumer and you could enable that to be the solrstats service or something else
[16:50] <stuartlewis> Our timescale for this (if we're still aiming for an October RC) is about 8 weeks. How much of this is 'do-able' in that time, bearing in mind we still don't have stats and embargoes integrated?
[16:50] <mdiggory> grahamtriggs: are your sessions shared or bound to one cluster node?
[16:50] <ben_atmire> mdiggory: why would you be limited to one UsageEvent, this can be altered as well
[16:51] <rrodgers> They wouldn't have to e released simultaneously
[16:51] <ben_atmire> I've added multiple UsageEvents before
[16:51] <grahamtriggs> the sessions are replicated, although the load balancer prefers to keep sessions on the same server (as there is no guarantee that the replication will occur between the time of two requests)
[16:51] <mdiggory> I was limiting as a task... I wasn;t too interested in reinventing the 2.0 EventService, just in reusing it
[16:52] <mdiggory> but if we have something that multiplexes UsageEvent thats already written, then great, lets use it
[16:53] <ben_atmire> we can have both solutions with only a small difference of configuration
[16:53] <mdiggory> There were other changes that were requested and which we need for SolLogger.
[16:53] <mhwood> I had been meaning to look at how to change UsageEvent to use sequence plugins.
[16:53] <mdiggory> but we already have a patch I wrote for those
[16:54] <ben_atmire> what I did was get minho stats and solr stats to log simultaneously
[16:54] <ben_atmire> so the other changes were copied from you
[16:55] <mdiggory> ben_atmire: it is a more conservative path that may be more palatable.
[16:57] <stuartlewis> So... do we have a conclusion, or recommendation?
[17:00] <mhwood> Anybody?
[17:01] <stuartlewis> Do we need to take this offline, perhaps have a summary written, and we can think about it.
[17:01] <rrodgers> Guess it needs further discussion/reflection
[17:01] <mdiggory> sorry, phone call
[17:01] <kshepherd> perhaps we should keep the service branches out of trunk until more of us have had a chance to test against our own instances, other patches etc
[17:01] <mdiggory> my apologies
[17:02] <jat_ysu> If this doesn't affect the current "way" of doing statistucs in 1.6 and is just an option to turn on/off, it shouldn't really upset the apple cart, so to say, and users should be okay with the upgrade to 1.6
[17:02] <mdiggory> Ok, here is what I recommend...
[17:02] <stuartlewis> mdiggory: Do you think you could write a summary email for us to digest and consider?
[17:03] <mdiggory> exactly...
[17:03] <jat_ysu> mdiggory, if this is correct, I have no problem with that idea. Remember, I'm your average 'in the trench guy" with no expertise. LOL
[17:04] <mdiggory> mostly it would be to approach it with the strategy outlined by ben_atmire and focus on doing this without services, because otherwise graham will have some serious migration issues to tackle
[17:04] <stuartlewis> So are we just going for services for stats? Nothing else? (I'd be fine with that)
[17:06] <mdiggory> the proposal is to just adapt UsageEvent more conservatively without bringing in the 2.0 work... of course, I'm not too pleased because that is my interest... but I see the problems that Graham is presenting and want a stable release that supports his needs as well
[17:07] <rrodgers> Still doesn't preclude an early access thing if we can do the integration....
[17:08] <mdiggory> Yes, we can still do an early access, in fact that allows us to be a bit less conservative with it
[17:08] <stuartlewis> So shall we stick with it for stats, get 1.6 out the door, and we'll all get some good exeprience with the service for 1.7 or 2.0?
[17:08] <mhwood> Just noting that we've passed 1hr. Still have other 1.6 stuff, documentation issues, and DSUG on the topic list.
[17:08] <mdiggory> yes, agreed stuartlewis and lets move on
[17:08] <stuartlewis> OK - have embargoes been talked about?
[17:09] <rrodgers> Just noted that kshepherd is reviewing
[17:09] <stuartlewis> Excellent.
[17:09] <mhwood> And I need to go. Will someone take over as moderator?
[17:09] <stuartlewis> OK - I can.
[17:09] <stuartlewis> 1.6: Docs. Jeff...?
[17:09] <jat_ysu> Yes..I have three things to the table. (maybe 4)
[17:09] <mhwood> Thank you. Good discussion. I look forward to reading the log.
[17:10] <jat_ysu> I need someone to write a little about the Event System Configuration. We have only what is in DSpace.cfg. Nothing in the manual. Volunteer? I'm ignorant about this.
[17:10] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:10] <rrodgers> I can send something - it got lost in the great rewrite...
[17:11] <jat_ysu> 2. Who here can give me some undivided attention on the browse index configurations? I really think there's some lacking in the documentation to understand all the configuration components and there are three chunks each in its own chapter....
[17:11] <jat_ysu> This conversation would be email offline.
[17:12] <jat_ysu> Thanks Richard.
[17:12] <kshepherd> ah.. i've thought the same thing in the past.. i see a lot of repeat questions on dspace-tech about browse/search indexes
[17:12] <jat_ysu> So, I'd like to draw it into two placed: configuration and application (re-indexing, options, etc.)
[17:13] * kshepherd will try to send something through
[17:13] <jat_ysu> great. Any other gurus that want to assist?
[17:13] <jat_ysu> Once I have the list of people who will assist, I will ask my questions more formally and much more organized.
[17:14] <stuartlewis> dspace-dev would be a googd place to use if you don't know who in particular to ask
[17:14] <jat_ysu> 3. Indexes and appendices. Chapter 15 is now Appendix A. Should the DRI Schema Reference be an appendix or a chapter.
[17:14] <jat_ysu> ?
[17:15] * stuartlewis thinks appendix
[17:15] <jat_ysu> Indexes: This worked automatically when generating HTML and PDF, but the coding is hardcoded inside each *.xml. It get's pretty uggly. I'll send a sample to the dspace-dev. list
[17:16] <jat_ysu> Looks great in the end result.
[17:16] <jat_ysu> That's just a good news update.
[17:17] <jat_ysu> 4. Nomenclature. I want you all to think about the chapter names and nomenclature. I had a systems admin ask me what the application layer was. I said "application programs that run dspace and all the jobs.."
[17:17] <stuartlewis> Yes - thanks Jeff. The docs are looking a lot better in terms of style, and loads better in content, typos, and pruning old content.
[17:17] <jat_ysu> Just to remind you, as i update, they are on my dspace server: htpp://digital.maag.ysu.edu/jspui/doc
[17:18] <jat_ysu> Also, there will be some reorganization and splittign and merging of content for the 1.6 release. I'll be working on updating all 1.6 changes I have sometime next week.
[17:18] <jat_ysu> If you see ANYTHING on that web page that looks FUNKY, please email me. If you want it in PDF let me know, I can place somewhere on a server for you to pull.
[17:19] <stuartlewis> 'application layer' is an interesting question. It is pretty standard terminology for develoeprs, but obviously not for the target audience of the docs.
[17:19] <kshepherd> mm, i can't think of a better term
[17:19] <kshepherd> but it wouldn't hurt to have a one or two line description of the entire application layer at teh beginning of the chapter
[17:19] <jat_ysu> Exactly...I've worked with DSpace since 1.1 release, so for me it's a no-brainer where to look for things.... I don't even look at the content page.
[17:20] <jat_ysu> kshepherd: I thought of something like: "Dspace Application programs" or "Dspace Administrator Programs"
[17:20] <jat_ysu> It's the wording "layer" that is confusing....
[17:21] <jat_ysu> But this is not as important as getting all the errors out and clarifying anything that doesn't make sense.
[17:21] <jat_ysu> okay...I'll put a call out to DSpace-Dev. to get assistance with the browse index.
[17:23] <jat_ysu> Also, one other thing is missing in the documentation. The feature "My exported items" zip file. I stumbled somehow on that...but can't locate anything but a property key in the configuration file. Anyone has a write up would be helpful.
[17:23] <jat_ysu> That's all I have...sorry to bore you all.
[17:23] <stuartlewis> The guys at TDL would be the ones to ask for that.
[17:24] <jat_ysu> Okay...will do.
[17:24] <stuartlewis> OK - DSUG. I've seen a preliminary programme now.
[17:24] <jat_ysu> We probably should keep a document with the committers' name attached to each release and what it was. ;-)
[17:24] <stuartlewis> There is quite a bit dedicated to 1.6, some to SWORD, some to service/ds2.0, some to repo managers, and some genreral case studies.
[17:24] <jat_ysu> Call it the BDCYA appendix....
[17:25] <jat_ysu> Blame Document: Cover Your A$$ appendix. LOL
[17:25] <jat_ysu> some humor is needed.
[17:25] <jat_ysu> I'm done and will now sit down in the bakc of the class.
[17:25] <stuartlewis> Do we want to offer any feedback to the DSUG planners about what we would like to see?
[17:26] <stuartlewis> There is one parallel slot for devs and repo managers to have their own streams.
[17:26] <stuartlewis> And the afternoon of the last day is free, with the committers meeting pencilled in.
[17:27] <stuartlewis> One final subject from me (anyone have any others before we close?)... JIRA cleanup to try and define a list of issues we want in 1.6, what to leave for later, and what to 'not-fox'.
[17:27] <kshepherd> jat_ysu: sorry to derail, just one last thought about "Application Layer" and "Business Logic Layer" (which is possible even more confusing to people?)... could go with some more common (if slightly less accurate) terms like Frontend, Backend, Storage
[17:28] <mdiggory> stuartlewis: I want to see a way for us (developers going to DSUG) to participate in the structure of the developer activites going on there
[17:28] <jat_ysu> WOW.....that's more like it....I think I can come up with something now. stay tune for me to put out a proposal on DSPACE-DEV
[17:29] <stuartlewis> Developer session is shceduled for 15:30 -> 17:00 on the second day, and has two sessions
[17:30] <stuartlewis> Tim and Andrea talking about the community admin patch
[17:30] <stuartlewis> Mark talking about DSpace services.
[17:30] <mdiggory> Yes, those are talks, and I happy to be giving one :-)
[17:31] <mdiggory> I'm refering more to commiter meetings, design discussions and unconference like activities... bar camp? like things etc
[17:31] <mdiggory> you know... really FUN stuff
[17:31] <stuartlewis> AFAIK there is nothing planned like that (other than committers meeting).
[17:31] <stuartlewis> There are tutorials on the first morning.
[17:32] <stuartlewis> Would you like to see a developers lounge exist during that time for people who want to talk technical and code rather than have tutorials?
[17:32] * jat_ysu (n=jeffreyt@maag127.maag.ysu.edu) has left #duraspace
[17:32] <mdiggory> not sure... its difficult to avoid overlap
[17:33] <stuartlewis> Naturally there will have to be overlap as <50% of people will be interested i nthe techie side of things.
[17:33] <rrodgers> Sorry for the context shift - but it just popped into my head. Are we addressing the DRIVER stuff in 1.6?
[17:33] <rrodgers> It was sort of a big deal for some of the Europeans at OR
[17:35] <stuartlewis> Do we have a list of DRIVER reqs that DSpace doesn't fulfil. The only one I know about is exposing a 'fulltext' OAI-PMH set.
[17:35] <mdiggory> we did have the topic come up in OR09
[17:35] <kshepherd> yeah, the committers panel at the end discussed it a fair bit, i just can't remember where i put my notes ;)
[17:36] <rrodgers> I don't have a list either - I'm just wondering if we should reach out to someone (like Minho) to find out?
[17:36] <ben_atmire> DRIVER has the requirement to offer a set for fulltext open access content
[17:36] <ben_atmire> that was the main issue
[17:37] <ben_atmire> without altering DSpace code, this implies making a collection for that and mapping all this content to that collection
[17:37] <rrodgers> I think that's right ben_atmire
[17:37] <stuartlewis> Yes - programatically deciding if something is full text is not going to be easy / accurate.
[17:38] <rrodgers> Well isn't it less that it's text (though it has to be that of course), but whether it's open?
[17:39] <mdiggory> they were hoping for dspace to make OAI more configurable
[17:39] <kshepherd> there were a few other 'compliance' issues discussed that were maybe not related so much to DRIVER, as well... like the dc.contributor.author vs dc.creator thing, and one suggestion was releasing a tool that could at least report all these potential issues to teh admin/user, even if they couldn't be fixed by 1.6
[17:39] <mdiggory> so that you could define your own sets of content separate from that of the community/collection hierarchy
[17:39] <stuartlewis> DRIVER has its own compliance reporting tool.
[17:39] <kshepherd> right, yeah, i think perhaps we were discussing non-DRIVER issues by then. sorry for derail ;)
[17:40] <mdiggory> kshepherd: we were all a bit baffled by that one because dspace oai maps contributor.author to creator
[17:41] <mdiggory> http://dspace.mit.edu/oai/request?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:dspace.mit.edu:1721.1/39126
[17:41] <kshepherd> yeah. which is a hacky workaround, but a very.. entrenched one by now.
[17:42] <mdiggory> One of my ideas for sharing between the Fedora and DSpace communities would be to actually begin utilizing Fedoras standalone OAI work that Chris has done in place of dspace oai where appropriate...
[17:43] <rrodgers> Do we know how they deal w/DRIVER compliance?
[17:43] <mdiggory> this would mostly mean creating Event Consumers and Loaders to populate the oai provider from dspace content
[17:43] <mdiggory> have to ask cwilper
[17:44] <rrodgers> thanks mdiggory - that could save us some time...
[17:45] <mdiggory> http://proai.sourceforge.net/
[17:46] <stuartlewis> Could be good in removing read-only records from oai-pmh. At the moment it is done in real-time, which is pretty slow.
[17:48] <mdiggory> Its an excellent opportunity for technology transfer, consolidation and reuse within the OR community
[17:48] <stuartlewis> For 1.6? Or will it take too long?
[17:49] <stuartlewis> (Just checked - it was only mentioned 3 times in the 1.6 survey)
[17:51] <mdiggory> I think that it would require an effort on our part to get better versed with the prOAI deployment and configuration... I would recommend that it be explored as an addon for dspace that might someday replace the existing oai functionality. but I think someone would need to focus on it intensely at this point to get it into 1.6
[17:52] <rrodgers> +1
[17:52] <stuartlewis> So I guess we need to leave it on the back burner unless anyoen has a burning desire...?
[17:52] <mdiggory> My issues with DRIVER compliance are that it requires "more" than just off the shelf OAI
[17:53] <rrodgers> Can't we just claim that if they identify OA content in metadata - it would be easy for us to implement a set?
[17:53] <stuartlewis> But presumably if someone really wants DRIVER compliance, they can do it with a collection of mapped items? So the compliance is there, albeit via a hack.
[17:53] <mdiggory> requiring a "full text" set rather than scanning teh OAI recoders for full text detail makes compliance require developers to alter existing OAI gateway capabilities
[17:54] <mdiggory> the set needs to have a specific name
[17:54] <ben_atmire> mdiggory: true, it needs to be called "driver"
[17:55] <ben_atmire> and if we would go far with this, NEEO compliance would probably be next
[17:55] * stuartlewis isn't comfortable with bodies requiring software to be tailored just for them, with sets named after their organizations. We could end up with dozens of these.
[17:56] <ben_atmire> NEEO is similar to DRIVER, but slightly different requirements
[17:58] <stuartlewis> As Richard suggested, if we could find a neat way of adding a driver tag or full text tag in the metadata, making a new set based on that would be easy enough.
[17:59] <rrodgers> At any rate, we should absolutely stay out of the business of programmatic identification...
[17:59] <mdiggory> I suspect that this hack will need to happen because of the traction/attention that DRIVER is getting
[18:01] <mdiggory> rrodgers: so you are recommending a tag which the metadata editor would need to add?
[18:01] <stuartlewis> ben_atmire: Would you be willing to (sorry for the pun) drive this, find the exact requirements, and come up with some possible solutions?
[18:01] <mdiggory> i.e. don't just look for annonymous access rights on bitstreams?
[18:01] <rrodgers> I guess what I'm suggesting is writing a set that looks for a configurable set of metadata values - not one that we require
[18:02] <ben_atmire> I have some previous experience with DRIVER, so I should be able to do this
[18:02] <stuartlewis> ben_atmire: Excellent. Thanks :)
[18:02] <rrodgers> but mdiggory - yes, it would be up to the repository manager to ensure that the tags be present & correct
[18:02] <stuartlewis> rrodgers: Sounds a good solution.
[18:03] <mdiggory> we also need to make sure that text is available over didl metadata crosswalk, right?
[18:03] <ben_atmire> driver uses url's in didl
[18:04] <ben_atmire> but that's usually not a problem
[18:04] <ben_atmire> it's the sets that bother most people
[18:05] <ben_atmire> most driver implementations edit the didl crosswalk for mapping the application profile anyway
[18:05] <ben_atmire> (at least for the 3 different implementations I've seen in the past)
[18:05] <mdiggory> so we would need to verify that we maintain the same mappings by default in ours
[18:07] <ben_atmire> I don't think the didl crosswalk requires changes from DSpace
[18:08] <mdiggory> we would probably want to have it enabled by default.
[18:08] <ben_atmire> the changes are specific to mapping the institution's application profile to DRIVER-specific metadata requirements
[18:08] <mdiggory> doesn't seem to be on most installations
[18:10] <kshepherd> brb, nicotine levels are dangerously low
[18:11] <mdiggory> think we have gone past the 2 hr mark...
[18:12] <rrodgers> I've got to run - but thanks all (and ben_atmire for the DRIVER assist - I think as mdiggory observed, we wil need to offer something)
[18:13] <ben_atmire> we won't be offer complete driver compatibility out of the box
[18:13] <ben_atmire> as it is too application profile dependent
[18:13] <rrodgers> true - but we will show that we listen to community input...
[18:14] <ben_atmire> and we can make sure DRIVER compatibility becomes a lot easier to accomplish
[18:14] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) Quit ()
[18:14] <mdiggory> perhaps a proposal for changes can be drafted and forwarded to DRIVER for comment
[18:14] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) Quit ("Leaving")
[18:15] <stuartlewis> OK - I have to run too now. Shall we formally close the meeting?
[18:15] <ben_atmire> I'm not sure whether DRIVER knows all the issues coming from DSpace users
[18:18] <mdiggory> stuartlewis: I think you just did
[18:18] <stuartlewis> Ok - well as ever, thanks everyone. We've covered a lot of ground today.
[18:19] <kshepherd> looking at proai, i don't think it'd be hard to write a DSpace OAIDriverImpl based on dspace-oai's existing API... but i'm getting distracted again ;)
[18:19] * mdiggory returns to his drawing board ;-)
[18:26] <mdiggory> kshepherd: I think the "pull"
[18:26] <mdiggory> nature of proai will be interesting to approach
[18:27] <kshepherd> yes
[18:27] <mdiggory> would mean it wouldn't be an EventConsumer based
[18:28] <kshepherd> seems like it'd be easy enough to pull, store and serve identities, sets, etc for multiple IRs in a single OAI interface as well which might interest people
[18:28] <kshepherd> but i haven't looked at it tooooo closely yet so i might be barking up the wrong tree
[18:28] <mdiggory> driver still requires he repository to produce the crosswalk...
[18:29] <ben_atmire> we should be careful not to offer a solution which breaks all alterations of people who already invested in customized crosswalks
[18:29] <kshepherd> ben_atmire: definitely
[18:30] <kshepherd> very valid concern
[18:31] <ben_atmire> is proai used by many institutions?
[18:31] <ben_atmire> DRIVER might be offering a crosswalk if it is :)
[18:32] <mdiggory> I think if this were explored it would just replace the current webapp and driver, the actuall crosswalks would probibly be maintained...
[18:32] <ben_atmire> something worth checking out in more detail
[18:32] <ben_atmire> some other day, I have to go now
[18:33] <mdiggory> theres nothing to suggest that it couldn't just be another alternative to the existing webapp, the caching support being the benefit.
[18:34] <kshepherd> i have to get back to $busywork now, myself
[18:34] <mdiggory> I think we would still need to author the crosswalk specifically for dspace
[18:34] <mdiggory> I don't think there is a way around that
[18:34] * ben_atmire (n=ben_atmi@62.235.147.46) Quit ()
[18:35] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[19:03] * cwilper (n=cwilper@74-44-156-57.dsl1-erie.roch.ny.frontiernet.net) Quit ()
[19:05] * cwilper (n=cwilper@74-44-156-57.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[19:08] * ksclarke (n=kevin@adsl-162-19-68.clt.bellsouth.net) has joined #duraspace
[19:08] * ksclarke (n=kevin@adsl-162-19-68.clt.bellsouth.net) has left #duraspace
[20:09] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) Quit ()
[20:48] * cwilper (n=cwilper@74-44-156-57.dsl1-erie.roch.ny.frontiernet.net) Quit (lindbohm.freenode.net irc.freenode.net)
[20:54] * cwilper (n=cwilper@74-44-156-57.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[21:03] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[22:31] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) Quit (Remote closed the connection)
[22:33] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) has joined #duraspace
[22:35] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) Quit (Remote closed the connection)
[22:39] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) has joined #duraspace
[22:54] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) Quit (Remote closed the connection)
[23:50] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.