Timestamps are in GMT/BST.
[3:55] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (Read error: 110 (Connection timed out))
[4:08] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:08] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:08] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:48] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (leguin.freenode.net irc.freenode.net)
[5:00] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[5:03] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (leguin.freenode.net irc.freenode.net)
[5:04] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[7:37] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[7:51] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[8:28] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:48] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:54] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[9:54] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[9:54] * bradmc_ is now known as bradmc
[10:02] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Read error: 104 (Connection reset by peer))
[10:04] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[11:11] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (leguin.freenode.net irc.freenode.net)
[11:11] * barmintor (i=barminto@specdl11.cul.columbia.edu) Quit (leguin.freenode.net irc.freenode.net)
[11:11] * greg-g (i=greg@ubuntu/member/greg-g) Quit (leguin.freenode.net irc.freenode.net)
[11:11] * ChanServ (ChanServ@services.) Quit (leguin.freenode.net irc.freenode.net)
[11:11] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (leguin.freenode.net irc.freenode.net)
[11:11] * cwilper (n=cwilper@74-44-155-90.dsl1-erie.roch.ny.frontiernet.net) Quit (leguin.freenode.net irc.freenode.net)
[11:11] * mhwood (i=mwood@mhw.ulib.iupui.edu) Quit (leguin.freenode.net irc.freenode.net)
[11:11] * snail (n=stuart@130.195.178.61) Quit (leguin.freenode.net irc.freenode.net)
[11:16] * ChanServ (ChanServ@services.) has joined #duraspace
[11:16] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[11:16] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[11:16] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[11:16] * barmintor (i=barminto@specdl11.cul.columbia.edu) has joined #duraspace
[11:16] * greg-g (i=greg@ubuntu/member/greg-g) has joined #duraspace
[11:16] * cwilper (n=cwilper@74-44-155-90.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[11:16] * snail (n=stuart@130.195.178.61) has joined #duraspace
[14:29] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[14:30] <kshepherd> hi all, i have a dentists appointment shortly so will be late to the developer meeting today
[14:31] <mhwood> Sounds like a short one -- usually the best kind!
[14:31] <kshepherd> i've attached patches for DS-406, DS-409 and DS-411 and am close to a patch for DS-365 (not a new/testathon issue, just an old issue i'd forgotten!) so please feel free to take a look and vote on committing them
[14:32] <kshepherd> mhwood: yeah just a single filling thankfully
[14:40] * ClaudiaJuergen (n=Miranda@i538778E8.versanet.de) has joined #duraspace
[14:47] * jat_ysu (n=jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[14:54] <tdonohue> all...we'll be having a DSpace developer meeting here in a few minutes. As mentioned (via email), I'd mostly like to do a quick review of some or all of the recent Jira issues in order to stay on top of things. If others have other topics for discussion, feel free to mention them now.
[14:54] <tdonohue> Here's a search of all recent issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-4w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[14:55] <tdonohue> (we last reviewed up to DS-375)...so, we'd be starting with DS-376 and a few other stragglers from just before Testathon
[14:56] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[14:57] * caryn (i=80c8e115@gateway/web/freenode/x-rszdadbwplktdpar) has joined #duraspace
[14:59] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[15:00] <tdonohue> Hi all...according to my clock, it's 20:00UTC now. For those of you who just joined, I'd like to start off with a Jira review. Here's a search for recent issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-4w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[15:01] <tdonohue> We'll be starting at the top with DS-376 (since we haven't reviewed any of these yet). Can I get a volunteer to post each issue, and I'll be the timer -- to try to keep us to about one minute (or so) per issue?
[15:02] <jat_ysu> I'll copy.
[15:02] <jat_ysu> http://jira.dspace.org/jira/browse/DS-376 Pack?Unpack Zip files
[15:03] <tdonohue> +0 - sounds like post-1.6 to me?
[15:04] <ClaudiaJuergen> +0 dito
[15:04] <mhwood> +0
[15:04] <caryn> +0
[15:05] <mdiggory> +0 underdeveloped
[15:05] <tdonohue> DS-376 Summary: +0 mark post-1.6.0 (likely more discussion needed)
[15:06] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[15:06] <tdonohue> (jat_ysu whenever you are ready for next one :)
[15:06] <jat_ysu> http://jira.dspace.org/jira/browse/DS-383 Auto commit functionalty not working courrectly in XMLUI
[15:08] <tdonohue> +0 further testing / verification? (anyone know about this or DS-353 which seems related)
[15:08] <mhwood> 0 important but no patch, needs study
[15:09] <mdiggory> reviewed this before... looking at notes
[15:10] <tdonohue> DS-383 Summary: +0 more testing needed (mdiggory feel free to add thoughts to issue)
[15:10] <jat_ysu> http://jira.dspace.org/jira/browse/DS-387 Add ability for various Packager plugins to report their custom Options via command line
[15:11] <tdonohue> +1 (for those who didn't realize the Packagers all have separate options which aren't really documented)
[15:12] <mhwood> We've gone RC1 -- should this wait? Why or why not?
[15:12] <mdiggory> +0 tim you submitted it, you commit it ;-)
[15:12] <lcs> 0 - it's an API change, ought to go in next release
[15:13] <tdonohue> lcs and mhwood - correct, should go in next release
[15:13] <mdiggory> API changes?... probibly should go in major release
[15:13] <mdiggory> note... because we froze prior to the rc candidate, doesn't mean things should stay froze during preparation for the next rc or release...
[15:13] <lcs> it's (a) minor, (b) a clean addition, but it does affect any packager plugins people have implemented.
[15:14] <ClaudiaJuergen> that's a big but
[15:14] <mdiggory> thus the importance of doing it in a major release
[15:15] <tdonohue> ok, lets summarize to DS-387: Needs more discussion, not for 1.6.0
[15:15] <mhwood> Introspect for the presence of the function? Then it doesn't break with older packagers.
[15:16] <mhwood> Maybe commandline tools need defined a general "I have more help for you" interface.
[15:16] <mdiggory> create a "help interface that can be implemented and use instanceof to test for it
[15:16] <mdiggory> if it doesn't implement it, then don't attempt to cast/call it
[15:16] <lcs> that's the --help option, usually.
[15:17] <tdonohue> mdiggory, so you are saying modify patch to do that?
[15:17] <mdiggory> Then it doesn't need to be a major release
[15:17] <mhwood> Can still be deferred, just not as long.
[15:17] <mdiggory> because you havn't created an incompatability for older packagers
[15:17] <tdonohue> ok...I'll go back and resubmit, and we can re-review later (if that sounds good)
[15:18] <mdiggory> tdonohue: yep, I'm suggesting modifying the patch to do that
[15:19] <tdonohue> sounds good. I'll modify the patch for DS-387, and we can review again later
[15:19] <mhwood> 0 not in 1.6.0, good idea we need when ready
[15:19] <tdonohue> DS-387 Summary: Assign to Tim, modify patch, review again later
[15:19] <jat_ysu> http://jira.dspace.org/jira/browse/DS-390 Worfklow task notification emails not available on deposits via SWORD
[15:20] <mdiggory> note +0/-0 means "indifference" +1/-1 are more appropriate if we are voting to do / not do something
[15:20] <tdonohue> oh, looks like we had reviewed DS-390 last meeting
[15:20] <ClaudiaJuergen> +1 small but convenient and fits the other workflow notification changes
[15:21] <jat_ysu> go on then?
[15:21] <mdiggory> +/-0 means I agree/disagree but am lazy and will not contribute...
[15:21] <tdonohue> Anyone have any further thoughts on DS-390? going once?
[15:22] <tdonohue> let's move on then, for now
[15:22] <jat_ysu> http://jira.dspace.org/jira/browse/DS-391 Add ability to temporarily disable or turn off email notifications
[15:22] <mhwood> Was there an acceptable Quick Fix, to be superseded when we have a Big Fix?
[15:23] <ClaudiaJuergen> thought Stuart had done a notification config option for the item import already
[15:23] <mdiggory> per 390, differ because stuart is not available to comment
[15:24] <tdonohue> mdiggory +1 - stuart needs to comment on his quick fix
[15:24] <caryn> isn't this a line in the new dspace.cfg "#mail.server.disabled = false"?
[15:24] <caryn> +1
[15:24] <mdiggory> per 391, does this relate to Bens patch as well
[15:25] <tdonohue> mdiggory: ben's patch?
[15:25] <mdiggory> http://jira.dspace.org/jira/browse/DS-306
[15:25] <caryn> that's the "quick fix" right - global turn off notifications?
[15:26] <mhwood> 306 is a different (and much simpler) use case, I think.
[15:26] <tdonohue> DS-391 from what I understand is slightly different (and may need more discussion)...it's more asking for the ability to "temporarily" turn off notifications (without a server restart)
[15:26] <mdiggory> That would be a nice feature...
[15:27] <jat_ysu> If you are batch loading your daily subs will flood a user...could we not get a flag to disable from running?
[15:27] <mdiggory> TBH, consider it not only an administrative feature... but maybe also a user / collection admin feature...
[15:27] <jat_ysu> for that particular collection?
[15:27] <caryn> DS-391 was more complex, so we wanted to push it to future releases, but 306 allows an admin to say "we're going to be doing a bunch of uploading, don't send notifications"... if i remember correctly...
[15:28] <caryn> 391 needed more discussion to flush out design specs
[15:28] <mhwood> You *can* do that with 306 but it requires a restart.
[15:28] <mdiggory> ok, why not turn of the crontab then?
[15:28] <mdiggory> of = off
[15:28] <jat_ysu> <==we turn off in crontab on days we batch load
[15:29] <tdonohue> Hmm...good thought, maybe a quick best practice on turning off crontab is a quick fix for DS-391
[15:29] <mdiggory> ok.. I do agree though, would be nice feature...
[15:29] <mdiggory> sounds like a 1.6.1
[15:29] <tdonohue> In the essence of time, let's differ discussion on DS-391 and mark is at post-1.6.0
[15:30] <jat_ysu> http://jira.dspace.org/jira/browse/DS-394 My search resuls differes from version to version
[15:30] <tdonohue> -1 Needs followup / more info (mark won't fix for now)
[15:31] <mhwood> -1 more information needed
[15:31] <caryn> -1 more info needed
[15:31] <ClaudiaJuergen> -1 more info needed, e.g. about filter-media run or not etc. and the versions used
[15:32] <tdonohue> DS-394 Summary: -4. More info needed. Tim will add a comment to issue.
[15:32] <jat_ysu> http://jira.dspace.org/jira/browse/DS-396 Provide metadata tags used by Google Scholar for enhanced indexing
[15:33] <lcs> I believe MIT is still working on a patch for this. If there were a patch I'd vote +1
[15:33] <tdonohue> +1 for post 1.6.0 (I've heard through grapevine MIT is working on this)
[15:34] <mhwood> +1 post 1.6.0
[15:34] <lcs> Last I heard is, they're close but need to get confirmation on Google on the metadata field names.
[15:34] <jat_ysu> +1 post 1.6.0
[15:34] <ClaudiaJuergen> +1 for the futuer, most instances won't have the metadata necessary
[15:34] <lcs> +1 post 1.6.0
[15:34] <tdonohue> DS-396 Summary: +5. Mark post-1.6.0. Follow up with MIT folks
[15:34] <jat_ysu> http://jira.dspace.org/jira/browse/DS-397 Collection template metadata language qualifiers ignored
[15:34] <mdiggory> if theres a crosswalk... this seems somewhat trivial
[15:35] <mdiggory> most of the google stuff looks like BIBO to me
[15:35] <tdonohue> mdiggory: Yea, but since MIT is already working on this, we might as well let them take the lead and submit a patch
[15:35] <mdiggory> I'd also toss in that this stuff would make nice for Zotero
[15:35] <mdiggory> sure... but would like to see confirmation on that
[15:36] <mdiggory> MIt works on "many things"
[15:36] <tdonohue> lcs & I have both heard they are preparing a patch...I think that's some confirmation. I'll check with Richard though
[15:36] <lcs> i have seen code.
[15:36] <tdonohue> Thoughts on DS-397?
[15:37] <mdiggory> no patch
[15:37] <ClaudiaJuergen> it's been around since 1.2 and is a nuisance for instances with non en metadata
[15:37] <mdiggory> but I think we stumbled over this too in the past
[15:38] <tdonohue> volunteer to look into DS-397?
[15:38] <mdiggory> I suspect that there are other things that should be checked in the template code as well
[15:38] <mdiggory> possibly, but post 1.6.0
[15:39] <tdonohue> ok, makes sense, Mark....Can we assign to you for now?
[15:39] <mdiggory> need to talk with team and see if we have something floating around.
[15:39] <mdiggory> sure
[15:39] <tdonohue> DS-397 Summary: post-1.6.0. Assign to MarkD for now
[15:39] * mdiggory ack! what'd I just do
[15:40] * tdonohue we can always reassign :)
[15:40] <mdiggory> ;-)
[15:40] <tdonohue> we're at 20mins left...everyone OK to continue for the full hour?
[15:41] <jat_ysu> <=ok
[15:41] <mhwood> OK
[15:41] <lcs> sure.. i wanted to bring up ds-412
[15:41] <caryn> ok
[15:41] <mdiggory> +1
[15:41] <jat_ysu> go do ds398? or skip?
[15:42] <tdonohue> lcs: do we need to skip to DS-412 temporarily?
[15:42] <lcs> no, i 'm sticking around
[15:42] <jat_ysu> http://jira.dspace.org/jira/browse/DS-398 Collection submission license displayed in collection homepage
[15:42] <mdiggory> ?
[15:42] <mdiggory> it is?
[15:43] <ClaudiaJuergen> yes
[15:43] <lcs> needs patch, given that, I
[15:43] <lcs> .. i'd say +1
[15:43] <ClaudiaJuergen> http://eldorado2.tu-dortmund.de:8080/xmlui/handle/123456789/11
[15:43] <tdonohue> +1 - needs volunteer
[15:43] <mdiggory> where is an example
[15:43] <ClaudiaJuergen> see above
[15:44] <mdiggory> http://testathon.net/xmlui/handle/123456789/2
[15:44] <caryn> this occurs in 1.5 also, right?
[15:45] <mdiggory> I'd have tot translate the page to test
[15:45] <ClaudiaJuergen> it occured once, but I thought it had been resolved
[15:45] <tdonohue> any volunteers to test / try to resolve?
[15:45] <mdiggory> isn't there a query string to change the locale?
[15:46] <tdonohue> Ok, I'll take the lead on this -- seems like it should be a relatively easy fix
[15:47] <tdonohue> Summary DS-398: Assign to Tim
[15:48] <mdiggory> ClaudiaJuergen: I just created an account there... who do I talk to to get admin privs
[15:48] <ClaudiaJuergen> mdiggory: you got admin rights now
[15:49] <jat_ysu> http://jira.dspace.org/jira/browse/DS-399 Special characters in collection license lead to parse error
[15:49] <tdonohue> mdiggory: fyi - i was able to verify DS-398 from the dortmund.de site.
[15:50] <jat_ysu> DS-398 only affected the XMLUI
[15:50] <tdonohue> jat_ysu: correct
[15:50] <jat_ysu> at dortmund.de site. JSPUI was looking fine.
[15:50] <mdiggory> Ok, so you expect that the text you enter into "Lizenz:" shouldn't show up int he page?
[15:51] <ClaudiaJuergen> jat_ysu: the bug is flagged as xmlui
[15:51] <mdiggory> what about provenance?
[15:51] <lcs> mdiggory: the TU site shows up in english for me; firefox 3.0 sends locale
[15:51] <jat_ysu> duh
[15:51] <ClaudiaJuergen> mdiggory: the submission license shouldn't appear in the collection homepage only the copyright notice
[15:51] <tdonohue> mdiggory: I always thought provenance was totally hidden (for admins only), and the license was also hidden (except it is used in the submission process for the collection)
[15:51] <ClaudiaJuergen> whether to make the item license available is up to the instance
[15:52] <mdiggory> the value you'ce inserted int he Collection view editor is
[15:52] <mdiggory> This is a test license.
[15:52] <mdiggory> Some special chars äöüß#<&
[15:53] <tdonohue> not sure I understand your question there mdiggory?
[15:53] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[15:54] <mdiggory> sorry, German is not my strong point... thought I was looking at the Copyright field...
[15:54] <mdiggory> Urheberrechtshinweis
[15:54] <mdiggory> is copyright sorry
[15:54] <tdonohue> hmmm...i'm seeing it in English, not German
[15:54] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:55] <tdonohue> we ready to move on to DS-399 (which seems somewhat related)?
[15:55] <mdiggory> ah better...
[15:55] <tdonohue> http://jira.dspace.org/jira/browse/DS-399
[15:55] <ClaudiaJuergen> interesting thought the i18n troubles were only on jspui
[15:55] <mdiggory> Firefox...
[15:55] <ClaudiaJuergen> tdonohue: only vaguely
[15:55] <mdiggory> and locale switcher cause problems
[15:56] <mdiggory> it tends to run wild
[15:56] <tdonohue> DS-399: Not sure if this is an actual bug or not. I wonder if it's just complaining about the unclosed bracket (<)
[15:56] <mdiggory> ok, I'm convinced... needs fixing +1
[15:57] <mhwood> Those should be character-entity encoded on the way in, so it shouldn't matter what they are -- but apparently it does.
[15:57] <mdiggory> per 399, yes, but XMLUI will catch licensing format issues.
[15:57] <mdiggory> not JSPUI... this a parity difference
[15:58] <mdiggory> XMLUI expects all fields to be wellformed
[15:58] <lcs> the license is stored as a bitstream, probably UTF-8 character stream.
[15:58] <tdonohue> yes. mdiggory is right...XMLUI is seeing the "<" and expecting wellformed XML
[15:58] <tdonohue> (or that's what I think could be happening)
[15:59] <mdiggory> it is the collection editor reflects this problem to the Collection Admin
[15:59] <mdiggory> in the XMLUI
[16:00] <tdonohue> I just removed the "<" from the collection license at http://eldorado2.tu-dortmund.de:8080/xmlui/handle/123456789/11, and the error disappears
[16:01] <tdonohue> It looks like it handles i18n fine...it's just expecting well formed XML when it sees either < or >
[16:02] <ClaudiaJuergen> right, more in the kind of usability might confuse newbie delegated administrators
[16:02] <tdonohue> So, is it more that it text of the warning should change?
[16:03] <mdiggory> XMLUI supports xhtml tags in the content of these feilds and requires it to be xhtml, not html or unclised tags. Its been in XMLUI since the beginning of XMLUI
[16:03] <ClaudiaJuergen> yes
[16:03] <mdiggory> unclised = unclosed
[16:03] <mhwood> Brokets need to be transformed to <, > when entering an XML context.
[16:03] <mdiggory> no, mostly xml content should be well formed
[16:04] <mdiggory> not escaped
[16:04] <lcs> the license is free text, not xml or html. it should be escaped as mhwood says.
[16:04] <tdonohue> mhwood. The problem there is that the XMUI is trying to allow you to enter XHTML into those fields (to provide formatting if you wish). Escaping those characters would remove that capability
[16:04] <caryn> text doesn't indicate anywhere that this can be marked up...
[16:04] <mhwood> Ewww
[16:05] <mdiggory> The UI behavior treats anything edited in a form field on that page the same
[16:05] <ClaudiaJuergen> thought the license could not be marked u
[16:05] <mdiggory> in XMLUI, its a feature
[16:05] <lcs> deposit license is stored as a bitstream of type "License" (ewww) with mimetype text/plain..
[16:05] <ClaudiaJuergen> only the descriptive elements
[16:05] <mdiggory> then put plain text in the form field
[16:06] <caryn> if it's well-formed, can that field display marked up text? or, do you get the <, >
[16:07] <mdiggory> it will display as markup if well formed
[16:07] <mdiggory> but, because he License file itself is text/plain, your browser will not rtreat it as such
[16:07] <lcs> it _should_ display literal <foo> if you enter <foo> in the license field.
[16:07] <mdiggory> as lcs points out
[16:08] <mdiggory> recommend that tdonohue change this when he looks at removing it as well
[16:08] <ClaudiaJuergen> ok, it's late here, bedtime for me
[16:08] <ClaudiaJuergen> bye
[16:08] <caryn> got it - also, the special characters won't parse when the item is downloaded as a bundle...
[16:08] <mdiggory> from the XMLUI presentation
[16:08] <tdonohue> I'll look into DS-399 as well. So we are agreed it should be plain text always
[16:09] <ClaudiaJuergen> +1 for that
[16:09] <caryn> +1 plain text
[16:09] * ClaudiaJuergen (n=Miranda@i538778E8.versanet.de) Quit ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[16:09] <mdiggory> I suppose
[16:09] <mhwood> Problem seems to be that it's undecided whether this hunk of text is XHTML or plain. We can be clever and try to detect what is markup and what is not (ick!) or we can ask the user to specify (and then it's his problem) or we can tell the user what it is, one way or the other.
[16:09] <lcs> +1 text/plain
[16:09] <tdonohue> we're well over time. Call it a day?
[16:09] <mhwood> +1 text/plain, be sure the user knows
[16:10] <mdiggory> mhwood: the UI does detect it, but the expectation is that if your putting in tags, your wanting html/xhtml
[16:10] <caryn> if it's not in plain text, then the downloaded license file should have an extension...
[16:10] <caryn> plain text is a bit more straightforward
[16:10] * mdiggory ponders that license should be an uploaded bitstream in the first place...
[16:10] <mhwood> Probably should close formal meeting, as we are starting to lose participants.
[16:10] * kshepherd returns from the dentist
[16:11] <mdiggory> ouch
[16:11] <kshepherd> wasn't too bad actually!
[16:11] <kshepherd> and i'm not slobbering all over my desk
[16:11] <mhwood> Good point about how the license is provided. They tend to be long, yes?
[16:11] <jat_ysu> I've got to run. Tight schedule today. (Birthday too). T
[16:12] <tdonohue> consider the meeting closed. feel free to continue discussion as needed. We can start with DS-400 next week. Though, I encourage you to all review the Testathon issues and try and fix the small ones :)
[16:12] <kshepherd> did we get up to DS-4xx issues?
[16:12] <tdonohue> nope. we ended on DS-399
[16:12] <kshepherd> jat_ysu: happy birthday!
[16:12] <caryn> they can be long - especially with some cc licenses...
[16:12] <jat_ysu> Thanks...I'm 29 again. (Lies like a rug...)
[16:12] <tdonohue> jat_ysu: yes, happy birthday!
[16:12] <mhwood> Happy birthday
[16:13] <caryn> jat_ysu: happy b-day!
[16:13] <jat_ysu> at 19 to that number . LOL
[16:13] <lcs> jat_ysu: happy brithday!
[16:13] <jat_ysu> Nite all...driving in sleet .
[16:13] * jat_ysu (n=jtrimble@maag127.maag.ysu.edu) Quit ("Leaving")
[16:13] <mdiggory> mhwood: I ponder how many batch uploaded files in ones repository would have to change if the policy for submission changed...
[16:13] <mdiggory> One license file per Item
[16:14] <lcs> gotta go, bye.
[16:14] <mdiggory> later
[16:14] <caryn> theoretically, there's already a distinct license file per item, right? b/c agreement to license is part of the process
[16:14] <kshepherd> i'd be interested in feedback/opinions on the best logic to use re: DS-411
[16:14] * lcs (n=lcs@serenity.hul.harvard.edu) has left #duraspace
[16:14] <kshepherd> (one of my questions is how most people are using dc.contributor.* or how they expect it to be handled)
[16:15] <mhwood> 'twould be nice if there were a collection of licenses that could be selected from, or you can add your own to the collection. I doubt there are many sites where every license is unique.
[16:15] <caryn> mhwood: agreed! might be fairly straightforward if cc licensing is used...
[16:16] * mdiggory wants to do away with summaryList DIM/META etc and encode logic in wing instead
[16:17] <mdiggory> I.E. the selection of what content is going intot he summaryList is in DRI and java, not in xslt
[16:18] <tdonohue> mdiggory: eek. what if you want to customize what fields display?
[16:18] <mhwood> Sounds sensible. What do we lose by not delaying to XSL stage.
[16:18] <mdiggory> no going to METS/DIM to get those values... if stored in search engine... no pulling those DSO into memory to get the values...
[16:18] <kshepherd> hrm, that's another option
[16:18] <mdiggory> tdonohue: still customizable...
[16:18] <kshepherd> didn't initially think of a non-DIM solution
[16:19] <mdiggory> just properly separates content selection from theming
[16:19] <mdiggory> kshepherd: this probibly too over the top for a quick solution
[16:19] <mdiggory> your approach is warranted as well
[16:20] <mdiggory> xsl choose/when logic seems to vary across transformers
[16:20] <kshepherd> i'm just worried that a quick patch will change behaviour too much for people who actually rely on dc.contributor.supervisor or dc.contributor.advisor *not* appearing as an author
[16:20] <kshepherd> or maybe they should
[16:20] <kshepherd> it's tricky
[16:20] <mdiggory> I recall Xalan and Saxon behaving differently in some cases
[16:20] <tdonohue> mdiggory: would make sense, as long as you keep it completely separate and not put it in the horrible <dri:table> tag (which is the worst thing ever)
[16:20] <kshepherd> (plus the delimiter issue i mention)
[16:21] <mdiggory> tdonohue: Was anticipating using dri:list, but totally get your point.
[16:22] <mhwood> Too complex an issue for 1.6.0 at this point?
[16:22] <tdonohue> mdiggory: dri:list is fine...that's a little less "structured" (and able to be themed). dri:table is more annoying and hard to change the them of.
[16:22] <mdiggory> right...
[16:24] <tdonohue> mhwood: the Java fix might be too complex right now for 1.6.0...but, if we can figure out an XSLT quick fix, maybe
[16:24] <mhwood> kshepherd I agree there could be sites depending on current behavior.
[16:24] <mdiggory> kshepherd: right now, I suspect any attempt to alter what is listed in SummaryList or SummaryView requires overriding the xslt template anyways
[16:24] <mhwood> No time to prepare people for such a change.
[16:25] <kshepherd> mm.. that's what i'm a bit worried about
[16:25] <caryn> just an fyi - in the most current dc schema (not library application profile), contributor is not qualified...
[16:26] <kshepherd> mhwood: it could be the sort of thing that i can just write some recipes for and stick them on the wiki, rather than try and patch in trunk/source
[16:26] * snail (n=stuart@130.195.178.61) Quit ("Leaving.")
[16:26] <kshepherd> i'd never noticed the 'dodgy logic' until someone with a mix of dc.creator and dc.contributor.author pointed it out to me
[16:26] <mhwood> kshepherd I think that might be best for now.
[16:27] <caryn> definitely good idea
[16:27] <mdiggory> I would approach maybe conservative strategy... maybe just support the broken behavior, just output dc.contributor.author
[16:27] <kshepherd> caryn: you're right.. not sure where the 'author' qualifier came from initially, and as we know it should have been kept dc.creator anyway ;)
[16:27] <kshepherd> mdiggory: yeah, i'm coming around to that thinking now
[16:28] <kshepherd> and will just make some alternative templates available on the wiki
[16:28] <mhwood> IIRC this is not the only place where DC got "stretched" a little.
[16:28] <caryn> kshepherd: that would be good
[16:28] <tdonohue> it'd be nice to "try" to support dc.contributor.author and dc.creator (if possible)....there are a lot of sites that moved to using dc.creator
[16:28] <caryn> the trick at this point is that 1.6 makes use of a few fields that are stretched...
[16:28] <mdiggory> thats fine too
[16:28] <tdonohue> (though, I realize DSpace still doesn't tend to fully support dc.creator usage)
[16:29] <kshepherd> well, now that the OAI harvester plugin is shipping with 1.6, any records taht are harvested from another dspace instance will be full of dc.creator
[16:29] <kshepherd> but probably not *both* dc.creator and dc.contributor.author
[16:29] <mdiggory> kshepherd: correct
[16:29] <kshepherd> so i guess we should be alright
[16:29] <mdiggory> I assume only if they support dc terms
[16:29] <mdiggory> otherwise, it would just be dc.contributor
[16:29] <tdonohue> kshepherd: correct. A site is really likely to have either dc.creator OR dc.contributor.author...not likely to have both
[16:30] <kshepherd> right
[16:30] <kshepherd> mdiggory: yeah, the qualifier was unnecessary there, shows how pervasive the metadata mangling has become ;)
[16:30] <caryn> true
[16:30] <mdiggory> and even then... its a bastardization dc.contributor.author? whats that?
[16:30] <kshepherd> ?
[16:31] <mhwood> I guess we need a "clean up our DC act" project.
[16:31] <mdiggory> only DSpace uses dc.contributor.author
[16:31] <kshepherd> oh yeah, that's what i meant
[16:31] <kshepherd> unfortunatley, that's where my first big leap into DC began ;)
[16:32] <kshepherd> mhwood: yeah, it won't be a quick project ;)
[16:32] <mdiggory> ther is no dcterms = author
[16:32] <caryn> on a somewhat related note... is there any documentation of where the dc fields are used in the dspace structure? i.e. where is dc.identifier.issn used? The registry says "do not remove"
[16:32] <caryn> author = creator
[16:33] <caryn> generally
[16:33] <mdiggory> I don't think ther is a reason that issn is required to be present
[16:33] <kshepherd> i can't think of one..
[16:34] <kshepherd> unless a default input form requires it, but that doesn't rnig any bells either
[16:34] <mdiggory> note: significant "bias" appears in some of the documentation
[16:34] <caryn> dspace-1.6.0-rc1-release\dspace\config\registries\dublin-core-types.xml indicates a few fields are "used by system: do not remove" (commented xml)
[16:34] <mdiggory> I.E. assumptions about things "that were going to be implemented but never were"
[16:35] <caryn> got it - so the easy answer is "try to remove it and see if anything breaks"?
[16:35] <mhwood> Hmmm, how to get a list of things that the *code* (not a configuration) depends on.
[16:36] <tdonohue> I think the fields that the *code* depends on are all in the InstallItem class (which initializes a newly deposited item)...or at least "most" of them should be there
[16:37] <tdonohue> InstallItem uses dc.date.accessioned, dc.date.available, dc.date.issued, dc.identifier.uri and dc.description.provenance
[16:37] <kshepherd> thanks guys, i'll try summarise our wee discussion on the JIRA issue (re itemSummaryList-DIM)
[16:37] <kshepherd> brb, coffee
[16:37] <tdonohue> those are the main required DC fields, i believe
[16:37] <mdiggory> dc.title
[16:37] <tdonohue> oh, yea. dc.title too...whoops
[16:38] <mdiggory> dc.contributor.author?
[16:38] <mdiggory> passibly can get away without it
[16:38] <tdonohue> nope...authors are not required for items
[16:38] <tdonohue> just a title
[16:38] <mdiggory> where, the submission UI?
[16:39] <tdonohue> yes. Submission UI doesn't require an author be entered
[16:39] <mdiggory> Think we need an inputforms example that is just the require fields ;-)
[16:39] <mdiggory> or... dc.title
[16:39] <mhwood> Well, it *generates* values for provenance, but how much of that stuff is required because the code wants it and how much because it's assumed that the users want it?
[16:39] <caryn> interesting - there are a variety of fields that are documented as "required", but aren't really...
[16:39] <caryn> provenance is also not an official qualifier for description
[16:39] <mdiggory> again... "librarian bias", not that I don't favor librarians and all... ;-)
[16:40] <caryn> it is useful for the system, to document how it has changed over time
[16:40] <caryn> should i admit that i work in a library at this point 8-)
[16:40] <tdonohue> caryn: yea...since 1.0 DSpace hasn't followed qualifiers correctly...it has made up a lot of them through the years
[16:40] <mhwood> Long term DSpace needs to decouple from DC and just support it out of (a) what DSpace needs to run, + (b) what sites configure to support.
[16:40] <mdiggory> this origin of author and provenance predate the current state of DCMI recomendations
[16:41] <caryn> simple dc would be easiest - most systems are going to use or at least map to/from that
[16:41] <caryn> it's only 15 elements, so it's pretty simple
[16:41] <mdiggory> back prior to the recommendation "not" to make up your own
[16:41] <caryn> true!
[16:41] <mhwood> Well, we need to think about what DSpace needs to operate vs. what sites want to support.
[16:41] <caryn> related question - do you know if i can setup a submission form to populate multiple fields?
[16:42] <caryn> i.e. the form says "author", but it populates dc.creator, and custom.author?
[16:42] <mdiggory> the path forward is to offer a separate namespace "ds" to push non dcterms qualifiers into
[16:42] <mdiggory> and the a processing script to migrate them
[16:42] <caryn> mdiggory: +1 definitely!!!
[16:42] <caryn> xslt to get from ds to dc
[16:42] <mhwood> mdiggory: sounds right
[16:43] <tdonohue> mdiggory: yep...in a way we mostly just need to rename our "dc" schema...in reality it's DIM (DSpace Internal Metadata) format, which is similar to DC, but not the same
[16:43] <mdiggory> the big concern is that much testing would need to happen across that platform
[16:43] <mdiggory> tdonohue: event he namespace is incorred
[16:44] <mdiggory> incorred = incorrect
[16:44] <tdonohue> right..so, change "dc" to "ds" and then modify the namespace
[16:44] <tdonohue> (i know, that's likely to break a lot of things though)
[16:44] <caryn> agreed - might be able to do a ds profile for dc
[16:47] <mhwood> Sounds like a 2.0 issue? It's going to be disruptive no matter what automated helpers we can reasonably provide.
[16:47] <tdonohue> yea...people would need a lot of warning...could be very disruptive
[16:47] <caryn> true!
[16:48] <caryn> on both counts (disruptive, and 2.0 issue)
[16:48] <mdiggory> had something like this going for awhile...
[16:48] <mdiggory> https://scm.dspace.org/svn/repo/modules/dspace-rdf/trunk/src/main/resources/org/dspace/adapters/rdf/vocabularies/customterms.rdf
[16:49] <mdiggory> and
[16:49] <mdiggory> https://scm.dspace.org/svn/repo/modules/dspace-rdf/trunk/src/main/resources/org/dspace/adapters/rdf/vocabularies/dspace.n3
[16:50] <mdiggory> I did some remapping in java
[16:50] <mdiggory> https://scm.dspace.org/svn/repo/modules/dspace-rdf/trunk/src/main/java/org/dspace/adapters/rdf/vocabularies/DS.java
[16:50] <caryn> interesting
[16:50] <mdiggory> This was all used for some of the RDF/LoD work I had been doing in my previous incarnation at MIT
[16:51] * mhwood bumps RDF up on his reading list...again....
[16:51] <caryn> i hear ya!
[16:52] <caryn> rdf is like a roller coaster on my list...
[16:52] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[16:52] <mdiggory> its very easy to get trapped in it... use lightly...
[16:52] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:53] <caryn> lol - don't look directly at the triplets... anyway, i need to log-off. thanks for all the great work you guys are doing on 1.6! have a great afternoon/evening
[16:53] <kshepherd> i think dspace-rdf is great
[16:54] <mdiggory> the above code is actionable here: http://dspace.mit.edu/metadata/handle/1721.1/7581/rdf.xml
[16:54] <kshepherd> a guy from another nz uni is going to be testing it soon, unfortunately it looks like he already closed his IRC client
[16:54] <mdiggory> and Item example
[16:55] <mdiggory> http://dspace.mit.edu/metadata/handle/1721.1/49807/rdf.xml
[16:55] <kshepherd> mdiggory: iirc, teh MIT version is slightly different to what we have in scm.dspace/org/svn/repo/modules?
[16:55] <kshepherd> but perhaps not for Items?
[16:55] * caryn (i=80c8e115@gateway/web/freenode/x-rszdadbwplktdpar) Quit ("Page closed")
[16:55] <kshepherd> (i remember the "no more aggregations of items" difference)
[16:56] <mdiggory> I think i amy even have broke provenance here
[16:56] <mdiggory> dspace-rdf needs "friends"
[16:56] <mdiggory> to care and feed it
[16:57] <kshepherd> heh
[16:57] <mdiggory> we have to correct something... http://purl.org/dc/terms/provenance does exist
[16:58] <mdiggory> it is ok
[16:58] * ChanServ (ChanServ@services.) Quit (shutting down)
[16:59] * ChanServ (ChanServ@services.) has joined #duraspace
[17:00] <mhwood> Sorry, must go. Thanks!
[17:01] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:35] * PeterDietz (n=PeterDie@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[17:55] * tdonohue (n=tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[19:00] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has left #duraspace
[19:20] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit ()
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.