Timestamps are in GMT/BST.
[0:41] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[3:31] * Tonny_DK (~thl@130.226.36.117) Quit (*.net *.split)
[3:31] * cbeer_ (~cbeer@146.115.109.210) Quit (*.net *.split)
[3:37] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[3:37] * cbeer_ (~cbeer@146.115.109.210) has joined #duraspace
[4:07] -hubbard.freenode.net- *** Looking up your hostname...
[4:07] -hubbard.freenode.net- *** Checking Ident
[4:07] -hubbard.freenode.net- *** Found your hostname
[4:07] -hubbard.freenode.net- *** No Ident response
[4:07] [frigg VERSION]
[4:07] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:07] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:07] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[5:38] * bradmc (~bradmc@75-139-111-085.dhcp.mant.nc.charter.com) Quit (Quit: bradmc)
[5:49] * krnl_ (Andrius@83.171.18.74) has joined #duraspace
[6:19] * kshepher1 (kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[6:24] * kshepherd (kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (*.net *.split)
[8:03] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[8:24] * bradmc (~bradmc@75-139-111-085.dhcp.mant.nc.charter.com) has joined #duraspace
[9:12] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[9:13] * bradmc (~bradmc@75-139-111-085.dhcp.mant.nc.charter.com) Quit (Quit: bradmc)
[9:20] * bradmc (~bradmc@75-139-111-085.dhcp.mant.nc.charter.com) has joined #duraspace
[9:25] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[12:20] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[12:39] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[12:54] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[13:42] * mdiggory (~mdiggory@64.134.222.79) has joined #duraspace
[14:52] * carynn (~cneiswen@c726.staff.lib.uci.edu) has joined #duraspace
[15:45] * jatrimble (~jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[15:47] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:56] * Keithg (~Keith@207.138.47.158) has joined #duraspace
[15:56] * cccharles (~cccharles@131.104.62.47) has joined #duraspace
[16:00] <PeterDietz> Hey Everyone, thus begins Developers Meeting on Weds, April 28, 2010
[16:01] <PeterDietz> Announcements
[16:01] <PeterDietz> -GSoC selections announced.
[16:01] <PeterDietz> -Changes to Documentation Workflow (Mark Diggory)
[16:01] <PeterDietz> --Using Confluence as the Documentation System. Requires a process for cleanup and markup effort to target pages for inclusion in "the docs", and to keep content from getting stale, outdated, misleading.
[16:01] <PeterDietz> Our four projects for GSoC are: Unit Testing (Pere Villega), DS2 Storage Services backporting to DS1.x (Andrius Blazinskas), REST API (Bojan Suzic), Storage based on Semantics (Yiganag Zhou)
[16:02] <PeterDietz> I was able to say which one I was most excited about, but it turns out I'm pretty excited for all of the projects.
[16:03] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[16:03] <PeterDietz> P.S. I'm filling in for Tim Donodue who is on vacation this week.
[16:03] * GavinH (~GavinH@86-44-127-17-dynamic.b-ras2.bbh.dublin.eircom.net) has joined #duraspace
[16:04] <kshepher1> those do all like excellent projects
[16:04] <GavinH> Hi
[16:04] * kshepher1 is now known as kshepherd
[16:04] <PeterDietz> p.s. this meetings log can be found at: http://www.duraspace.org/irclogs/index.php?date=2010-04-28
[16:05] <PeterDietz> Hi GavinH
[16:05] <PeterDietz> Next, is Documentation work flow changes
[16:06] <GavinH> HI Peter from Ireland.
[16:06] <PeterDietz> now that we have confluence, refining our documentation and making changes easily can become our job as the community
[16:07] <PeterDietz> I'll hope that jatrimble and mdiggory can add some words to this
[16:07] <mhwood> Wasn't it our job before?
[16:07] <PeterDietz> correct, but I think the change is getting pages cleaned up so that confluence/wiki become "the documentation"
[16:08] <kshepherd> i might just quickly grab a coffee while we wait for mark/jeff -- need to wake up
[16:08] <mdiggory> Hi
[16:08] <kshepherd> oh
[16:08] <GavinH> << armed with a coffee already
[16:09] <PeterDietz> I went to make coffee, but I ran out of filters :(
[16:09] <jatrimble> I'm awake.
[16:10] <mdiggory> kshepherd: I will never keep a man from his coffee (said while sitting in a Starbucks)
[16:10] * PeterDietz meeting postponed 5 minutes (jk)
[16:11] <mdiggory> Good I can go wait in line to get a refill ;-)
[16:11] <Keithg> what's storage based on semantics?
[16:11] <mdiggory> We just talk about storing things, not actually store them.
[16:11] <Keithg> :)
[16:12] <mdiggory> Ok, but seriously folks...
[16:12] <mdiggory> you can catch my next show at the Ritz carlton on friday
[16:12] <mhwood> http://wiki.dspace.org/confluence/display/DSPACE/GSOC10+-+Storage+Service+Implementations+Based+on+Semantic+Content+Repository
[16:13] <mdiggory> Basically it is using triplestores to capture the metadata associated with the content
[16:14] <mdiggory> Opening the door to allow strucutral metadata to be unconstrained to the DSpace Community/Collection/Item datamodel
[16:14] * kshepherd has coffee :)
[16:14] <Keithg> sounds interesting
[16:15] <mdiggory> The Semantic and Storage Service projects align very closely with eachother.
[16:16] * mdiggory (~mdiggory@64.134.222.79) Quit (Read error: Connection reset by peer)
[16:16] * mdiggory_ (~mdiggory@64.134.222.79) has joined #duraspace
[16:16] <mdiggory_> And we should be able to clarify how DSpace, Fedora and Mulgara relate to each other within these projects.
[16:17] <PeterDietz> re:GSoC I did see that we are currently in the interim meet the community phase, so that means google orders us to be friendly for the next month
[16:17] <mhwood> So that squares with the DSpace 2 notion that community and collection objects go away by becoming relationships among items (if you want to organize your assets that way)?
[16:17] <mdiggory_> Without diving into each project, perhaps we should chat about management and how we will be operating
[16:17] <mdiggory_> mhwood: yep
[16:18] <mdiggory_> I have been considering how we best promote "community" in the student group.
[16:19] <mdiggory_> and thinking that we need to have stronger incentives for students to be communicating with each other and the developers at large
[16:19] <kshepherd> use dspace-devel list more?
[16:19] <GavinH> i think maybe go beyond that? :)
[16:19] <mdiggory_> Yes, we need to go beyond that
[16:19] <kshepherd> fair enough
[16:19] <GavinH> I think all key members of active community, should share skype (/or im) so people can sit in "virtual" realtime skype chats
[16:20] <PeterDietz> if the students are of age/at OR10, I'll buy them all a round
[16:20] <kshepherd> we haven't even gone that far in the past, really, from what i've noticed
[16:20] <mdiggory_> possibly mandating that the students hold a meeting weekly to discuss their projects with eachother and the developers that attend
[16:21] <mdiggory_> The challenge with Skype is that the conversations are rather private
[16:21] <PeterDietz> and then in terms of getting comfortable talking with the community IRC is probably the best place, I probably wouldn't want #dspace to be spammed with help with my project, but more general things in there would be best
[16:21] <GavinH> well, if you want them to talk to each other, its easier doing that kind of thing privately
[16:21] <GavinH> and not auto-logged onto a webpage.
[16:21] <mdiggory_> I think the duraspace IRC channel really would be the best place to approach these meetings
[16:22] <mdiggory_> But talking privately is not promoting community
[16:22] <carynn> IRC would give the students the most "real-world" experience, at least in the DuraSpace community...
[16:22] <GavinH> i meant just for day to day
[16:23] <PeterDietz> ok, so not much said for documentation changes
[16:23] <mdiggory_> GavinH: this is the problem we have encountered in the past. The student and mentor pair up and then basically "disappear" until evaluation period
[16:23] <GavinH> Would be useful having a weekly "visual/audio" conference
[16:24] <GavinH> where they present where they are..
[16:24] <GavinH> to the rest of community
[16:24] <mhwood> Well, the meetings would be for thoughts that are worked out enough for public exposure.
[16:24] <GavinH> We could probably provide access to an elluminate room for that purpose.
[16:24] <mdiggory_> tend to agree with mhwood
[16:25] <mdiggory_> that this meeting should be the students working together possibly with mentors present or not present
[16:25] <mhwood> How visual would it be, really? Talking heads we don't need.
[16:25] <PeterDietz> Well I'll just state that the front page of confluence ( DSpace 1.6.1 (Kim Shepherd)
[16:25] <PeterDietz> -DC-Date related bugs � values out of the range and date format inconsistencies.
[16:25] <PeterDietz> -Update and other bugs that need more eyes
[16:25] <PeterDietz> -1.6.1 Open Issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10020&fixfor=10030
[16:25] <PeterDietz> JIRA Catch-Up � starting with issue DS-517 (and getting as far as we can).
[16:25] <PeterDietz> -Recent Issues http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-8w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC ) has some nifty rules to follow to clean up the random documentation in the wiki. Content has been migrated, now we would like to promote cleaning up atleast the top 150 viewed pages, and then as you use the other pages to clean them up as well
[16:26] * PeterDietz does not know what IRC just did
[16:26] * robint (~52292565@gateway/web/freenode/x-pcmmlvgekqllduzs) has joined #duraspace
[16:27] <GavinH> ellumiante provides audio conferencing, shared desktop, presentations, txt chat room(+ transcript) and 6 video feeds if needed.
[16:27] <mdiggory_> PeterDietz: delayed response?
[16:27] <PeterDietz> i had something else in my clipboard i suppose
[16:27] <mdiggory_> So we have some ideas about medium of communication that may need to be explored
[16:28] <PeterDietz> DSpace 1.6.1 (kshepherd)
[16:28] <PeterDietz> -DC-Date related bugs � values out of the range and date format inconsistencies. (robint)
[16:28] <mdiggory_> But do we agree that having the students (and mentors) meeting and evaluating each others ideas on a weekly basis is importnat to put in place early on
[16:29] <GavinH> definately.
[16:29] <carynn> mdiggory: +1
[16:30] <mhwood> I think it can be a good thing. If done, 'twere well it were started quickly.
[16:30] <GavinH> (if u want to check out elluminate - http://uk.elluminate.com/join_meeting.html?meetingId=1253094938593 ) fyi..
[16:30] <mdiggory_> So it sounds we need to work on the schedule for such a thing... and tools...
[16:31] <kshepherd> PeterDietz: was that my cue? or another accidental paste? ;)
[16:31] <mdiggory_> perhaps this should be a first thread of discussion in dspace-gsoc-student
[16:31] <kshepherd> we haven't done Confluence though yet, hmm
[16:31] <GavinH> what timezones are the gsoc students in?
[16:33] <mdiggory_> Ireland, Eastern Europe, China
[16:34] <mdiggory_> there used to be a google map in the socghop app... I can;t find it now
[16:35] * robint_ (~52292565@gateway/web/freenode/x-ehlmknxsbpugotgf) has joined #duraspace
[16:36] <mdiggory_> Sounds like we will take this up in the email list. kshepherd shall we move on?
[16:36] <PeterDietz> unless there should be some consensus on confluence first
[16:36] <kshepherd> ok, well i didn't have a lot to say really, taht wasn't in my earlier email
[16:36] <mdiggory_> ok
[16:36] <kshepherd> svn activity has been pretty low, i have some catching up to do committing patches that i've been sitting on for too long
[16:37] <kshepherd> and i'd rather save more time for the JIRA review than waffle on :)
[16:37] <kshepherd> really would like to hear some opinions on the DCDate changes in 1.6 though, if we have time after our other topics
[16:38] <kshepherd> the granularity stuff that's been added, etc
[16:38] <kshepherd> that's me
[16:39] * robint_ (~52292565@gateway/web/freenode/x-ehlmknxsbpugotgf) Quit (Client Quit)
[16:39] <mdiggory_> can we see the JIRA ticket number again?
[16:40] <PeterDietz> http://jira.dspace.org/jira/browse/DS-554 ?
[16:40] <kshepherd> ?
[16:41] <kshepherd> sorry, i see: DS-401, DS-497 (robin has fixed, waiting commit), DS-553 and DS-554
[16:41] <kshepherd> that i know of.
[16:42] <kshepherd> it's possible there isn't really a big problem, just some small kinks that needed ironing out, but i find usage as far as setting/getting/displaying DCDates still quite inconsistent throughout...
[16:42] <mdiggory_> Well, so the legacy behavior is to allow the extended ISO Date behavior along the same lines of XML schema dates
[16:43] <kshepherd> right
[16:44] <mdiggory_> http://www.w3.org/TR/xmlschema-2/#isoformats
[16:44] <PeterDietz> i'm redoing one of my patches, I talked with claudia and she pointed to some java internal that will spit out a country according to the locale (i.e. Germany == Deutschland == Alemania == Tyskland ) instead of a list maintained within the code
[16:45] <mdiggory_> Yes, we should be using those defaults in Java whereever possible, I saw the fragment of your chat and agree
[16:46] <kshepherd> my thinking right now is that the 'granularity' handling needs a clean up at the very least. perhaps that's all there is to it (aside from that other GregorianCalendar annoyance of rolling dates over when large day_of_month is given)
[16:46] <kshepherd> PeterDietz: good thinking, yeah
[16:47] <robint> You can set GregorianCalendar to function in non-lenient mode which will prevent a day of 32 becoming 1 (or 2, you know what I mean)
[16:47] <kshepherd> i need to i18n jspui stats display properly too
[16:47] <mdiggory_> So, while I support the quick fix of catching the zero components in the timestamp to filter out those parts that shouldn't be there, It hink as well, we need to be careful to allow the application to get back to the original string value whenever possible
[16:48] <kshepherd> robint: that's one thing to look into. i had some initial success validating against GregorianCalendar.getActualMaximum(DAY_OF_MONTH)
[16:48] <kshepherd> but it doesn't behave exactly as i expected
[16:49] <mdiggory_> As DSpace evloves, we rely less and less on the datatypes of metadata fields in the model... which makes me want to see classes like DDCDate go away in favor of treating things as strings whereever possible.
[16:49] <robint> kshepherd: thats disappointing
[16:50] <mdiggory_> and have utilities mediate the validation and formating of things like dates/urls etc
[16:50] <kshepherd> yep i like the idea of nicely formatted strings instead of complicated objects
[16:51] <jatrimble> But, the DCMI has standards for the date entries.
[16:51] <mdiggory_> I do think however, there is support somewwhere in the JAVA JAXP api's for the XML schema ISO Date type that might be better to use than the DCDate thing we created
[16:52] * bradmc (~bradmc@75-139-111-085.dhcp.mant.nc.charter.com) Quit (Quit: bradmc)
[16:52] <mdiggory_> jatrimble: don't think that DCMI requires anything different than the ISO 8601
[16:52] <mdiggory_> does it?
[16:52] <mhwood> Have to say I like converting inputs to structured data ASAP, while we still have some notion of what it's said to represent.
[16:53] <kshepherd> i need to run to a big staff meeting now.. i'll still have my laptop. need to find my way to the room though. brb.
[16:53] <jatrimble> well, it's dependent on if the agency uses cataloging rules
[16:53] <jatrimble> But, Marc, I think a string would be better.
[16:53] <mdiggory_> what? not USE CATALOGING RULES?
[16:54] <jatrimble> LOL
[16:54] <jatrimble> The problem currently is that DSpace requires month/day/year or a combo there of. When using guestimates, catalogers are instructed to use blind dates: 19--
[16:54] <mdiggory_> So... thinking back to 2.0 work...
[16:55] <jatrimble> or 19uu, 190-, 1---
[16:55] <jatrimble> DSpace can't accomodate that.
[16:55] <mdiggory_> in 2.0 the model focuses on deligating validation to the underlying store
[16:55] <jatrimble> Some dates don't need validation..... they should be only validated by the human.
[16:55] <mdiggory_> Most stuff is string, primitive types and XML Schema types otherwise
[16:56] <robint> The underlying problem with DCDate is that it uses java.util.Date which is miiliseconds since 1970 which translates to having a day and month, sometimes we just want a year, or year and month.
[16:56] <jatrimble> yes...especially archival material where you only have a century or decade as your date.
[16:56] <mhwood> So we need some fields which are *dates* and other fields which are *strings representing time*.
[16:56] <mdiggory_> robint: I'm thinking the XML schema tool might alleviate this
[16:57] <jatrimble> exactly... DC.coverage.temporal does this
[16:57] <robint> mdiggory: I'll do some reading, thanks
[16:57] <jatrimble> <==Needs to run....any last things?
[16:57] <mhwood> So then we need to pin down which fields are which.
[16:58] <mdiggory_> http://www.docjar.com/docs/api/javax/xml/datatype/XMLGregorianCalendar.html
[16:58] <Keithg> need date range searching to magically work with strings representing time, too
[16:58] * jatrimble (~jtrimble@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[17:00] <Keithg> or i guess reference the *dates* fields
[17:01] <kshepherd> back
[17:01] <PeterDietz> the hour time slot for the meeting has officially expired, but interested and able to meet can stick around
[17:02] <PeterDietz> I just noticed that there exists a "leap second"
[17:02] <kshepherd> heh
[17:03] <PeterDietz> so would it be to remove DCDate things and just reference dates as text, and when doing operations such as sorting/indexing its up to that engine to do it on its own?
[17:03] <kshepherd> mdiggory_: useful link thanks
[17:04] <mhwood> How many differnt hunks of code to puzzle out the meaning of "19uu" do we want?
[17:04] <mdiggory_> Keithg: well, in my work on Solr, we would approach indexing the values to assure such capabilities whcih usually means being strict about the value being and representation of java date
[17:04] <PeterDietz> I haven't messed with dates so ignore my past statement if needed
[17:05] <mdiggory_> which means storing the date as a string, but making sure you can turn it into a java util date for indexing.
[17:05] <Keithg> okay - thanks for explaining that
[17:06] <robint> Sorry, got to go.
[17:06] <Keithg> 20th century = 1900 ?
[17:06] * robint (~52292565@gateway/web/freenode/x-pcmmlvgekqllduzs) Quit (Quit: Page closed)
[17:07] <mhwood> 20th century is an interval: 1900-1999. Hey, do we just need an interval type?
[17:07] <mdiggory_> its still got to be ISO 8601
[17:07] <PeterDietz> so something like date precision
[17:08] <Keithg> fuzzy dates! :)
[17:09] <PeterDietz> something from 1940's is (1940-00-00:00:00:00, DECADE) ?
[17:10] <kshepherd> hm
[17:10] <PeterDietz> or maybe that doesn't even matter
[17:10] <kshepherd> there's a worrying comment in DCDate:
[17:11] <mdiggory_> I don't think you get that capability from the ISO
[17:11] <mdiggory_> though that would be sweet
[17:11] <kshepherd> // if date is 1-jan, assume it's because this was set for year
[17:11] <kshepherd> that's the kind of thing we want to avoid assuming ;)
[17:11] <mhwood> Ewww.
[17:11] <mdiggory_> What I think is that, like jtrimble just said, this is a appropriate domain of dc.coverage.temporal
[17:12] <kshepherd> but this is getting close to the recent granularity changes in DCDate
[17:12] <kshepherd> mdiggory_: yeah agreed
[17:13] <Keithg> ok
[17:14] <mdiggory_> the range of temporal is a "PeriodOfTime"
[17:14] <mdiggory_> http://dublincore.org/documents/dcmi-terms/index.shtml#terms-temporal
[17:14] <PeterDietz> so what if your item is something that happens exactly on new years, like a picture of the ball drop. Does that get granularity YEAR, because it was (either 2010:00-01 or 2010-01-01:00:00:0 )0
[17:15] <PeterDietz> and are months 0 indexed?
[17:15] <mdiggory_> in the patch, ,yes that is the problem
[17:15] <kshepherd> PeterDietz: as of right now, in trunk/1_6_x, if it was constructed from a java Date object, then yes
[17:16] <mhwood> Sounds like DCDate is trying to be several different types.
[17:19] <PeterDietz> so say we squashed DCDate, we'd likely end up rebuilding/using some utilities to process dates
[17:19] <kshepherd> yeah
[17:20] <kshepherd> but they dont have to be methods of this big complicated class
[17:20] <kshepherd> they can be generic utilities that work on strings and the standard date types we've discussed earlier
[17:21] <kshepherd> i think that's where mdiggory_ was going.. am i correct?
[17:21] <PeterDietz> and we would want to continue to store that value (in DB) as something that conforms to iso 8601
[17:22] <mdiggory_> Yes, I'm trying to go that way
[17:22] <mdiggory_> Sorry I drifted off into DCMI documentation for a bit
[17:22] <mdiggory_> http://dublincore.org/documents/domain-range/index.shtml#PeriodOfTime
[17:22] <mdiggory_> sufficiently vague
[17:22] <mdiggory_> An interval of time that is named or is specified by its start and end dates.
[17:23] <kshepherd> nice
[17:24] <kshepherd> should probably try to raise awareness of things like PeriodOfTime and dcterms:temporal
[17:25] * kshepherd 's laptop batteries are nearly dead
[17:26] <mhwood> So is there already a class out there that represents IS8601 in all its glory? So we don't have to write such a hairy beast?
[17:26] <kshepherd> if i stop responding, it means i had to close the lid and actually listen to the IRL meeting i'm at
[17:27] <PeterDietz> ok, thanks for you help kshepherd hopefully we'll come up with some good solutions for DCDate
[17:27] <kshepherd> thanks to all for this discussion
[17:28] <kshepherd> helps me plan my patching, and i'm glad a few of us are thinking more about dates :)
[17:29] <Keithg> /quit catpool leaving
[17:29] * Keithg (~Keith@207.138.47.158) Quit (Quit: Leaving)
[17:30] <kshepherd> seems like we've all stopped talked anyway :P
[17:30] <kshepherd> hope i didn't divert from teh confluence stuff too much
[17:31] <kshepherd> s/talked/talking/
[17:31] <PeterDietz> I don't think there is anything that tracks granularity, but there are plenty of utils for doing date stuff
[17:32] <mhwood> I'm going to have to go.
[17:32] <kshepherd> investigating intervals/periods as an alternative to 'fuzzy' dates sounds good, though could result in some battles with cataloguers/IR admins ;)
[17:33] <kshepherd> yeah i have to go too, just about out of batteries
[17:33] <kshepherd> cheers all
[17:33] <mdiggory_> mhwood: that is what I was suggesting with my link to XMLGregorianCalendar
[17:33] <mhwood> Ah, more to read.
[17:33] <PeterDietz> I'm wondering if SimpleDateFormat might be enough
[17:35] <mdiggory_> there are any ways to construct one
[17:35] <mdiggory_> http://www.docjar.com/docs/api/javax/xml/datatype/DatatypeFactory.html
[17:35] <PeterDietz> (as utility to do work as opposed to solving metadata folk battles over how to distinguish date periods )
[17:35] <mdiggory_> any = many
[17:35] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:36] <mdiggory_> and durations helpout as well
[17:36] <mdiggory_> http://www.docjar.com/docs/api/javax/xml/datatype/Duration.html
[17:37] <mdiggory_> PeterDietz: Some battles are won
[17:46] * mdiggory_ (~mdiggory@64.134.222.79) Quit (Quit: mdiggory_)
[17:47] * carynn (~cneiswen@c726.staff.lib.uci.edu) has left #duraspace
[17:54] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[18:01] * GavinH (~GavinH@86-44-127-17-dynamic.b-ras2.bbh.dublin.eircom.net) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- The professional IRC Client :D)
[18:01] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[18:10] * ksclarke (~kevin@184.39.8.146) Quit (Read error: Operation timed out)
[18:22] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[18:42] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[19:50] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Quit: mdiggory)
[20:08] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[20:08] * bradmc (~bradmc@75-139-111-085.dhcp.mant.nc.charter.com) has joined #duraspace
[21:07] * ksclarke (~kevin@184.39.8.146) Quit (Quit: Leaving.)
[21:10] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[21:54] * ksclarke (~kevin@184.39.8.146) Quit (Read error: Connection reset by peer)
[21:54] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[21:55] * ksclarke (~kevin@184.39.8.146) Quit (Client Quit)
[21:55] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[22:38] * bradmc (~bradmc@75-139-111-085.dhcp.mant.nc.charter.com) Quit (Quit: bradmc)
[22:50] * ksclarke (~kevin@184.39.8.146) Quit (Quit: Leaving.)
[23:55] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
[23:55] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[23:55] * mdiggory_ is now known as mdiggory
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.