Timestamps are in GMT/BST.
[6:55] -morgan.freenode.net- *** Looking up your hostname...
[6:55] -morgan.freenode.net- *** Checking Ident
[6:55] -morgan.freenode.net- *** Found your hostname
[6:55] -morgan.freenode.net- *** No Ident response
[6:56] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:56] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:56] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:38] * ruckus (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[8:38] * ruckus is now known as fasseg
[9:43] * fasseg (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[10:27] * ruckus (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[12:16] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:46] * ruckus (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[12:48] * fasseg (~fas@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[14:01] * barmintor (~ba2213@franklin.cul.columbia.edu) has joined #duraspace
[14:59] * kstamatis (25067746@gateway/web/freenode/ip.37.6.119.70) has joined #duraspace
[15:11] * kstamatis (25067746@gateway/web/freenode/ip.37.6.119.70) has left #duraspace
[15:33] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[15:50] * fasseg (~fas@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[16:33] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (*.net *.split)
[16:34] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[16:45] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (*.net *.split)
[16:45] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[17:02] * Kstamatis (25067746@gateway/web/freenode/ip.37.6.119.70) has joined #duraspace
[17:21] * Kstamatis (25067746@gateway/web/freenode/ip.37.6.119.70) has left #duraspace
[18:00] * bollini (~chatzilla@host9-29-dynamic.51-79-r.retail.telecomitalia.it) has joined #duraspace
[18:01] * bollini (~chatzilla@host9-29-dynamic.51-79-r.retail.telecomitalia.it) Quit (Client Quit)
[19:20] * kstamatis (25067746@gateway/web/freenode/ip.37.6.119.70) has joined #duraspace
[19:21] * helix84 (a@195.113.97.174) has joined #duraspace
[19:52] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:59] * sands (~sandsfish@18.189.31.239) has joined #duraspace
[19:59] * bollini (~chatzilla@host9-29-dynamic.51-79-r.retail.telecomitalia.it) has joined #duraspace
[20:00] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:01] <sands> Hello everyone, welcome to the meeting!
[20:02] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:02] <PeterDie_> hi
[20:02] * hpottinger cheers.
[20:02] <bollini> hi
[20:02] <sands> So today's topic is 100% focused on, as you might expect, DSpace 3.0
[20:02] <PeterDie_> Pre-meeting note, I'm working on the Elastic Search contribution for statistics
[20:03] <sands> PeterDie_ that's already on the Release Notes page, right?
[20:03] * sands heads to the release notes page.
[20:03] <sands> yup, there it is
[20:03] * hpottinger cheers for PeterDie_
[20:04] <sands> So to start, I'd like to forego the JIRA ticket review that we normally do, so as to spend more time on release discussions. Is everyone ok with that?
[20:04] <PeterDie_> there was some ambiguity, I figured I'd atleast get something polished for contrib, hopefully so it can be included
[20:04] * helix84 joins the head cheerleader
[20:04] <PeterDie_> skip jira is fine with me
[20:05] <mhwood> OK here
[20:05] <helix84> ok
[20:05] <sands> We'll be referencing tickets in the discussions anyway.
[20:05] <bollini> ok
[20:05] <hpottinger> +1 forego JIRA review for refocus
[20:05] <sands> My hope is that we can touch on the upcoming contributions briefly, and make sure there is coverage for moving them forward.
[20:05] <sands> So I'm using the release notes as a guide here...
[20:06] <sands> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes
[20:06] <kompewter> [ DSpace Release 3.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+3.0+Notes
[20:06] <sands> thank you kompewter
[20:06] <kompewter> sands: You're welcome.
[20:06] <sands> :P
[20:06] <sands> The goal being to make sure nothing falls through the cracks and any concerns are voiced.
[20:06] <sands> So let's start at the top, unless anyone has any comments.
[20:07] <sands> @Mire has a number of great (and large) contributions here.
[20:07] <sands> mdiggory, can you speak to what you think needs to be looked at the most?
[20:08] <sands> Also, if anyone has any other comments on the @mire contributions, please share.
[20:09] <mdiggory> The feedabck on embargo has been trivial so far.
[20:09] <mdiggory> We need feedback on discovery
[20:10] <mdiggory> versioning will have a pull request created for it by the end of the week.
[20:10] <sands> Mark, does @mire have a demo instance that these features are running on already for people to play with, or is it necessary to build an instance to interact with them?
[20:10] <robint> mdiggory: what are you looking for with respect to Discovery ? Just general testing and feedback ?
[20:11] <mdiggory> basically a second (or in this case 3rd) set of eyes looking for obvious problems.
[20:12] <bollini> what do you expect about the jspui porting? should we include also the new enhancements?
[20:12] <mdiggory> tbh, at this point we are not really looking for big design dialogs around any of our contribs, a great deal of design dialog already happened, especially for embargo and versioning.
[20:13] <robint> fine by me
[20:14] <robint> Are there likely to be any conflicts between the Cilea and @Mire Discovery work ?
[20:14] <sands> i think that is understandable, especially considering the breadth of the work that has already been implemented.
[20:14] <mdiggory> bollini: I would basically recommend that we first focus on everyone getting their code onto the stage so that it can be commited via a pull request, then address integration issues only if they arise.
[20:14] <bollini> ok, we should be able to meet our deadline 13 August for the pull request
[20:16] <sands> robint: I'm interested in that as well.
[20:16] <mdiggory> I agree, I'd address integration issues that arise after the freeze date, focusing this time about assuring we do know whats to be included in 3.0, not achieving perfection in the inclusions.
[20:17] <sands> not just code conflicts, but consistency of functionality. i don't think it needs to gate any of the contributions, but we want to understand what we're putting into the release and how to set expectations about the functionality available in it.
[20:17] <bollini> I'm not worry about api conflict or other technical issues, only concerned about users expectation
[20:17] <bollini> exactly
[20:18] <helix84> we can polis that during the testing phase when we can see all the code in action
[20:18] <mdiggory> user expectation is managed through documentation
[20:18] <helix84> s/polis/polish/
[20:18] <kompewter> helix84 meant to say: we can polish that during the testing phase when we can see all the code in action
[20:18] <sands> it seems to me (please correct me if i'm wrong) that including both of these discovery enhancements will diverge what "discovery" is on JSPUI vs. XMLUI
[20:18] <bollini> it could be difficult to explain that some things work differently between xmlui and jspui for discovery
[20:18] <helix84> bollini: could you draft a brief list on the wiki?
[20:19] <sands> mdiggory: agreed. but we need to understand exactly what we've got in hand here and what's different. does @mire have any plans to port new discovery features to JSPUI, or should we consider this a divergence?
[20:19] <sands> at the same time i'm curious about the reverse (CILEA contributions for XMLUI eventually?)
[20:20] * helix84 notes that it's been a guideline for a while that there doesn't necessarily have to be feature-parity between interfaces
[20:20] <sands> helix84: yup. just wanna be clear, since we're calling it discovery on both sides.
[20:20] <bollini> I'm not exclude that we could be able to port the new enhancements to the jspui
[20:20] <kshepherd> morning all, sorry for lateness (currently on teh bus)
[20:21] <sands> welcome kshepherd
[20:21] <bollini> I have just not yet take a look to the new enhancement from a technical point of view
[20:21] <sands> we're currently discussing @mire contributions to 3.0, ATM specifically Discovery enhancements.
[20:21] <mdiggory> sands: no plans to port to JSPUI at this time
[20:21] <sands> mdiggory: ok
[20:21] <helix84> i say let's get the contributions in and we can polish them during testing and in minor releases
[20:22] <mdiggory> sands: but we are glad to advise and discuss how to approach porting if theres an interested party
[20:22] <kshepherd> cool, i'm pretty keen to test/review the discovery stuff..
[20:22] <mdiggory> stepping back to Advanced Embargo
[20:22] <bollini> can I do some basic questions about these last enhancements?
[20:22] <mdiggory> bollini: you go first
[20:23] <sands> yes, please feel free, though i want to make sure we move to some of the other contributions after @mire. let's say at half-past.
[20:23] <bollini> how do you filter unauthorized content in search results? do you index what?
[20:23] <sands> we can have further discussions on devel in between meetings.
[20:24] <bollini> I'm concerned about performance implication (at indexing time) of Access Rights Awareness
[20:24] <helix84> in the interest of covering the most contributions today i'd like to politely suggest Andrea to contact Mark by email (CC to mailing list is welcome)
[20:25] <KevinVdV> Bollini: we have a plugin that adds the group names and eperson identifiers to the solr document upon indexing and we have a plugin that will add all group identifiers to each query
[20:26] <KevinVdV> This feature can easily be disabled and should work out of the box with jspui as this is back end only
[20:26] <sands> bollini: is taking further discussions about this to the mailing list ok with you?
[20:26] <bollini> ok (hope to find time for this ;-) )
[20:26] <sands> ok, embargo then?
[20:27] <sands> anyone planning on implementing this, or concerns that we should spin threads for?
[20:27] <kshepherd> there's also #dspace for unmoderated chat..
[20:27] <sands> kshepherd: yes, good to remember, thanks.
[20:28] <sands> i ask about any potential implementors because they are usually the best ones to get feedback from.
[20:29] <sands> if there are no comments at the moment, i would ask anyone who is excited about this feature to review the contribution and share feedback with @mire and the community.
[20:29] <sands> next on the list is Ivan's contributions.
[20:30] <sands> it looks like he defers OAI work to the Lyncode implementation.
[20:30] <mdiggory> Per Embargo, about the only thing left is to "squash" all the commits into one and do some minor reformating of the code.
[20:30] <helix84> the XSL from EPrints has been obsoleted by the new XSLT in Lyncode's XOAI
[20:30] <helix84> and based on encouragement from Mark on dspace-release today, I plan to hit the Merge button on XOAI
[20:31] <helix84> the other two things are very minor
[20:31] <helix84> unless you have some comments on robots.txt
[20:31] <mdiggory> note we have 26 pull requests at the moment
[20:31] <mdiggory> https://github.com/DSpace/DSpace/pulls
[20:31] * kshepherd will try to give the XOAI stuff a test
[20:31] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls
[20:31] <mdiggory> this is the bottleneck I refer to that is forming....
[20:31] <sands> unless anyone has other concerns about this, i'd say +1 to that. the discussion on list seems to have come to a rough consensus that it is ready.
[20:32] <kshepherd> i think part of that could be all of us getting used to Git
[20:32] <sands> only question i have is are we pulling the former OAI from the 3.0 release.
[20:32] <kshepherd> you could say that there were times there were far more than 26 patches sitting uncommitted in JIRA, it just wasn't as obvious ;)
[20:32] <helix84> based on mdiggory's suggestion, that's how Lyncode rewrote the pull request
[20:33] * mdiggory ducks for cover
[20:33] <helix84> i now tend to agree that it's in all aspects better then OAI 1.0
[20:33] <helix84> the major point being you can configure it to use SQL instead of Solr
[20:34] <sands> helix84: i haven't actively tested it, but it does seem like it's been vetted and seems to be backward compatible. and yes, it is great that you can set it to not require Solr.
[20:34] <kshepherd> not require solr? since when did oai require solr?
[20:35] <robint> The new XOAI uses solr
[20:35] <kshepherd> ohhh gotcha
[20:35] <helix84> OAI 1.0 has SQL data source. OAI 2.0 has Solr by default, but SQL can be configured (in case you don't want to isntall Solr)
[20:36] <helix84> i'd like to repeat here that Lyncode has been extremely prompt in adressing any comments, so any addditional ones can be ironed out during testing after freeze
[20:36] <sands> helix84: agreed
[20:37] <sands> if there are no other questions, let's assume that XOAI is going in...
[20:37] <kshepherd> yeh, definitely needs a good thrashing in testathon if it's replacing existing OAI.. it's a critical service for a lot of repo managers
[20:37] <kshepherd> and hey, since we're talking about pulling out the old oai module...
[20:37] <kshepherd> can we get rid of lni yet? ;)
[20:38] <helix84> [off-topic discussion detected]
[20:38] <helix84> [kicking the intruder]
[20:38] <helix84> :)
[20:38] <kshepherd> ok sorry, whatever
[20:38] <kshepherd> work time now anyway
[20:38] <robint> kshepherd: believe it or not we have a number of installations that use LNI
[20:38] * kshepherd goes
[20:38] * hpottinger believes it
[20:38] <robint> Happy to discuss more later
[20:39] <sands> unfortunately MIT still has a user that demands using LNI. :( but yes, a discussion should happen there. maybe pulling it from the core release
[20:39] <sands> everyone ok with this? seems like a no-brainer to me: https://jira.duraspace.org/browse/DS-1138
[20:39] <kompewter> [ [#DS-1138] robots.txt - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1138
[20:39] <helix84> hey! i just realized, REST is not on the release notes page, is it going in for 3.0?
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1138 ] - [#DS-1138] robots.txt - DuraSpace JIRA
[20:39] <sands> this is Ivan's next contribution.
[20:39] <mhwood> Still need a way to pull stuff out of the core release. Topic for another day.
[20:39] * sands exclaims about the REST realization too!
[20:40] <sands> oversight?
[20:40] <hpottinger> mhwood +1 we had a discussion about the need to figure out our deprecation process at OR12
[20:40] <robint> helix84: There is a big whole in dspace-rest, it doesn't check authorisation
[20:40] <helix84> too big to close after freeze?
[20:41] <helix84> how about a big Beta(tm) label?
[20:41] <robint> Needs a volunteer
[20:41] <mhwood> Needs a way to turn it off, if not.
[20:41] <helix84> worked for Gmail ;)
[20:41] <robint> whole/hole (5 lines ago)
[20:42] <sands> or we include it with a Caveat that it doesn't respect auth yet.
[20:42] <sands> could be useful to institutions that don't have any sensitive content.
[20:43] <helix84> Discovery has been significantly improved from 1.7 to 1.8, let's try it here, too
[20:43] <sands> ok, another thread there. this is good.
[20:43] <mdiggory> lni could always be released as a separate addon.
[20:44] <robint> mdiggory: agreed, that needs to be the route rather than making our distro bigger and bigger
[20:44] <mdiggory> per REST... I'd consider the folks at Fedora just worked very hard on their REST implementation... theres something to learn there...
[20:44] <hpottinger> +1 mdiggory, I think we could formalize that into a deprecation process, anything we want to deprecate we funnel into an addon
[20:45] <sands> hpottinger: +1
[20:45] <hpottinger> re: REST, I'd be OK with it being all open access, as long as that doesn't apply to write actions
[20:45] <mdiggory> http://duraspace.org/now-available-fedora-35
[20:45] <kompewter> [ NOW AVAILABLE: Fedora 3.5 | DuraSpace ] - http://duraspace.org/now-available-fedora-35
[20:45] <mhwood> REST is a separate webapp we can just not deploy, right?
[20:46] <helix84> correct
[20:46] <sands> mhwood: right
[20:46] <mdiggory> Spring based CFG, One standardized WAR file, no longer need FEDORA_HOME env setting,
[20:47] <helix84> sidenote: Lyncode is also reworking cfg as part of their SpringUI
[20:47] <sands> since we're 15 minutes from the formal end of the meeting, i'd like to press on and see if we can't identify any other topics that can be discussed on list.
[20:47] <sands> Ivan's SFX button support and robots.txt contributions seem straightforward. i'm guessing after a quick look, we can push those into the release.
[20:47] * hpottinger was thinking of tinkering more with REST, is a bit worried about no auth... will move it higher up on the "play with soon" list
[20:47] <sands> Next is SeDiCl
[20:48] <helix84> will any other contribution from CILEA be ready for 3.0?
[20:48] <robint> I would like to promote https://jira.duraspace.org/browse/DS-1127
[20:48] <kompewter> [ [#DS-1127] Submission improvements: document type-based submission - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1127
[20:48] <kompewter> [ https://jira.duraspace.org/browse/DS-1127 ] - [#DS-1127] Submission improvements: document type-based submission - DuraSpace JIRA
[20:48] <PeterDie_> I'm thinking REST should be something thats not visible outside your firewall, until auth is strong
[20:48] <robint> DS 1127 is something repo admins have long campaigned for
[20:49] <helix84> PeterDie_: so we could restrict it to localhost by default, like Solr
[20:49] <mdiggory> helix84: why does not Lyncode come talk to those of working on the ServiceManager and ConfigurationService? We don't need a new configuration service, we need adoption of the one we all agreed to add to DSpace when the ServiceManager was added.
[20:49] <sands> PeterDie_: sounds like something we could leave to the implementor. i'd hate to handicap it when there are system-level ways to restrict access.
[20:50] <bollini> helix84: we have already in place the pubmed integration (the work has been done by I collegue: Andrea Pascarelli) but I'm concerned about the new concurrent proposals : totalimpact and altmetrics
[20:51] <bollini> helix84: also the browse system based on SOLR should be ready in time
[20:51] <mdiggory> PeterDie_: adding it doesn't mean it needs to be enabled by default
[20:51] <helix84> mdiggory: i think you briefly talked about that with him. Feel free to email him, although he's on vacation ATM. All I know is from here: https://wiki.duraspace.org/display/~lyncode/Dynamic+Configurations
[20:51] <kompewter> [ Dynamic Configurations - DSpace @ Lyncode - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~lyncode/Dynamic+Configurations
[20:52] <mdiggory> Yes, thats not very sufficient
[20:52] <helix84> bollini: I have something similiar to your Pubmed, for Web of Science and Scopus, almost pure javascript, but for XMLUI
[20:52] <mhwood> Sounds like we need to get the metrics people all together for a talk.
[20:52] <helix84> mdiggory: anyway, that's post-3.0, plenty of time
[20:53] <mdiggory> agreed
[20:53] <sands> mhwood: agreed
[20:54] <sands> apropos type-based submissions, i know that rrodgers had done some work in this area he might want to share details about with the current implementation, but he's on vacation this week.
[20:54] <mdiggory> Are there folks out there that don't know how to setup a Pull request?
[20:54] <sands> i'll pass it along to him.
[20:54] <robint> sands: thanks. If he has no objections I hope to commit early next week.
[20:55] <sands> mdiggory: there's documentation out there, yes?
[20:55] <sands> robint: great. i'll make sure he gets back to you ASAP.
[20:55] <helix84> one question in relation to git - do we want to rebase (squash) multi-commit pull requests before merge?
[20:55] <sands> robint: do you need feedback on the other 3 contributions?
[20:56] <mdiggory> its down inside the docs, but I'm just verifying if anyone listening is struggling to bring their changes to github and setup their pull requests.
[20:56] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Development+with+Git
[20:56] <robint> sands: I confess I haven't had time to look at them yet :(
[20:56] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git
[20:56] <mdiggory> and its not "complete"
[20:56] * mhwood is struggling with whether a given branch is ready for a pull request. :-/
[20:56] <mdiggory> ThinkUP github
[20:57] <mdiggory> opse...
[20:57] <mdiggory> that was meant to be a google search
[20:57] <bollini> I haven't looked in detail to the DS-1234 but I don't like the general idea
[20:57] <helix84> mdiggory: that multi-purpose address bar gets under one's skin quickly, doesn't it? ;)
[20:57] <kompewter> [ https://jira.duraspace.org/browse/DS-1234 ] - [#DS-1234] Edit an Item using the workflow process - DuraSpace JIRA
[20:57] <mdiggory> someday... with effort our guide should look more like this...
[20:57] <mdiggory> https://github.com/ginatrapani/ThinkUp/wiki/Developer-Guide
[20:57] <kompewter> [ ThinkUp Developer Guide · ginatrapani/ThinkUp Wiki · GitHub ] - https://github.com/ginatrapani/ThinkUp/wiki/Developer-Guide
[20:58] <mdiggory> http://thinkupapp.com/docs/contribute/developers/devfromsource.html
[20:58] <kompewter> [ Develop from Source — ThinkUp 1.0.8.1 documentation ] - http://thinkupapp.com/docs/contribute/developers/devfromsource.html
[20:58] <mhwood> bollini: your concerns?
[20:58] <helix84> bollini: perhaps you'd like something along the lines mdiggory's idea of what metadata schema should be? (enforcing types and dictionaries)
[20:59] <robint> mdiggory: 1234 makes me a bit uneasy too
[20:59] <bollini> I think that move an item "back" in the workflow process is something worst, we need to take caution about introducing strange cycle that could also make more complex use custom workflow
[20:59] <robint> mdiggory: sorry wrong person !
[20:59] <robint> bollini: agreed !
[21:00] <helix84> bollini: this is what I meant: https://github.com/DSpace/DSpace/pull/12#issuecomment-7592923
[21:00] * sands notes that we're up against the end of the hour, but is willing to stay to continue the discussions. We haven't even gotten to EKT's many contributions that hard work has been put into in the last week.
[21:00] <kompewter> [ Pull Request #12: Support Metadata On All DSpaceObjects by mdiggory · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/12#issuecomment-7592923
[21:00] <mdiggory> 1234, we already do something similar to provide Describestep editing in Reviewer Wrokflow, it doesn't involve adding the item back into submission workflow
[21:00] <mdiggory> just reusing the business logic of the submission process.
[21:00] * helix84 would like to congratulate sands for a very efficient meeting format today, we covered much more ground than usual
[21:01] <KevinVdV> Needs to run until next week !
[21:01] <robint> +1 (round of applause)
[21:01] <sands> helix84: thanks, though taking a shotgun to the JIRA review probably deserves most of the credit. :)
[21:01] <mdiggory> +1
[21:01] <bollini> mdiggory: if it reuse only the code it could be fine, but if they create a fake workflowitem as it looks from their comments
[21:01] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: Leaving)
[21:01] <robint> Got to run too. Thanks all.
[21:01] <sands> cheers KevinVdV
[21:02] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:02] <sands> for any who can remain on, since there are many EKT contributions, do any stand out as needing to be discussed?
[21:03] <mdiggory> bollini: The Item Level Versioning supports reentry into the Submission Process and Reviewer Workflow, but its for a new version of the Item.
[21:03] <mdiggory> the point is that new versions requested by the original submitter need to be reviewed.
[21:03] <bollini> mdiggory: I fine with the item level versioning logic
[21:03] <mdiggory> however, if we ware just talking about the admin or likewise wanting to edit the metadata, it shouldn't need that
[21:04] <mdiggory> sounds like we are in agreement
[21:05] <bollini> mdiggory: at CILEA we have already developed a new edit-item page that show all the metadata in a "long submission style" page
[21:05] <mdiggory> helix84: I think we buried your comment...
[21:06] <helix84> mdiggory: if you mean about schema, it was rather your comment. i just thought it's an alternative to ds-1234
[21:06] <bollini> mdiggory: the problem is that we have done a big refactoring of the describestep class and splitted the jsp in more parts... it needs time to package it for a contribution and now we are not able to accomplish this in time for 3.0
[21:06] <kompewter> [ https://jira.duraspace.org/browse/ds-1234 ] - [#DS-1234] Edit an Item using the workflow process - DuraSpace JIRA
[21:07] <hpottinger> sands: you're right, that's a bunch of pull requests from EKT...
[21:07] <mdiggory> I think what helix84 is referring to is being able to "Type" Items and assign forms and validation according to type rather than "by collection" and "only in submission"...
[21:07] <mdiggory> we also need the requirement to show some fields in admin editing and some fields only in submission and some fields only in review
[21:08] <kstamatis> Hi everyone, I'm watching the conversation from the beginning. Just to inform you that should you have any question about EKT's contributions I would be glad to answer them
[21:08] <helix84> kstamatis: i recommend you take this oportunity to find potential reviewers, they're hard to come by ;)
[21:09] <sands> kstamatis: thanks for raising your hand. sorry that we didn't get all the way through the list! are there any that you would like to be prioritized for review, or are they all equal in your eyes?
[21:09] <mdiggory> kstamatis: I'll be honest, I've not looked closer at the code.
[21:10] <helix84> JSPUI isn't my area of interest/expertise, so I won't be reviewing them
[21:10] <mdiggory> are the patch and modified classes the same?
[21:10] <mdiggory> helix84: this is xmlui...
[21:11] <helix84> mdiggory: i was referring to EKT
[21:11] <mdiggory> 1234?
[21:11] <kstamatis> sands: All seems equal to us but if I should give an order DS-1226 is interesting, DS-1223 is also a nice extension
[21:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1226 ] - [#DS-1226] Batch import from basic bibliographic formats (Endnote, BibTex, RIS, TSV, CSV) - DuraSpace JIRA
[21:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1223 ] - [#DS-1223] Display frequencies of items in single browsing for selected indices - DuraSpace JIRA
[21:11] <helix84> i won't be reviewing EKT contrinutions for JSPUI
[21:12] <kstamatis> DS-1236, DS-1237 and DS-1238 are light-weighted
[21:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1236 ] - [#DS-1236] Auto update advance search drop down lists from configuration file - DuraSpace JIRA
[21:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1237 ] - [#DS-1237] Support date ranges in advance search - DuraSpace JIRA
[21:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1238 ] - [#DS-1238] Display advance search form after an advance search - DuraSpace JIRA
[21:13] <mdiggory> Per 1223... tbh this is why we developed discovery, to not have to create something that a popular third party open source technology already did well.
[21:14] <bollini> mdiggory: it looks as 1223 refers to the browse not to the search system
[21:15] <helix84> mdiggory: see 1223 comments, i already raised that point and Christina responded
[21:16] <hpottinger> I think I can drum up some interest in testing 1224 and 1226 (pull 53 and pull 46)
[21:17] <bollini> mdiggory: I haven't see the code but it could also make more easy to include frequencies in browse with the SOLR DAO (CILEA 1218 contibution)
[21:18] <helix84> As they describe it, this solution is an alternative way to achieve the fucntionality for those who don't want to use Solr. We're still not forcing Discovery on everyone, it's not even the default. So I think Christina has a point.
[21:19] <sands> kstamatis: I unfortunately don't have any JSPUI instances, or much experience with it, but hopefully we can get those in the community that do to have a look at your contributions. Another possibility would be for you to light up a demo for people to try the changes without having to build it themselves. I don't know if that's something you are able to do or not though.
[21:20] <helix84> mdiggory: quick question about metadata for all status - will it be in 3.0 in any form? (current pull request? modified to use a single table? more advanced?)
[21:20] <kstamatis> sands: I think all of the contributions include example repositories of EKT that show the changes
[21:21] <bollini> helix84: I have reviewed the code just now and I don't think that it could work in this way (it calculates the frequencies for any term as a separated query).
[21:22] <helix84> bollini: great, could you please comment in Jira so that it doesn't get lost?
[21:22] <bollini> helix84: I'm going to do ;-)
[21:22] <sands> kstamatis: great!
[21:23] <helix84> EKT did a very good job documenting their contributions. They just need to find someone interested in JSPUI to look at them.
[21:25] <helix84> mdiggory: ping?
[21:25] <hpottinger> bibblio-transformation-engine is on my list of toys to play with, so I definitely want to give 124 and 1226 a spin, have metadata people here excited about playing, too
[21:26] <hpottinger> s/124/1224/g
[21:26] <kompewter> hpottinger meant to say: bibblio-transformation-engine is on my list of toys to play with, so I definitely want to give 1224 and 1226 a spin, have metadata people here excited about playing, too
[21:27] <kstamatis> hpottinger: that's nice
[21:27] <sands> kstamatis: if the release team can help you with these contributions, finding reviewers, etc. please let me know.
[21:28] <mdiggory> helix84: I think we are not focused on adding it at this time.
[21:28] <helix84> i am disappont :(
[21:28] <sands> great meeting all. thanks for all the discussion! i've got to bow out now, but i'm *hoping* to sit down with the transcript and make sure all these threads spin out onto devel for anyone who wasn't here. cheers!
[21:28] <mdiggory> well, what I mean is that we have 5 big contributions with higher priority
[21:29] <kstamatis> sands: being new in here, help is needed!
[21:29] <sands> kstamatis: ok, then you will receive it! :) i will make sure the review continues on the release list and we will make sure it gets the attention needed. cheers!
[21:30] <mhwood> Tail-end Charlie here would like to invite more eyes to DS-861, added to the list after the start of this meeting.
[21:30] <kompewter> [ https://jira.duraspace.org/browse/DS-861 ] - [#DS-861] Salt PasswordAuthentication - DuraSpace JIRA
[21:30] <helix84> mdiggory: i understand. i just thought we'd get the framework in in it's current form, even if there's no UI. For me it's important to have a place to store metadata for epersons. I'll probably have to abuse items for that.
[21:30] <kstamatis> sands: thank you very much
[21:30] <sands> you're very welcome
[21:31] <helix84> bollini: one question about your Researcher pages: where do you store Eperson metadata?
[21:32] <bollini> helix84: the short answer is. we have new objects in the data model
[21:32] <mdiggory> helix84: I"m thinking a lighter approach would be to make a "service" that manages the metadata independent of the data model
[21:32] <hpottinger> mhwood, there was a pretty funny thread about salted password hashes in Code4Lib IRC a couple of hours ago
[21:33] <mdiggory> new DSpace().getSingletonService(ExtraMetadataService.class).getMetadata(DSpaceObject object)
[21:33] <helix84> mdiggory: don't go all Java on me, you know I don't speak the language of your tribe :) I'd be accessing the DB tables directly.
[21:33] <helix84> bollini: but what's the underlying storage? DB tables?
[21:33] * mhwood still wondering why it's *Extra*Metadata
[21:34] <mdiggory> because its shorter than IWantToStoreAddtionalMetadataForMyDSpaceObjectService?
[21:34] <bollini> helix84: the long answer is that we have developed our "framework" to manage additional properties, something like the dspace metadata but much complex (they are typed: string, data, number, etc.) and they can also manage nesting (similar to table)
[21:34] <helix84> mhwood: @mire added a second table so they could make it an addon for older versions of DSpace
[21:34] * hpottinger chuckles, remembering an OR11 slide by kshepherd, recommending that we treat people as objects
[21:34] <mhwood> Ah
[21:35] <bollini> helix84: we use heavy DAO with Hibernate so data are in the DBMS
[21:35] <mdiggory> haha
[21:35] * mdiggory not sure why we need more DSpaceObjects
[21:36] <helix84> bollini: i think this storage is something we all would like to know more about. the need to store structured metadata has been discussed as part of metadata for all and related discussions
[21:36] * mdiggory we do need more Data Model Object though....
[21:36] <helix84> hpottinger: i remember that slide :D
[21:38] <hpottinger> PeterDie_: send a flag up the pole if you want help with review of your Elastic Search Statistics work
[21:38] <mdiggory> bollini: your planning on contributing researcher pages? is that going to introduce JPA/Hibernate dependencies?
[21:39] <bollini> helix84: yes I know, I'm sorry but it is a very big contribution and we need time to dedicate to this activity. I happy to say that HKU has funded this initiative so we can find the time in the next months
[21:39] <mhwood> Sorry, I have to leave. 'bye all!
[21:40] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:41] <helix84> bollini: no problem, i'm looking forward to it
[21:41] <bollini> mdiggory: I think that all the community need to think about this. The ResearcherPage (dspace-cris will be the contribution name) will be a separate module that will use a separate datasource no need to share the same solution with the dspace core. Obviously it could be a first tentative to introduce jpa
[21:41] * barmintor (~ba2213@franklin.cul.columbia.edu) Quit (Quit: barmintor)
[21:42] <mdiggory> bollini: helix84: this is why I'm hesitant to push up the priority of the pull request for the extra metadata table as well, there are other possibilities and I'm concerned about us making the DSO model changes without a good discussion on a DSO Design roadmap.
[21:42] <kstamatis> Goodnight everyone (12:40 am in Athens/Greece)
[21:43] * kstamatis (25067746@gateway/web/freenode/ip.37.6.119.70) Quit (Quit: Page closed)
[21:44] * sands (~sandsfish@18.189.31.239) Quit (Quit: sands)
[21:44] <helix84> mdiggory: maybe we need to put all the options on the table before we start choosing one
[21:45] <helix84> mdiggory: but in principle, i like the idea of any dspace object having the same metadata possibilities. orthogonal design.
[21:45] <helix84> dspace object suffrage movement!
[21:47] <helix84> i'll better head out now before a horse runs over me
[21:47] <helix84> good night!
[21:47] <mdiggory> I still think we don't know what we want, the dialog upto this point was to attempt small changes to the DSO model to expose actual MetadataValue objects. But, TBH, I'm concern that this sounds simpler than it actually is... the fkey relationships force us to need to change the persistence model if we really want to make metadatavalue table DSO centric
[21:48] <mdiggory> thats why theres a separate table and methods in the pull request/
[21:48] <mdiggory> gnite
[21:48] <bollini> mdiggory: at CILEA we are working on our framework since four/five years (not all time ;-) ) so I'm enough confident that our solution is a good DBMS solution to store metadata of any complexity, using different technologies (JCR, XML, NOSQL)
[21:49] <bollini> could provide better ?! solution
[21:50] <bollini> mdiggory: sorry, phrase splitted on two lines
[21:50] <mdiggory> I would be happy to see the design... I have a strong sense that JPA is probably going to be the best path forward
[21:50] <hpottinger> would love to hang around more, but our library is closing for the evening and they're kicking me out, see you all later
[21:51] <mdiggory> your still at work?
[21:51] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:51] <bollini> time to go also for me... bye!
[21:51] <mdiggory> have a good eveing... send me something
[21:51] <mdiggory> design doc or link or whatever....
[21:53] <bollini> ok, I will send something as soon as possible
[21:53] <bollini> bye
[21:53] <kompewter> bye!
[21:53] * bollini (~chatzilla@host9-29-dynamic.51-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
[23:49] * helix84 (a@195.113.97.174) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.