Timestamps are in GMT/BST.
[1:56] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[2:09] * eddies (~eddies@bb220-255-224-197.singnet.com.sg) has joined #duraspace
[2:09] * eddies (~eddies@bb220-255-224-197.singnet.com.sg) Quit (Changing host)
[2:09] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[2:15] * eddies (~eddies@unaffiliated/eddies) Quit (Read error: Connection reset by peer)
[2:27] * eddies (~eddies@bb220-255-224-197.singnet.com.sg) has joined #duraspace
[2:27] * eddies (~eddies@bb220-255-224-197.singnet.com.sg) Quit (Changing host)
[2:27] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:54] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:54] -rajaniemi.freenode.net- *** Checking Ident
[6:54] -rajaniemi.freenode.net- *** Found your hostname
[6:54] -rajaniemi.freenode.net- *** No Ident response
[6:54] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:54] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:54] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:56] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:33] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:55] -mrmist- [Global Notice] - A reminder that this coming weekend sees our long awaited services upgrade and database prune. All nicks unused for 150 days or more will be dropped from the database. Please make sure you have identified to your accounts, and used your grouped nicks. use /msg nickserv info when identified to see yours and thanks for flying freenode!
[13:22] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:29] * helix84 (a@195.113.97.174) has joined #duraspace
[13:52] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[13:52] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[13:52] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[14:20] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[14:24] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[17:00] <tdonohue> DSpace "Office Hours" are starting. Ping me if you have something you'd like to chat about: https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours (In the meantime, I'll be keeping an eye on this channel while I get some other work done)
[17:10] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[19:01] * KevinVdV (~kevin@d54C154B1.access.telenet.be) has joined #duraspace
[19:12] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:17] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:30] * vtkeithg (~vtkeithg@vtkeithg.lib.vt.edu) has joined #duraspace
[19:50] <tdonohue> Hi all, quick reminder that our DSpace Devel Mtg starts here in 10 mins : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-13
[19:55] * ryscher (ae61f77a@gateway/web/freenode/ip.174.97.247.122) has joined #duraspace
[20:00] <tdonohue> Hi all, it's that time again. The DSpace Devel Mtg starts now: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-13
[20:00] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:01] <PeterDietz> hi all
[20:01] <KevinVdV> Hi all
[20:01] <tdonohue> before we get into JIRA review stuff, first off just wanted to again congratulate our newest committer, helix84! Glad to have Ivan on the team!
[20:01] * richardrodgers (~richardro@dhcp-18-111-8-152.dyn.mit.edu) has joined #duraspace
[20:01] <helix84> hello everyone, thanks for your support
[20:01] <hpottinger> grats again, helix84
[20:02] <mhwood> WElcome!
[20:03] <tdonohue> So, with that, we'll head into JIRA reviews: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1047+ORDER+BY+key+ASC
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1047 ] - [#DS-1047] Reset CC licence on an already submitted item - DuraSpace JIRA
[20:03] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1047+ORDER+BY+key+ASC
[20:03] <mdiggory> Hello
[20:03] <tdonohue> starting with DS-1047
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1047 ] - [#DS-1047] Reset CC licence on an already submitted item - DuraSpace JIRA
[20:05] <helix84> i think i noticed someone on the list working on a feature that would allow change the license by re-running an existing item via the submission workflow. but i can't remember more right now.
[20:05] <mhwood> This seems like one of those things which *should* be a little complex and involved, because changing terms on something already published should be approached thoughtfully.
[20:05] <mdiggory> One strategy we reuse often for clients is to make it so that Items can be sent back through the submission workflow as part of the review process. Allowing access to CC steps and the like
[20:05] <richardrodgers> Yea, I'm not sure what the exact use case is - is it changing your mind and relicensing?
[20:06] <tdonohue> mdiggory -- is that public code? cause that sounds like it'd meet these needs.
[20:06] <tdonohue> richardrodgers -- I could see a potential use case as just being an "undo" (whoops, selected X license in the submission, when I meant to select Y license. Now, I cannot fix it)
[20:07] <richardrodgers> tdonohue: is the idea that submitter doesn't realize the mistake until item has been installed?
[20:08] <PeterDietz> ...and the process of retroactively modifying licenses is non-existant
[20:08] <mdiggory> tdonohue: I can discuss and get back to you, its not much code, more strategy...
[20:09] <tdonohue> yes, richardrodgers -- e.g someone submitted their thesis quickly to get it in under a deadline (or something), but didn't realize the mistake till it was public.
[20:09] <mdiggory> tdonohue: Can possibly support as part of the Versioning work. Versioning is activated as duplicating and sending an Item through submission and review again.
[20:10] <mdiggory> so cases where the wrong CC license was applied could be revisions to the Item
[20:10] <tdonohue> I guess I'm of the frame of mind that "In general, DSpace really should support the ability to edit/change anything, even after an item is installed/archived. People make mistakes, and it'd be nice if we make it easier to correct them"
[20:10] <richardrodgers> ok, but submitter loses access to modifying most everything after submission, why do we single out CC license?
[20:10] <mdiggory> minting a new item with appropriate CC details and withdrawing the original
[20:11] <tdonohue> not trying to single out "CC Licenses"...just a small use case in a much large problem. (which mdiggory is right could potentially be helped by Versioning work)
[20:11] <mdiggory> This is a usecase that Item Versioning solves by allowing original submitters to resubmit changes to an item
[20:11] <mhwood> I like the idea of re-review. Letting submitters unilaterally change things after they've been reviewed and approved doesn't sound right.
[20:13] <tdonohue> ok. realize I may have brought us off the "architectural deep end" here :) Do we think this ticket should be recategorized as a sub-ticket on Versioning? Should it be held for more discussion around whether Items should be changeable after "archived"?
[20:13] <mdiggory> Yes, this was one of the original benefits in the design
[20:14] <mhwood> I think we need to be sure there is consensus on just how permanent installed items should be.
[20:14] <mdiggory> Its a mix... You can classify it as versioning and I'll try to address it
[20:15] <richardrodgers> I actually think the change bar should be pretty high - otherwise we compromise our ability to be part of a scholarly record....
[20:15] <tdonohue> to be clear, I was never meaning to say that submitters should be able to go change all their installed items. I just meant that *someone* (an admin even) should be able to change any installed item (in an easier fashion)
[20:15] <tdonohue> (in order to correct mistakes that the submitter may have made)
[20:16] <mdiggory> Yes, There are cases where administrative fixes shouldn't create new versions, and cases where they should. There'll be healthy debate in the community about when/where these are appropriate
[20:16] <tdonohue> mdiggory, can you link this ticket over to whatever Item Versioning ticket you have (assuming there is one)?
[20:17] <tdonohue> we should also add this discussion into the comments of Ds-1047 (if someone gets to it before I do, please feel free)
[20:17] <mhwood> Yes, it should be possible to fix mistakes without digging in the database, but it should involve more than one person. One of the things that makes DSpace IMHO better than much of the Web is precisely that it doesn't change all the time; it only accumulates new stuff.
[20:17] <mdiggory> Yes, I need to create an Umbrella Task
[20:18] <tdonohue> ok, Ds-1047 summary: Needs more discussion. mdiggory will link to an umbrella task around Item Versioning (as it may be covered by that). Add discussion notes to comments
[20:19] <tdonohue> ok. we spent a long while already on just that one ticket (whoops). So, we will stop the JIRA review there for today and move on, in the essence of time.
[20:19] <mdiggory> CLI code is useful though... we will want to make sure that license changes on an existing item properly behave in submission UI / etc so the task is good in clarifying requirements with some code samples.
[20:20] <tdonohue> Next up, the main topic for today is around the "OR12 DSpace Developer Mtg Draft Agenda": https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:20] <kompewter> [ DevMtg 2012-07-09 - OR12 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:20] <tdonohue> Essentially, just wanted to open up the floor here for discussion on how we should reallocate time, and what folks like/don't like, etc.
[20:21] <tdonohue> already, we had some good feedback from mdiggory that 1 hour may not be enough time for "3.0 Discussions" (would be interested to hear what others think)
[20:21] * hpottinger volunteers to be the official timer for lightning talks
[20:21] <richardrodgers> Yes, TIm & I did this as a strawman so there is something to react to
[20:22] * aschweer (~aschweer@ip-118-90-91-194.xdsl.xnet.co.nz) has joined #duraspace
[20:22] <tdonohue> Also, we had an offer from Jonathan Markow (DuraSpace Chief Strategy Officer) to come talk to the group about Fedora Roadmap & DuraSpace strategies & anything about DSpace + Fedora. Currently that's not listed in the agenda, but we could slot in 1/2 hour if we wanted that discussion to happen.
[20:22] <hpottinger> I think that would be a good discussion to happen
[20:22] * tdonohue is going to stop typing/talking for a while and listen to your feedback
[20:23] <richardrodgers> I'd like to hear that, if it isn't going to be presented elsewhere at OR (like user group)
[20:24] <tdonohue> It may also be presented at a higher level at the Duraspace Plenary before the user groups -- but, this would allow for more of a direct discussion with Jonathan (and he said he'd be willing to join for 1/2 hour or an hour or however long we want.
[20:25] <mdiggory> I think its good to have this sort of discussion within the community prior to any big announcements at OR as it will allow for feedback from those in the community with vested interests.
[20:25] <hpottinger> +1 mdiggory
[20:26] <mdiggory> so I think having Jonathan and/or some Fedora interests present for the dialog would be good
[20:26] <tdonohue> So, it sounds like there is general agreement to have Jonathan attend for Fedora/DuraSpace/DSpace+Fedora discussions. How long would folks like this session to be? 1/2 hr? 1 hr?
[20:27] <tdonohue> (I'd guess it may be tough to fit into 1/2 hr, unless you just had Jonathan speak)
[20:27] <tdonohue> (but, that's just a guess)
[20:28] <mdiggory> Is the Fedora Devs meeting in parallel to this?
[20:28] <hpottinger> maybe an hour, 1/2 for Jonathan, 1/2 for brainstorm
[20:29] <tdonohue> yes. The Fedora Devs are meeting in parallel to the DSpace Devs. Jonathan is going to split his time between the two meetings...he was hoping to hit DSpace in the morning & Fedora later on
[20:29] <mdiggory> One of my comments was that the Madrid devs meeting dove tailed into a common DSpace/Fedora meeting with social afterwards.
[20:29] <mdiggory> and that was an excellent time for dialog
[20:30] <mdiggory> Serious geekdome over drinks...
[20:30] <tdonohue> We are scheduling in the social meetup between the DSpace & Fedora Devs (after the respective meetings). We'll all be meeting up at the same pub.
[20:30] <richardrodgers> at the very least, we should synchronize on pubs at end of day
[20:30] <mdiggory> at the very least ;-)
[20:30] <hpottinger> +1 pub
[20:30] <tdonohue> I've already talked with Chris Wilper & we will be meeting up at the same pub as the Fedora Devs. Robin Taylor has picked out a recommended pub in walking distance
[20:31] <mdiggory> \me is unable to find drink emoticon...
[20:31] * mdiggory is unable to remember its a forwardslash
[20:31] <PeterDietz> Since I won't be anywhere near Scotland, maybe I'll go out the pub at the same time you guys are there, (6pm - 6 hours = noon on a weekday)
[20:32] <hpottinger> PeterDietz +1
[20:32] <mhwood> Talk about "being there in spirit"....
[20:33] <tdonohue> So, does 1/2 hr for Jonathan to talk to the group sound good? Likely this will be in the morning. I can also slot in 1/2 hour after that for further DSpace + Fedora discussion (if you want it) -- or you can choose to talk about this later in the day during "Open Discussion" or similar
[20:33] <mdiggory> sounds like it could frame the meeting nicely...
[20:33] * tdonohue is trying to make it clear that this meeting is 100% yours. So, definitely let me know if you'd like something changed or different
[20:33] <hpottinger> I think it will be hard not to talk after Jonathan's talk...
[20:35] <tdonohue> ok, 1hr in the morning for "DuraSpace / Fedora -related" discussions it is then. I'll let Jonathan know as well
[20:35] <richardrodgers> tdonohue: morning is good also from the 'dividing' the day into tech/non-tech angle - everyone could hear it
[20:35] <tdonohue> Before we get into what may need to "fall out" of the schedule (from lack of time in a day), I also wanted feedback on the "3.0 Discussions". Is 1hr enough time? Would folks like more time (as mdiggory mentioned)? If so, how much more?
[20:37] <mdiggory> for us, I know that there will be presentations on contributions later in the conference
[20:38] <mdiggory> So my thoughts are more planning, targets/goals, relevance of specific contributions... new strategies for contribution (Pull requests), social changes
[20:39] <tdonohue> mdiggory -- I see a lot of those topics in the schedule already -- for instance there is 1 hr at the end of the day to discussion "Developer practices" (which is meant to talk about GitHub / pull requests / other developer & contribution workflows)
[20:40] <mdiggory> sorry, I should have doublechecked... true
[20:41] <tdonohue> Currently, we have essentially 5 hours of available "meeting time" -- the full meeting is 9am-5pm, with 1.5hr lunch & two 15 min breaks
[20:41] <tdonohue> We've identified we want 1hr = DuraSpace / Fedora stuff
[20:41] <tdonohue> We currently have 1hr = 3.0 Planning & Discussion
[20:42] <richardrodgers> Are there topics of burning interest that *aren't* covered anywhere in the schedule?
[20:42] <tdonohue> 1hr = Developer Workflows/Practices (GitHub & the like)
[20:43] <mdiggory> seems like th 3:$5 Summary and any special topics could fill any gaps if theres more that needs to be discussed about 3.0 planning
[20:43] <mdiggory> 3:45
[20:44] <mdiggory> but its short...
[20:44] <mdiggory> wheres a time dilator when you need it
[20:45] <helix84> mdiggory: you'd need to move really fast for that
[20:45] <helix84> mdiggory: depending on the food, you just might ;)
[20:45] <tdonohue> Yea, I had anticipated that "3:45 - 4pm" Summary timeperiod to just be a time to decide which topics *didn't get discussed enough* and therefore need to have a later "Special Topic Mtg" or similar
[20:46] <tdonohue> So, getting down to it. If we add 1hr for DuraSpace + Fedora discussions, I'm assuming that means we are dropping the "Lightning Talks" and possibly the "Ask a developer anything" sessions. We just don't have enough time to do all of them
[20:46] <tdonohue> Anyone object to that?
[20:47] <hpottinger> I have a really cool visual timer I just picked up, but plan to use that for our talk practicing, so no big deal :-)
[20:48] <tdonohue> I think we *need* to keep the DCAT discussion period (1/2hr). We probably should keep the "Open Discussion" (but it could be decreased from an hr if need be), just for topics that come up.
[20:48] <tdonohue> All that together means we still only have 1hr for "3.0 Discussions" it sounds like. Unless something else drops off. Thoughts?
[20:49] <hpottinger> maybe make part of introductions an answer to the question "tell us one cool thing you're working on right now"
[20:49] <mhwood> Remember that the schedule isn't rigid and will inevitably be reworked.
[20:49] <mdiggory> if you bring Jonathan in for 1/2 hour thats going to need space too
[20:49] <tdonohue> mdiggory -- that's part of the "1hr for DuraSpace + Fedora discussions" -- 1/2 hr of that is Jonathan
[20:50] <mdiggory> maybe we mix open discussion into the end of lunch?
[20:50] <tdonohue> yes, the schedule can be reworked on the day-of if you need to. None of this is set-in-stone :) I'm just trying to get something that seems "reasonable"
[20:50] <mdiggory> lunch is 1 1/2 hours
[20:51] <richardrodgers> having some predictability is nice for folks that might want to drop in...
[20:51] <tdonohue> in order to make time for what? That's my big question here that I'm trying to tease out of you all :) What is missing or needs more time for discussion? If we can figure that out, I'm sure there's ways to create a schedule around it :)
[20:51] <tdonohue> i.e. to all of you, what is the most important thing to get out of this meeting? & are we currently allocating enough time to that "topic"?
[20:52] <tdonohue> currently, in my head, the schedule looks like this:
[20:53] <tdonohue> 1hr = DuraSpace / Fedora (featuring Jonathan)
[20:53] <tdonohue> 1/2hr = DCAT
[20:53] <tdonohue> 1/2hr = Intros & then the Wrap-Up (15 mins each)
[20:53] <tdonohue> 1 hr = 3.0 Stuff
[20:53] <tdonohue> 1hr = Developer Practices & Workflows (GitHub & such)
[20:53] <tdonohue> 1hr? = Open Discussion
[20:54] <tdonohue> (those aren't in order right now, but you get the idea)...in total 5 hrs of active meeting time
[20:54] <hpottinger> I like the ask anything idea, but think it might be better part of the general conference track, or, heck, ask us at the pub
[20:55] <richardrodgers> seems roughly reasonable
[20:55] <tdonohue> yep, you could always do the "ask anything" over lunch too (not sure how the "provided lunch" is going to happen yet, but Stuart & Robin are supposed to be getting more details posted shortly to that page)
[20:55] <mdiggory> I am actually happy with the coverage and the organization of general in morning vs technical in afternoon. You guys have done good thusfar with the planning tdonohue and richardrodgers
[20:55] <mhwood> Yes, Ask Anything and Lightning Talk seem like things that have been done in general sessions in past conferences.
[20:57] <tdonohue> ok, sounds like we have a general plan then :) I can update the draft schedule & send out an update to the lists based on this discussion. (And get in touch with Jonathan about his part in the morning meeting)
[20:57] <mdiggory> I'm wondering how successful Lightning talks are...
[20:57] <hpottinger> +1 mdiggory, tdonohue, that draft schedule looks good to me
[20:58] <richardrodgers> mdiggory: they can be somewhat affected, but we did want a place where perhaps "non-mainstream" DSpace work could be made visible (in an informal way)
[20:59] <mdiggory> they seem good when marketing your work to a larger audience. not sure if they are good in a smaller group setting.
[21:00] <tdonohue> Yea, the original idea that richardrodgers & I brainstormed about "lightning talks" was NOT "show us what you are already talking on later in OR", but rather "show us something cool that you may still be actively working on / not finished, but you want feedback on, etc"
[21:01] <tdonohue> so, the idea was much more informal -- it was more like : "hey, look at this cool thing I'm messing around with (that is a total hack). Anyone else doing something like this, or have ideas on how to make it better"
[21:01] <hpottinger> I do think that in this smaller group, just mentioning what you're working on during intros works, we'll have/make time to show off to those interested later in the conference
[21:01] <tdonohue> +1 hpottinger: yea, you may just be able to mention topics of interest / stuff you are working on as you go around the room doing Intros
[21:03] <tdonohue> I see we are over time already :( And I know that helix84 was looking for a bit of feedback on DS-1193 today, if we could get to it.
[21:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1193 ] - [#DS-1193] display bitstream read access permissions on item page - DuraSpace JIRA
[21:04] <aschweer> sorry, I need to leave -- bye all
[21:04] * tdonohue notes if folks need to leave, it's OK. I think we are done with the OR12 discussion, but I'm gonna stick around for a quick discussion of DS-1193 for any interested
[21:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1193 ] - [#DS-1193] display bitstream read access permissions on item page - DuraSpace JIRA
[21:04] * aschweer (~aschweer@ip-118-90-91-194.xdsl.xnet.co.nz) has left #duraspace
[21:05] <mdiggory> some of my points from the email thread
[21:05] <richardrodgers> I've got to run also - but welcome helix84 !
[21:05] * richardrodgers (~richardro@dhcp-18-111-8-152.dyn.mit.edu) Quit (Quit: richardrodgers)
[21:05] <mdiggory> 1.) We need to be careful about disclosing groups and users that have permissions such as WRITE and DELETE
[21:05] <mdiggory> to the public
[21:06] <mhwood> Yes, I think that the essential information here is "can *I* get it?"
[21:06] <mdiggory> 2.) Its generally good not to make the METS document have to be rerendered for every single request.
[21:06] <mdiggory> so that caching can be effective.
[21:06] <mdiggory> so filtering these in the METS sections based on permissions is a bit heavy
[21:07] <KevinVdV> Needs to run, until next time
[21:07] <helix84> 1) In my proposal, that wouldn't be an issue. XMLUI would show only READ access and if it can be done, the METSRights info would be accessible only from localhost (for XMLUI)
[21:07] * KevinVdV (~kevin@d54C154B1.access.telenet.be) Quit (Quit: KevinVdV)
[21:07] <mdiggory> we have the ability to have METS "point" at additional resources that may be protected.
[21:07] <mdiggory> in techMD sections
[21:07] <mdiggory> thus we could have separate requests for METS Rights outside the mets document
[21:08] <mdiggory> or we could just restrict access to METS and DRI remotely.
[21:08] <tdonohue> mdiggory: adding those separate requests for METSRights though -- isn't that a big overhaul to how XMLUI works? I think we're looking for "simple" :)
[21:09] <mdiggory> not really very hard at all...
[21:09] <mdiggory> its just some sitemap additions and generators.
[21:09] <helix84> so what's your idea of be the best approach?
[21:10] * hpottinger has to go, will check the transcript later tonight.
[21:10] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:10] <mdiggory> both approaches helix and I are proposing are sensible... the approach I'm being wary of is attempting to filter or modify the results of the METS rendering based on your current permissions.
[21:11] <helix84> mdiggory: by current permissions you mean group membership of logged in user?
[21:11] <mdiggory> Hunting for a good word to describe what I mean....
[21:11] <mdiggory> yes correct
[21:12] <helix84> because of bad impact on caching?
[21:12] <mdiggory> Ah yes... Stateless.
[21:12] <helix84> so basically, you agree with my A) part, but disagree with my B) part, right?
[21:13] <mdiggory> Individual metadata requests should be stateless... DRI is generally not (in some cases it is, but most DRI pipes fail caching)
[21:14] <mhwood> Oops, I have to go. 'bye!
[21:14] <tdonohue> One clarification on "Problem A)" description, currently you can tell the XMLUI to run *ANY* DSpace Crosswalk just by passing the crosswalk name in as a request param (not just the METSRightsCrosswalk). You could just as easily pass another Crosswalk name in and the XMLUI will run it as it tries to generate the METS
[21:14] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:15] <mdiggory> true true
[21:15] <tdonohue> (It's both extremely powerful for developers, and also something that likely shouldn't be publicly available to anyone in the world)
[21:15] <helix84> my A) is stateless and suggests restricting access from localhost. my B) is stateful.
[21:15] <helix84> so is A) agreeable as-is?
[21:15] <mdiggory> helix84: I'm not sure if I disagree with B
[21:16] <mdiggory> I'm trying to determine the most appropriate manner to capture this detail...
[21:17] <mdiggory> we did create a line in the sand that DRI is more page configuration while METS is the content of an object
[21:19] <mdiggory> I can say we are already heading down an interesting road with some of our current discovery work, we are filtering Items from results based on users permissions.
[21:19] <helix84> what about disabling parameters to METS (the crosswalks) so that it can be cached well and making the crosswalk results accessible separately (with the possibility of restricting them)?
[21:19] <mdiggory> so, its not the XSLT tier that this filtering happens, but the Content generation tier
[21:20] <helix84> mdiggory: yea, I hate that the power of XSLT is so limited in DSpace...
[21:21] <tdonohue> mdiggory -- so, if you filter from results, if you searched while *not logged in* you'd get different results than searching *while logged in*? Couldn't that be confusing? (Or will it somehow let you know that you should login before searching to get the full results list?)
[21:21] <mdiggory> so, lets say I have /metadata/handle/1234.5/6/mets.xml
[21:21] <mdiggory> and it has technical and descriptive metadata sections that describe
[21:21] <helix84> tdonohue: it's what google started doing several years ago
[21:23] <mdiggory> that describe MDRef to other metadata/handle/1234.5/6/rights.xml and so on
[21:23] <helix84> right
[21:23] <mdiggory> then these xml forms are protected if neccessary
[21:24] <mdiggory> the presentation of various TechMD, AdmnMD and DescrMD sections could be driven by your crosswalk configuration settings
[21:25] <mdiggory> such that the UI would have references to these various representations and XSLT developers could make choices if they do or do not want to traverse the document() method and retrive them for rendering
[21:26] <mdiggory> this can even apply to the case of rendering citations to enusers in various formats.
[21:26] <mdiggory> enusers = endusers
[21:26] <helix84> yes, that's what i meant
[21:27] <mdiggory> note, this is similar to our approach for providing Dryad ris and bib citation formats...
[21:27] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Item+Versioning+Support#ItemVersioningSupport-ServicestosupportVersioningandAlternativeIdentifiers.
[21:27] <kompewter> [ Item Versioning Support - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Item+Versioning+Support#ItemVersioningSupport-ServicestosupportVersioningandAlternativeIdentifiers.
[21:28] <mdiggory> I think the important point is that we don't try to render all these representations embedded in METS, that would impact performance, but instead render links to query them independently and be able to manage access controls on them where appropriate
[21:29] <helix84> that would be fine for me, but I'm not able to change the code to do the separation and right management
[21:30] <mdiggory> I do agree with the whole effort your taking to access this level of detail in the pipeline
[21:31] <mdiggory> right now I think we need to not get too bogged down in the access management (we could alter the metadata pipeline to improve access control.
[21:31] <helix84> i agree
[21:32] <helix84> After all, it can be done (provisionally) in Apache HTTPD and maybe in Tomcat, too. It's been exposed until now and noone seemed to mind.
[21:33] <mdiggory> Looking more at...
[21:33] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap#L431
[21:33] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap#L431
[21:33] <mdiggory> At this time, the crosswalks all embed into the mets.xml rendering...
[21:33] <mdiggory> we need something separate...
[21:34] <helix84> and preferably standards-compliant
[21:34] <mdiggory> that interacts via a separate request
[21:34] <mdiggory> ie.... metadata/handle/*/*/[crosswalk]
[21:35] <tdonohue> yea, that's what I was saying when I meant this "may not be as easy". You'd need to rework the current XMLUI METS rendering stuff. It's possible to do, it just may take some investigation.
[21:36] <helix84> tdonohue: is there currently some code in stock DSpace that uses some crosswalk in this way?
[21:36] <tdonohue> Currently the "DSpaceMETSGenerator" in XMLUI handles whether a crosswalk is kicked off or not (and currently by default, only DIM & MODS crosswalks get kicked off by default, unless you pass in more crosswalks as request params)
[21:36] <mdiggory> in the IdentifierServices work... we shifted this into Spring
[21:36] <tdonohue> helix84: not really, or not that I can think of off the top of my head
[21:36] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/java/org/dspace/springmvc/ResourceIdentifierController.java
[21:37] <mdiggory> @RequestMapping("/resource/{prefix}/{suffix}/citation/ris")
[21:37] <helix84> tdonohue: you said no but you mentioned DIM & MODS - I'm confused
[21:37] <mdiggory> DAP View uses Crosswalks
[21:37] <mdiggory> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/java/org/dspace/springmvc/DapView.java
[21:38] <tdonohue> oh wait, I may have misunderstood your question, helix84...sorry :)
[21:38] <helix84> mdiggory: you lost me at Spring
[21:38] <mdiggory> we could have been a bit more generic in our exposing crosswalks ... parameterizing the path and such
[21:38] <mdiggory> Spring... you know... green trees and rain...
[21:39] <mdiggory> sorry...
[21:39] <helix84> ...and coffe beans... not my favourite, remember? :)
[21:39] <tdonohue> So, the way the Crosswalks currently work in the XMLUI is like this....
[21:39] <mdiggory> pay more attention to the code inside the methods than the framework...
[21:40] * ryscher peeks in, mutters something about excessive abstraction being the root of all evil, and quickly hurries away
[21:40] <mdiggory> ha
[21:40] <tdonohue> (1) You request a path ending in 'mets.xml', and then the DSpaceMETSGenerator is called: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/cocoon/DSpaceMETSGenerator.java
[21:40] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/cocoon/DSpaceMETSGenerator.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/cocoon/DSpaceMETSGenerator.java
[21:41] <mdiggory> this is correct
[21:41] <tdonohue> (2) The DSpaceMETSGenerator looks for params passed into the request and then calls the ItemAdapter (the class that actually generates METS for items): https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java
[21:41] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java
[21:42] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java#L350
[21:42] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java#L350
[21:43] <tdonohue> (3) The ItemAdapter has several methods which load up DisseminationCrosswalks, including "renderDescriptiveSection()", "renderAdministrativeSection()", etc.
[21:43] <tdonohue> mdiggory just linked to one example in the "renderDescriptiveSection()" method
[21:43] <mdiggory> correct, heres the admin method
[21:43] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java#L472
[21:43] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java#L472
[21:44] <mdiggory> and where things like premis are corsswalked into such sections
[21:44] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java#L619
[21:44] <kompewter> [ DSpace/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java#L619
[21:44] <tdonohue> Yep, as mdiggory notes, most of these sections are empty by default (unless you pass in a request param specifying the Crosswalks to add)
[21:45] <helix84> i generally understand (which doesn't mean I would be able to make changes - parameter->url)
[21:46] <mdiggory> We (@mire) did do some things where we add plug-ability to these sections allowing us to inject our own mdWrap/xmlData from addons.
[21:47] <tdonohue> So, as I showed, you can get those sections to auto-fill out just by passing Crosswalk names to the appropriate params...if you know the right request param, you can insert any Crosswalk's output into any METS section :)
[21:47] <mdiggory> tdonohue: what do you think about adding external mdRef sections to separate URI to render those sections outside the METS?
[21:48] <tdonohue> I think it sounds like a nice idea, but I wonder how you maintain it over time as you add new crosswalks. We'd need a way to easily enable/disable new crosswalks into sections as appropriate. But, the idea sounds fine
[21:49] * helix84 is waiting for mdiggory to mention Spring & beans for configuration
[21:49] <mdiggory> Yes, I think there would need to be configuration for what is exposed int he UI same as there si for what is exposed in OAI.
[21:49] <tdonohue> "Spring is the answer to everything!" -- quote attributed to Mark Diggory, 2012
[21:50] <mdiggory> hey man... now thats gonna get taken out of context....
[21:50] <mdiggory> ;-)
[21:50] <tdonohue> haha :)
[21:50] <helix84> "can't beat the simplicity of key = value" ~~helix84, before being murdered by axe
[21:51] * mdiggory where the hell's my axe again?
[21:51] <mdiggory> gmail.com
[21:52] * tdonohue notes I unfortunately have to leave shortly... I do like the general direction here though, just be nice to figure out some next steps. I'll have to check back into this logs later tonight/tomorrow
[21:52] <mdiggory> opse
[21:52] <helix84> mark, do you happen to have this problem? http://xkcd.com/477/
[21:52] <kompewter> [ xkcd: Typewriter ] - http://xkcd.com/477/
[21:53] * helix84 is not amused that Tim approves of the general idea of new commiters being murdered
[21:53] <mdiggory> ROTFL
[21:53] <tdonohue> xkcd for the win :) Ok, gotta go, I'll catch back up later
[21:54] <tdonohue> whooops - now that was taken out of context :) HAHA
[21:54] <tdonohue> just for the record "I do not approve of committers being murdered by axes" :) Ok, now really need to head out of here. have a good one
[21:55] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:55] <mdiggory> I'm still going to use it out of context ;-) maybe OR12 Developers meeting, hmmmm, yes, perfect....
[21:56] <helix84> So Mark, I really don't think I'll be able to do those changes (but I approve of them). So what are the next steps? Are you willing to do the parameter->url transition? Or should I just go ahead with my current code for now?
[21:58] <mdiggory> I'd say start first with your approach with the parameter... the change later would be that instead of looking in the METS document, that someone need to write a crosswalk transformer or generator to add to /metadata/
[21:58] <mdiggory> and the xslt code would change a little
[21:59] <helix84> yes, since it would process a different document, the value for each file would need to be stored in a variable in a template processing the crosswalk output and used in the template processing mets
[21:59] <helix84> however, since there can be multiple bitstreams, I'm not sure how to do that with multiple variables (XSLT doesn't have arrays)
[22:00] <mdiggory> Is the METSRights already specific to the bitstreams?
[22:00] <helix84> sure it is
[22:00] <helix84> see my screenshot
[22:00] <mdiggory> going back to
[22:00] <mdiggory> http://demo.dspace.org/xmlui/metadata/handle/10673/3/mets.xml?rightsMDTypes=METSRIGHTS
[22:01] <helix84> off-topic: there's something rotten in the state of demo.dspace.org: qualifier="degreee"
[22:02] <mdiggory> that qualifiers when the student takes 10 years to complete theirs
[22:02] <helix84> there's mets:rightsMD for each bitstream
[22:03] <mdiggory> right so in the METS you would still have
[22:03] <mdiggory> ADMID="rightsMD_file_580_METSRIGHTS"
[22:04] <mdiggory> and the amdSec
[22:04] <mdiggory> <mets:rightsMD ID="rightsMD_file_580_METSRIGHTS">
[22:04] <mdiggory> but then
[22:04] <mdiggory> <mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="METSRIGHTS">
[22:04] <mdiggory> would be a mets:mdRef
[22:04] <helix84> wait, AMDID isn't there if the crosswalk isn't requested (currently)
[22:04] <mdiggory> and a URI pointing out to the representation of <RightsDeclarationMD
[22:05] <mdiggory> correct
[22:06] <helix84> were you thinking of somehow naming the variable based on AMDID?
[22:07] <helix84> (I'm still not sure that's even possible)
[22:10] <helix84> ping?
[22:10] <mdiggory> making you an example
[22:11] <mdiggory> <mets:rightsMD ID="rightsMD_file_580_METSRIGHTS">
[22:11] <mdiggory> <mets:mdRef xlink:href="metadata/handle/1234.5/6/[sequenceid]/[filename.ext]/Rights.xml" LOCTYPE="URL" MDTYPE="OTHER" OTHERMDTYPE="METSRIGHTS"/>
[22:11] <mdiggory> </mets:rightsMD>
[22:11] <mdiggory> this would be in the mets.xml
[22:11] <mdiggory> and this would be at the end of that URL
[22:11] <mdiggory> <RightsDeclarationMD xmlns:rights="http://cosimo.stanford.edu/sdr/metsrights/" xmlns="http://cosimo.stanford.edu/sdr/metsrights/" RIGHTSCATEGORY="LICENSED">
[22:12] <mdiggory> <Context CONTEXTCLASS="GENERAL PUBLIC">
[22:12] <mdiggory> <Permissions DISCOVER="true" DISPLAY="true" MODIFY="false" DELETE="false"/>
[22:12] <mdiggory> </Context>
[22:12] <mdiggory> </RightsDeclarationMD>
[22:12] <mdiggory> but I would expect more detail than that....
[22:13] <mdiggory> Actual ResourcePolicies that are better serialized
[22:13] <helix84> yes, that's what we were talking about all the time
[22:13] <mdiggory> I think the challenge is that this does make it the XSLT tiers job to properly filter resources based on these permissions
[22:14] <mdiggory> is the above representation best to accomplish that?
[22:14] <mdiggory> should it be stateless and the XSLT needs to compare the groups assigned tot he User vs the permissions int he xml?
[22:15] <mdiggory> or should the above URI return a set of rights based on the current users state
[22:15] <helix84> it would be a good representation - if I could only figure out the problem I mentioned of getting information from a template matching "rights" to the template matching "mets" *for multiple bitstreams*
[22:16] <mdiggory> thing is that these.... <Context CONTEXTCLASS="GENERAL PUBLIC"> are not group names...
[22:16] <helix84> yes to the idea of comparing groups, that's what I meant in B)
[22:17] <helix84> group names are elsewhere, wait
[22:17] <mdiggory> in the users org.dspace.core.Context...
[22:19] <helix84> in rights:RightsDeclarationMD/rights:Context/rights:UserName
[22:19] <helix84> well, more precisely in rights:RightsDeclarationMD/rights:Context/rights:UserName[@USERTYPE = 'GROUP']
[22:21] <helix84> and I'm not even sure if in DSpace you can assign rights to an individual (which would make @USERTYPE = 'INDIVIDUAL' unused)
[22:22] <mdiggory> I see what you mean
[22:24] <helix84> (what i said about INDIVIDUAL is not a problem, only an observation)
[22:29] * vtkeithg (~vtkeithg@vtkeithg.lib.vt.edu) has left #duraspace
[22:30] <helix84> are you still looking at it or shall we make some conclusion?
[22:57] * ryscher (ae61f77a@gateway/web/freenode/ip.174.97.247.122) Quit (Quit: Page closed)
[23:58] <mdiggory> I need to conclude, other projects pulled me away
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.