Timestamps are in GMT/BST.
[0:05] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[0:07] * eddies (~eddies@cm175.eta98.maxonline.com.sg) has joined #duraspace
[0:07] * eddies (~eddies@cm175.eta98.maxonline.com.sg) Quit (Changing host)
[0:07] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[0:20] * helix84 (~a@195.113.97.174) Quit (Quit: helix84)
[6:46] -sendak.freenode.net- *** Looking up your hostname...
[6:46] -sendak.freenode.net- *** Checking Ident
[6:46] -sendak.freenode.net- *** Found your hostname
[6:46] -sendak.freenode.net- *** No Ident response
[6:46] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:46] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:46] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:46] -sendak.freenode.net- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[11:01] * bigbrovar (~quassel@83.229.6.19) has joined #duraspace
[11:09] * bigbrovar_ (~quassel@41.206.12.3.vgccl.net) has joined #duraspace
[11:09] * bigbrovar (~quassel@83.229.6.19) Quit (Ping timeout: 256 seconds)
[11:14] * bigbrovar_ (~quassel@41.206.12.3.vgccl.net) Quit (Ping timeout: 272 seconds)
[13:21] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:58] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:27] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Quit: Leaving)
[14:28] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[15:23] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[16:27] * tdonohue1 (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[16:27] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Disconnected by services)
[16:27] * tdonohue1 is now known as tdonohue
[17:16] * helix84 (~a@195.113.97.174) has joined #duraspace
[18:31] * helix84 (~a@195.113.97.174) Quit (Quit: helix84)
[18:35] * helix84 (~a@195.113.97.174) has joined #duraspace
[18:50] * PeterDietz (~peterdiet@128.146.173.112) Quit (Remote host closed the connection)
[18:52] * PeterDietz (~peterdiet@128.146.173.112) has joined #duraspace
[19:25] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[19:27] <linux4u> hi guys. I am getting this on my oaiprovider. any ideas? "java.lang.NoClassDefFoundError: proai/driver/OAIDriver"
[19:31] <helix84> dspace version?
[19:42] <linux4u> fedora 3.4
[19:43] <helix84> oh, ok :)
[19:43] <helix84> that clears it up for me :)
[19:43] <helix84> but the message generally means that the required JAR is not in your classpath
[19:44] <helix84> so if OAI is distributed separately from fedora (I have no idea), double-check the instructions that say where to put the JAR or how to enable dependencies
[19:45] <linux4u> the ins I have seen dont mention anything about that.
[19:45] <linux4u> but I maybe looking at the wrong ones.
[19:46] <helix84> sorry, I have no practical experience with fedora. that is just the general answer for this java error.
[19:46] <linux4u> thanks. the fcrepo channel is kinda dead.
[19:52] <tdonohue> linux4u -- maybe try the Fedora mailing list?
[19:56] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:58] <tdonohue> Hi all, reminder we have our DSpace Developer Mtg starting here in a few minutes: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-30
[19:58] <kompewter> [ DevMtg 2013-01-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-30
[19:59] <hpottinger> linux4u, I've dabbled with Fedora a bit, there's a fair amount of "just put that jar file in a lib folder somewhere" the Fedora mail list is a good tip, they should be able to help
[20:00] <tdonohue> Hi all...it's officially DSpace Devel Mtg time. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-30
[20:00] <kompewter> [ DevMtg 2013-01-30 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-30
[20:01] <tdonohue> First & foremost...just wanted to say that hpottinger is cutting our DSpace 3.1 release *as we speak* (or type)
[20:01] <hpottinger> {flex}
[20:03] <tdonohue> sorry...two conversations at once...I'm talking to hpottinger in #dspace too (as he gives status of the 3.1 release)
[20:03] <tdonohue> the announcements for 3.1 won't go out till everything has propagated though...so, likely sometime tomorrow
[20:03] <mhwood> I guess item 1 (topics before 3.1 release) is taken care of.
[20:03] <helix84> tdonohue: after which email should I send the announcements?
[20:04] <tdonohue> helix84 -- announcements need to wait on two things. 1) Everything needs to appear in Maven Central -- sometimes takes 2-4hours, and 2) I need to get dspace.org updated (which I can do after this mtg)
[20:05] <helix84> tdonohue: ok
[20:05] <tdonohue> By "appearing in maven central", I mean we have to wait until we see a "3.1" here: http://repo2.maven.org/maven2/org/dspace/dspace/
[20:05] <kompewter> [ Index of /maven2/org/dspace/dspace/ ] - http://repo2.maven.org/maven2/org/dspace/dspace/
[20:05] <tdonohue> (and as I said, that can take hours after hpottinger presses the final button...it becomes a waiting game)
[20:06] <tdonohue> But, the other option is just to announce tomorrow morning, at which point everything should be in Maven central
[20:06] <helix84> no problem, i'll check & send
[20:07] <tdonohue> I believe that's all that's left on our 3.1 to-do list.
[20:08] <tdonohue> (other than some minor wiki cleanup...like cleaning up the DSpace Wiki homepage to list 3.1 as latest version, etc.)
[20:09] <helix84> for anyone who hasn't heard yet, I wrote two new chapters on Git (you asked how to do backports, the other one is a pre-requisite explaining the setup): https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-Recommendedsetupofrepositoriesforcommiters
[20:09] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-Recommendedsetupofrepositoriesforcommiters
[20:09] <mhwood> Thank you!
[20:09] <tdonohue> excellent, helix84. yea, thanks. I hadn't seen it yet
[20:11] <helix84> i guess that concludes the agenda, now the drinking part?
[20:11] <tdonohue> The other set of hints we could use is the "how do I update my outdated pull request" (i.e. the "rebase" hints).
[20:11] <tdonohue> but, that looks like a great start, helix84
[20:11] <tdonohue> yea..the agenda is rather light today. So, the floor is open.. anyone have any topics they'd like to discuss?
[20:12] <helix84> I'll think about it. It's just that so many things can go south when rebasing - it's mostly about learning by doing.
[20:12] <hpottinger> we were chatting about REST-API earlier...
[20:12] <helix84> hpottinger: good topic, but I don't think there are any news since last time
[20:12] <tdonohue> yea, my favorite topic...REST API :)
[20:12] <mhwood> Time to pick a REST implementation and groom it for release.
[20:13] <tdonohue> mhwood ++
[20:13] <helix84> on one hand, we have REST which others should work to prepare for inclusion,
[20:14] <helix84> on the other hand we have DAO which we can look at right now
[20:14] <hpottinger> both! :-) I'm multitasking right now...
[20:15] <tdonohue> One thing to note RE: REST-API stuff.... Remember all those "DSpace Futures" discussions we had in late 2012? We will be having a few followup meetings in late Feb on specific "hot topics" to try and drum up some volunteers & someone to bring it forward. REST API is one of those "hot topics" up for further discussion and needing some support behind
[20:15] <mhwood> We have multiple REST candidates, and I worry that nothing much will happen until one is selected.
[20:15] <hpottinger> working group?
[20:15] <tdonohue> The followup meetings in late Feb will be announced soon...I think the one on getting a DSpace REST API will be on Weds, Feb 27 @ 19:00UTC
[20:15] <helix84> tdonohue: will someone from both wijiti and jorum attend?
[20:16] <tdonohue> hpottinger -- yea, essentially that's the goal of these followup meetings...to establish a "working group" (if we can) around specific projects
[20:16] <tdonohue> helix84 -- anyone from the community will be invited.
[20:17] <tdonohue> So, as of now, there will be 3 of these "topic meetings" coming out of "DSpace Futures" discussions. There's no guarantee any of these topics will result in a 'working group' or an actual project.
[20:17] <tdonohue> 1. REST API (this has the most support these days, it seems)
[20:17] <helix84> OK, I'll write them both and also invite them to the call
[20:18] <tdonohue> 2. DSpace + Hydra ( not sure yet if this means DSpace on Hydra or Hydra on Dspace, but it seemed a hot topic)
[20:18] <tdonohue> 3. "Enhancing Metadata" in DSpace (which is a very broad topic, I know)
[20:19] <tdonohue> So, you all are the "first to know". Questions are welcome...just thought I'd mention this in light of the REST API discussions
[20:19] <helix84> good news, thanks, tim
[20:20] <tdonohue> yep. That's the basics...you all will get more specific emails in the near future once we have dates/times finalized in late Feb. (likely emails will go out late this week or early next)
[20:21] <tdonohue> in any case, we can move on to other topics / question now
[20:21] <helix84> is anyone interested in discussing metadata for all?
[20:22] <mhwood> Sure.
[20:22] <tdonohue> sure, we can talk about it
[20:22] <tdonohue> (though I admittedly have grown to dislike the name "metadata for all"...as it seems to be used to mean different things)
[20:22] <helix84> so basically, we had this pull request open before 3.0 freeze, but it got no attention: https://github.com/DSpace/DSpace/pull/12
[20:22] <kompewter> [ Support Metadata On All DSpaceObjects by mdiggory · Pull Request #12 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/12
[20:23] <helix84> I reviewed it and love it (save minor details)
[20:23] <helix84> I think it would solve many, even if not all, problems we currently have regarding metadata
[20:24] <helix84> can we work from there? what do you think about the approach taken?
[20:25] <tdonohue> So, if I recall correctly (quickly browsing code again), this is where all the metadata storage/maintenance gets moved up to DSpaceObject...and then anything which extends it (Collection, Community, Item, EPerson) then has the options to store metadata
[20:25] <KevinVdV> tdonohue: that is correct
[20:26] <helix84> and the storage mechanism is the same
[20:26] <helix84> as for current item metadata
[20:26] <tdonohue> Yea, I recall liking the idea at the time... I just got held up cause is seemed to come in a little "late" for 3.0...it was a massive change that affected everything.
[20:26] <helix84> the only thing I didn't like about it is that the pull requests makes a separate table for metadata of all but items
[20:26] <KevinVdV> A bit different there are no "schemas" although the element/qualifier bit does remain
[20:27] <helix84> it could all be in metadatavalue, distinguished by a resourcetype column
[20:27] <tdonohue> but, I'd be interested in re-investigating it for 4.0 and trying to get it in *EARLY*, so that we can ensure everything else being developed for 4.0 uses it
[20:28] <mhwood> So is it close enough that we can work with it, even if there are some differences over internals?
[20:28] <hpottinger> tdonohue: +1
[20:28] <helix84> +1
[20:28] <mhwood> +1
[20:29] <tdonohue> So, sounds like we have a consensus that it needs re-investigation. How do we want to go about this? Do we need to try and rope in mdiggory one of these weeks for discussion?
[20:29] <helix84> KevinVdV: can you tell us more about "there are no schemas"?
[20:30] <helix84> KevinVdV: if that removes schemas (I don't remember) that might conflict with the parallel DC/QDC/DCMI efforts
[20:31] <tdonohue> helix84 -- I think it's a semantics thing. mdiggory doesn't like the name "schema"....but, I think it was initially chosen to parallel the naming of the dublin core schema.
[20:31] <KevinVdV> It doesn't "remove" anything since it is stored in separate tables. The data is stored in 2 tables.
[20:31] <KevinVdV> One is the registry (list of available metadata fields)
[20:31] <mhwood> I read that schemas include *rules* about what you can put into a field and how they relate. A namespace just gives you labels for things.
[20:31] <KevinVdV> The other is the value table
[20:32] <helix84> ok. i know about namespace/schema dilema and about metadatavalue/metadatafieldsregistry
[20:32] <tdonohue> mhwood : yea, that's probably the reasoning behind mdiggory's suggestion to rename "schema" to "namespace"
[20:32] <helix84> i'd support that
[20:34] <mhwood> The ability to consistently label all of our types could be seen as laying the groundwork for a schema layer later.
[20:34] <tdonohue> Regarding "schema" vs. "namespace"... even if "namespace" is more correct, I would point out that it's less understandable to a 'layperson' librarian / repo manager. So, no matter what we call it underneath, we may need to think about a better word then "namespace" for the actual UI
[20:35] <tdonohue> (cause no one is gonna understand what a "metadata namespace registry" is...unless they've heard the term namespace from XML)
[20:35] <mhwood> "field labels"
[20:35] <helix84> mhwood: -1
[20:36] <mhwood> Suggestion?
[20:36] <tdonohue> we don't need to come up with a better UI term now...just pointing out that "namespace" is not necessarily a widely understood term
[20:36] <helix84> thinking hard, but getting nothing better than schema or namespace
[20:36] <helix84> thinking in fields + set direction
[20:37] <hpottinger> under certain circumstances it's OK to educate users ;-)
[20:37] <helix84> fieldgroup? :/
[20:37] <tdonohue> hpottinger -- yea, it is.. but, I can just anticipate DCAT folks saying...why are you wanting to call this a "namespace" when it's defining my dublin core schema.
[20:38] <mhwood> Might be good to clear off "schema" now so we can re-use it later. A "schema" as I think it is being spoken of would have wide-ranging consequences. The forms engine could query a schema to find out whether a field is repeatable, for example, and wouldn't have to be configured itself.
[20:38] <hpottinger> these are information professionals we're discussing... they'll zig if we need 'em to zig, I think
[20:39] <tdonohue> Oh wait...disregard my complaints :)
[20:39] <mhwood> "Why namespace, when...." Well, IIRC DC tells you what can go in the field. What we have doesn't, does it?
[20:39] <tdonohue> Looked at the XMLUI.....it uses the word "namespace" all over the place in the Metadata Registry
[20:39] <helix84> from what noticed on the lists in 2 or 3 cases, people frok the difference and even use namespace themselves when they're referring to what we curretly have as schema
[20:39] <tdonohue> we already burned that bridge ;)
[20:40] <tdonohue> err...crossed that bridge
[20:40] <helix84> s/sfrok/grok/
[20:40] <helix84> oh, that might be it, I didn't really notice :)
[20:41] <tdonohue> so, we should just take this the next step. I'm ok with renaming schema to namespace....as it already is mostly called that in XMLUI
[20:41] <helix84> do we need/want to vote on that now?
[20:43] <tdonohue> honestly, it could just be bundled as part of this Pull #12 as mdiggory already has done.
[20:44] <tdonohue> So, the next steps here would be: 1) We need a fresh pull request for 3.0 from someone, 2) We may need a (brief) writeup on the wiki on what is changing, so we don't all need to read the code, 3) Then we review, ask questions & vote
[20:44] <tdonohue> whoops typo... "pull request for 4.0"
[20:44] <KevinVdV> We will also need a UI to edit / create the medata values & fields cause this isn't included in the pull request
[20:45] <tdonohue> KevinVdV : yes, that is also true. Though it could be possible that separate people could work on the UI, assuming we had folks who could put time towards it
[20:45] <helix84> KevinVdV: OTOH, there's not much point working on that if the base is not approved for merging
[20:46] <KevinVdV> Agreed, just making sure everybody realised this ;)
[20:47] <tdonohue> it's a big point though...essentially, if we were to "accept" / vote-in, a change like Pull #12, then we'd need to make sure we have the time/resources to tweak/build the necessary UI changes
[20:47] <helix84> or, we could split up the vote - now for "yes, this is the approach we want to take, the data structures and APIs are approved" and later for "this implementation is approved"
[20:49] <helix84> tdonohue: not necessarily - it could be just changes in the API and UI changes to come at a later date (in the extreme case)
[20:49] * tdonohue wonders out loud if this change could be made "backwards compatible" with regards to the UI...i.e. make Metadata for All available in the APIs, but the UIs (initially) just support metadata on items.
[20:49] <tdonohue> oh, helix84 & I are thinking alike...we just said about the same thing
[20:49] <helix84> tdonohue: I think almost certainly
[20:50] <hpottinger> I like that approach
[20:50] <tdonohue> yea, if we can make this initial API change "backwards compatible" with the UI, then we can do this in stages....1) change API, 2) change UIs one by one
[20:50] <KevinVdV> Just to be clear the metadata on all lives ALONGSIDE the metadata for items
[20:51] <mhwood> And this means....
[20:51] <helix84> KevinVdV: I din't quite understand
[20:51] <tdonohue> KevinVdV -- that wasn't clear. This is where I wish there were docs on the wiki
[20:51] <helix84> ah, right
[20:52] <KevinVdV> So ok. The metadata for all getters & setters are calls to something that is called EXTRAMETADATA. This extratametadata lives in separate database tables
[20:52] <helix84> just in the original proposal they were in a completely new table (duplicating metadatavalue so that it could be implemented as an addon) duplicating metadatavalue
[20:53] <helix84> the new metadata could live along item metadata just fine as new rows, distinguished by a new metadatavalue.resourcetype column
[20:54] <helix84> did that make sense to you?
[20:54] <KevinVdV> So helix, you propose to alter the existing metadata tables & merge those changes with the current pull request ?
[20:55] <helix84> yes
[20:55] <helix84> it's simply adding a column
[20:56] <KevinVdV> Ok you got me now
[20:56] <mhwood> Does it need a "type", or isn't namespace the type?
[20:56] <KevinVdV> type would be 0 for bitstream, 2 for item, 3 for collection, ....
[20:56] <tdonohue> yea, I'd rather have all objects handle their metadata in a similar way...rather than have two separate places that metadata gets stored (based on the type of object)
[20:57] <helix84> no, namespace is something different. this is resourcetype (item, bitstream, collection, ...)
[20:57] <mhwood> Ah
[20:57] <tdonohue> So, I like the concept that helix84 is proposing...if it's possible.
[20:58] <tdonohue> but, beyond that, I still like this proposal overall.
[20:58] <KevinVdV> It should be possible mhwood
[20:58] <mhwood> Hrm, yes, we need to add a resource type column to give space for unique IDs, now that we have different types of objects represented and their ID numbers might collide.
[20:58] <helix84> I'd just like to note that the metadatavalue is already our largest table and this will make it grow. but not grow O(n), only O(1). speaking of number of rows.
[21:01] <tdonohue> So, it sounds like we have the following decided: (1) we like the concept of Pull #12, but we'd like to see it just use metadatavalue if possible & be "backwards compatible" for existing UIs if possible, (2) we need an updated pull, (3) we need some docs on wiki, (4) then we need to review & vote on it.
[21:01] <helix84> mhwood: it's not really for making unique ids - metadata_value_id already are our unique ids
[21:02] <helix84> tdonohue: sounds good, but mdiggory could comment on API backward compatibility
[21:02] <mhwood> Not IDs for the values; the unique IDs of the objects carrying these values. You can have an Item, Collection, Community all with ID 1.
[21:02] <mhwood> tdonohue: yes.
[21:02] <helix84> mhwood: gotcha
[21:03] <tdonohue> yea, I agree...mdiggory could comment. But, as mdiggory is hard to get time from these days (he seems really busy), hopefully KevinVdV can get word from him or pass things along :)
[21:03] <mhwood> This will affect indexing too. If we index on resource_id now, we'd need to change that to (resource_type, resource_id).
[21:04] <helix84> yes, that would be our new "composite primary key", outside the database
[21:04] <tdonohue> mhwood -- yea, definitely will affect indexing. But, it's easy enough to reindex stuff.
[21:04] <mhwood> Just wanted to capture the thought.
[21:04] <helix84> but regarding that - it might be beneficial to adopt a single, unique ID across all DSOs
[21:04] <tdonohue> in general, this will be a major change, and will require some "migration" of data....it won't be simple, but it seems necessary
[21:04] <mhwood> helix84: interesting point.
[21:04] <helix84> this would be a disruptive change, but might be well worth the added complexity in the future
[21:05] <helix84> look at this
[21:05] * helix84 looking for wiki page
[21:06] <helix84> https://wiki.duraspace.org/display/DSPACE/Proposal+For+Metadata+Enhancement
[21:06] <kompewter> [ Proposal For Metadata Enhancement - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Proposal+For+Metadata+Enhancement
[21:06] <helix84> the comments
[21:07] <tdonohue> helix84 -- huh...you're suggesting "Unique ID for All" :) Seriously though, might be worth considering...moving "id" up to DSO, and making it globally unique.
[21:08] * tdonohue notes we're over time here...but, this is a very interesting topic today.
[21:09] <mhwood> I need to ponder that a bit. The comments appear at first glance to be in violent agreement. :-)
[21:09] <helix84> code-wise, this would be much more disrupting than metadata for all, also requiring migration efforts on upgrade
[21:10] <tdonohue> yea, it would be very disruptive. but it is interesting to think about.
[21:10] <helix84> since we're going wild here today, should I turn it one more notch?
[21:11] <helix84> *up
[21:11] <hpottinger> by all means, yes
[21:11] <mhwood> I wonder where the handles would come from if you're a site that doesn't use Handles? Needs more discussion.
[21:12] <tdonohue> sure, helix84..but, I do want to make a sidenote that obviously our official meeting time is "passed". So, if folks have to leave, they are obviously welcome to.
[21:12] <helix84> ok, apart from our nice hierarchical DSOs, we could also have DSOs that cannot be "boxed" his way, they would be related to our DSOs (attributes in OOP-speak)
[21:12] <helix84> in particular - author and journal
[21:12] <helix84> currently there's no way to store their metadata without duplicating it in item metadata
[21:13] <mhwood> Replacing hierarchy with a more general notion of containment is also a perennial topic.
[21:13] <helix84> so, there are two possible approches here as I see it
[21:13] <tdonohue> mhwood -- probably best to ignore the idea of handles..and think more about "a globally unique ID per object, which may or may not be 'mapped' to a handle". So, the internal ID is globally unique, but it need not be the same as the external ID (handle).
[21:13] <helix84> tdonohue: +1000
[21:13] <mhwood> Sounds right.
[21:14] <mhwood> But then, it can be an integer, as now.
[21:14] <tdonohue> mhwood..right, internal id could still be an integer...but it needs to be *globally unique*, which it currently is not
[21:15] <mhwood> Got it.
[21:16] <helix84> 1) [an indirect approach, but should be easy to implement] authorities. the same concept could be applied to journals or whatever. there has even an implementation around for some time: http://www.askosi.org/dspaceSKOS/DestinSKOS.pdf
[21:16] <helix84> 2) [a direct approach, might require even larger changes] implement triplets, like in RDF, of DSO-relation-DSO
[21:16] <mhwood> Yeah. Instead of a string, "author" is a reference to an Author, etc.
[21:17] <helix84> (another example of such DSO is grants)
[21:18] <helix84> too wild from where we stand? :)
[21:18] <mhwood> I recall that things somewhat like this have been discussed before. I think you will find advocates.
[21:19] <helix84> this can be gradual in the order as I mentioned it - metadata4all, ID4all, authorities4all/triplets4all
[21:19] <mhwood> I think it may have to be phased. That's a lot of changes.
[21:20] <helix84> mhwood: I'm sure it must have been even before I knew DSpace existed :) It's nothing new, just applying general concepts to DSpace
[21:20] <mhwood> So assuming for the moment that metadata4all is slotted for 4.0, where do the rest go?
[21:20] <tdonohue> yea...i think it's an interesting concept as well. But, we cannot do everything at once. We'd have to stage it across several versions of DSpace, likely.
[21:21] <helix84> ID4all might make sense to go right after metadata4all, still in time for 4.0
[21:21] <helix84> the rest is too far for now, IMHO
[21:21] <mhwood> If there is agreement that this is where DSpace should be going, we should assign them to releases now (not today, but RSN). Things can be adjusted later.
[21:22] <mhwood> Something that happens to DSpace a lot is that wishes never become goals.
[21:22] <helix84> also not that I waasn't even talking about larger changes, such as structured (not flat) schema, enforcing field types (schema)
[21:22] <helix84> s/not/note/
[21:22] <kompewter> helix84 meant to say: also note that I waasn't even talking about larger changes, such as structured (not flat) schema, enforcing field types (schema)
[21:23] <mhwood> Yes.
[21:24] <tdonohue> yea, mhwood. we do tend to have a large "wish list". The problem always tends to be a lack of resources to tackle large projects...but, as suggested, we could try and at least get metadata4all proposal/pull request updated & try to get it into 4.0 as soon as possible
[21:24] <helix84> mhwood: I know, I should have started with "I have a dream". But I think I've already heard it somewhere :)
[21:24] <mhwood> :-)
[21:25] <mhwood> My concern is that big things need to be scheduled or they languish. They need to move from "I'd sure like to have this, but it's BIG" to "we intend to do this, how do we get it done?"
[21:25] <KevinVdV> Needs to run until next week guys !
[21:26] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Now with extra fish!)
[21:26] <helix84> I think metadata4all is definitely doable for 4.0
[21:26] <tdonohue> agreed mhwood.
[21:26] <helix84> I could even attempt to port the pull request, but not in the coming week or two
[21:27] <helix84> I guess we don't have a roadmap document, do we?
[21:28] <tdonohue> helix84: if you are willing that'd be great. Even if it's a few weeks / month from now. The key is just to try and get this work started/voted in by March or April, preferably (i.e. sometime early in the release cycle)
[21:28] <mhwood> Notice the pronoun shift. Putting a big goal on the schedule might be one way to gather collaborations.
[21:28] <helix84> it wouldn't align with the way DSpace is developed (organically)
[21:29] <tdonohue> So, what are we suggesting to do different this time around? Just throw this up on a "4.0 Release Notes" page and keep picking at it?
[21:29] <mhwood> Depends on whether the roadmap is inclusive or exclusive. If things not on the map are Not Allowed, that would be a big change.
[21:30] <helix84> mhwood: i think a "not allowed" list is also contrary to how DSpace is developed
[21:30] <mhwood> I think we just agreed.
[21:31] <helix84> right :)
[21:31] <tdonohue> I like the idea of "we intend to do this, how do we get it done"...but, we just need to hold ourselves to it. It's obviously a group thing, as no one has full control of everyone else's time.
[21:32] <helix84> tdonohue: release notes are fine for metadata4all, but do we have a larger "vision" document?
[21:33] <mhwood> The idea is that we commit to a scheduled goal *as a body*, after enough discussion that a working group seems to be coming together.
[21:33] <tdonohue> helix84 : we do not have an overarching "vision" document, as it seems to change with every release :) We have tons of overarching "proposals" for things we really need to do (which is our large "wish list")
[21:35] <tdonohue> mhwood : yea, I agree with the idea. Just curious if you had thoughts on how to get the "buy in". In the past, we've scheduled things via JIRA or stuck them on a "release notes" page. Sometimes that gets them done, sometimes they just get rescheduled again later
[21:35] <mhwood> "No plan ever survives contact with the enemy." Planning is something you do over and over as the situation develops.
[21:36] <tdonohue> helix84: Though we do tend to treat the "release notes" as "vision documents" for the next release...at least early on...so, we probably should create a "4.0 Release Notes" with some ideas around what we'd like to see happen for 4.0 soon
[21:36] <helix84> definitely
[21:37] <hpottinger> it certainly makes for awesome release notes pages... and a nice high pagerank for them
[21:37] <helix84> also, the "we'll cross that bridge when we come to it" approach agrees with setting only goals that are in sight and therefore reachable
[21:37] <mhwood> I think we start with people generally agreed that goal X is large enough to need a team, and some discussion of how to parcel it out and who might want to be on the team.
[21:38] <helix84> once we are "there" (4.0 or metadat4all), it will make more sense to ponder where to go next
[21:39] <helix84> which brings me into agreement with mark again :)
[21:39] <tdonohue> helix84 -- yea, that's essentially how we tend to work. One release at a time. (As mentioned, we do have some "pie in the sky" proposals / wish lists out there too..but they don't tend to happen until the time is ripe)
[21:42] <mhwood> Should we try to e.g. go ahead and schedule authorities4all for DSpace 5, with the understanding that it's not a promise until a team forms that is willing to commit to a schedule? "Right now, this is where we think we will be going."
[21:42] <mhwood> Again, not today, but after a reasonable amount of ML discussion.
[21:44] <helix84> we could, but a roadmap would be better than release notes for DSPace 4, 5 and 6 created at this time
[21:44] <tdonohue> we could... the only other alternative I can think of is to actually create a high level "Vision" wiki page, and map out possible features for possible future releases. It's no "promise"..but it could give us something to glance at once we are done with 4.0, to remind us where we might want to go next
[21:44] * tdonohue said the same thing as helix84
[21:44] <mhwood> Whatever document works. I'm trying to figure some way to get from "we should do that someday" to "what would it take to deliver that, and when?"
[21:45] * helix84 detaches from the mind-meld
[21:47] <mhwood> Thinking about it, these goals individually are details of a vision of how the use of DSpace could evolve.
[21:48] <tdonohue> mhwood...yea, I agree. Some of this is also stuff we're trying to "rethink" with the "DSpace Futures" discussions.... so, for example, I mentioned those "topic specific" followup meetings. Part of that is to also try and feel out whether there are ways to get others involved (or get others to promise additional resources) to help us "deliver features" sooner.
[21:51] <helix84> mhwood: could you please look at #dspace?
[21:51] <mhwood> Reading....
[22:17] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:52] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:54] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:08] * linux4u (~james@employed.library.emory.edu) Quit (Ping timeout: 245 seconds)
[23:47] * helix84 (~a@195.113.97.174) Quit (Quit: helix84)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.