Timestamps are in GMT/BST.
[0:51] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[4:28] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[5:18] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[5:20] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[6:36] -asimov.freenode.net- *** Looking up your hostname...
[6:36] -asimov.freenode.net- *** Checking Ident
[6:36] -asimov.freenode.net- *** Found your hostname
[6:36] -asimov.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:59] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[9:50] * barmintor_beer (~ba2213@franklin.cul.columbia.edu) Quit (Read error: Connection reset by peer)
[9:51] * barmintor_beer (~ba2213@franklin.cul.columbia.edu) has joined #duraspace
[11:33] * ajs6f (d80c403e@gateway/web/freenode/ip.216.12.64.62) has joined #duraspace
[11:33] <ajs6f> afk
[12:19] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:36] * elschlomo (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[12:37] * elschlomo (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[12:38] * fasseg (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[12:39] * fasseg (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[12:39] * fasseg (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[12:45] * fasseg (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[12:47] * fasseg (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[12:51] * ajs6f (d80c403e@gateway/web/freenode/ip.216.12.64.62) Quit (Ping timeout: 245 seconds)
[12:58] * ajs6f (d80c403e@gateway/web/freenode/ip.216.12.64.62) has joined #duraspace
[12:58] * Dan_Davis (4a4f9413@gateway/web/freenode/ip.74.79.148.19) has joined #duraspace
[13:00] * cwilper (ad579cc8@gateway/web/freenode/ip.173.87.156.200) has joined #duraspace
[13:01] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:46] <fasseg> i wouldn't be able to think at 100°F, my head started steamventing at 89°F
[13:47] <ajs6f> Well, I was born here and truthfully, I enjoy the heat and humidity. You do have to be careful of dehydration or heat stroke if you are working outside, but we _were_ built for the savannah, right?
[13:53] <ajs6f> bbl
[13:53] * ajs6f (d80c403e@gateway/web/freenode/ip.216.12.64.62) Quit (Quit: Page closed)
[13:55] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Quit: Leaving.)
[13:56] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:07] * fasseg (~smuxi@HSI-KBW-46-223-116-28.hsi.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[14:21] * Dan_Davis (4a4f9413@gateway/web/freenode/ip.74.79.148.19) Quit (Quit: Page closed)
[14:30] * barmintor_beer is now known as barmintor
[14:31] <barmintor> cwilper: did you work that MPT store issue out last week? I've got some time to work on it this morning if not.
[14:36] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[14:49] * spotvin (80c25750@gateway/web/freenode/ip.128.194.87.80) has joined #duraspace
[14:57] * Amy_ (80cea088@gateway/web/freenode/ip.128.206.160.136) has joined #duraspace
[14:58] <Amy_> Hi Sarah
[14:58] * Maura (80c1a3fa@gateway/web/freenode/ip.128.193.163.250) has joined #duraspace
[14:58] <spotvin> Hi Amy
[14:58] <spotvin> Hi Maura
[14:58] <Amy_> Hi Maura
[14:58] <Maura> Hi.
[14:59] <Amy_> I'm hoping that some of the developers listed as being on are actually here; there was interest expressed during OR in more DCAT members using this channel to communicate so they could see what's going on.
[15:00] <spotvin> Yes, me, too!
[15:00] <spotvin> Mark Diggory, are you here?
[15:01] <Amy_> Let's give Maureen a couple of extra minutes to log on, then perhaps you could lead off Sarah? I'm intending to largely lurk since I'm not a metadatarian ; I'm here to do the grunt work you assign me. :)
[15:01] <spotvin> Oh no, I was also intending to be somewhat lurkish.
[15:02] <barmintor> Depending on his chat client, he might get an alert if you include mdiggory in your message
[15:02] <tdonohue> Hi Amy_, Maura and spotvin. Just a quick FYI on IRC...you can "ping" people by mentioning their username. So, to ping Mark Diggory you'd just say mdiggory (his username). Pinging them usually will make their IRC window "flash" or similar on their desktop, to let them know someone has mentioned them
[15:02] <spotvin> Thanks, tdonohue
[15:02] <tdonohue> aha..I see barmintor just said the same thing :)
[15:03] <Amy_> hmmm...well, I get the impression Maura has some experience, so perhaps she can helpus get started?
[15:03] <Amy_> Thanks, Tim!
[15:03] <spotvin> and barmintor
[15:03] <barmintor> spotvin: No problem.
[15:03] <Maura> I have metadata experience, but I am new to what we want to do for the dspace update.
[15:04] <spotvin> mdiggory, I mentioned you in particular because we were looking at the comments you added to some of these tasks in JIRA
[15:04] <Amy_> Okay, then, into the dark yonder woods we shall go....
[15:04] <spotvin> Yes
[15:04] <spotvin> I can start us off
[15:04] <Maura> Thanks
[15:04] <spotvin> So, this seems to be a rather thorny issue
[15:04] <Maura> what makes it a thorny issue.
[15:05] <spotvin> Deceptively simple to think of updating the registry to DCTERMS with some plan for migration
[15:05] <spotvin> but thorny given the other demands for metadata and modeling in DSpace
[15:05] <spotvin> Here are some potential thorns:
[15:06] <spotvin> As Amy has mentioned: 1) interest in other schema; 2) migration
[15:06] <spotvin> Also: 3) potential need to align with the Fedora model
[15:06] <spotvin> 4) potential implications for harvesting
[15:07] <spotvin> 5) how does this fit into demands for linked data / semantic web?
[15:07] <spotvin> Do you think that we can clear some of the thorns away by declaring it our mandate to come up with a plan to update DCTERMS?
[15:07] * MWalsh (8092add0@gateway/web/freenode/ip.128.146.173.208) has joined #duraspace
[15:07] <spotvin> Hi Maureen
[15:07] <Amy_> Hi Maureen
[15:07] <Maura> Hi Maureen
[15:07] <MWalsh> Hi
[15:08] <MWalsh> Sorry I'm late, previous meeting ran over
[15:08] <Amy_> I think Sarah has a good idea in that we need to simplify what our task is to be. Really, the first step needs to be to determine what current version of DC we need to get in place, then make that happen.
[15:08] <Amy_> NP Marueen
[15:08] <Amy_> *Maureen*
[15:09] <spotvin> i.e., to acknowledge that, while there is much to be done to update the metadata model in DSpace, we are going to simply focus on the DCTERMS issue
[15:09] <Amy_> Agreed-that's probably where we need to start in order to make anything later happen.
[15:09] <spotvin> So I have what may be a pretty basic question
[15:09] <MWalsh> If as Valorie said the goal is the simplest first, then we may need to saty with element.qualifier
[15:09] <spotvin> the current DIM model is basically a schema.element.identifier model, yes?
[15:10] <spotvin> ah ok
[15:10] <tdonohue> correct...DSpace currently only supports metadata structured like "schema.element.indentifer"
[15:10] <spotvin> so, I haven't seen this in action, but is it kosher, for example, to have dcterms.contributor.advisor?
[15:10] <MWalsh> if we move to terms than we need to deal with a host of config changes
[15:11] <Amy_> and I think that's where the rub comes in for the developers--gets complicated
[15:11] <MWalsh> so to begin with the simplest would be to update the our elements/qualifiers
[15:11] <Maura> I agree
[15:11] <spotvin> So, MWalsh, does that mean we can't implement terms?
[15:12] <MWalsh> if we were to we would need to re-model DSpace
[15:12] <spotvin> yes
[15:12] <spotvin> so not kosher to do dcterms.x.x
[15:12] <spotvin> ?
[15:13] <spotvin> or, really, just not useful?
[15:13] <tdonohue> Why can't you simplify and do something like "dcterms.x.x"? I'll just note that "re-modelling" DSpace metadata is potentially a rather large (likely multi-year) project
[15:13] <Amy_> I think there's a desire on the part of repo managers, from what I heard at OR for dcterms
[15:14] <MWalsh> so the consensus is to go to dcterms and dcterms.x.x
[15:15] <Amy_> unless there's an overriding reason to not do so, yes
[15:15] <Maura> yes.
[15:15] <spotvin> point of info: implementing "terms" is distinct from implement "dcterms," or no?
[15:16] <Amy_> different namespaces, I think (?)
[15:18] <Amy_> Okay, so if we're going to look into implementing dcterms, how do we start?
[15:19] <MWalsh> I was thinking when it was said to stay simple that we would update the existing - i.e. not citation but bibliographicCitation, but by simple first we are going in the direction of impleting terms in a way that fits with current DSpace model
[15:20] <Amy_> does it make sense to do what MWalsh suggests, then move on to something larger? will it be 'cleaner' in the long run?
[15:21] <spotvin> MWalsh, would an example of that be: dc.identifier.citation migrated to dcterms.bibliographicCitation?
[15:21] <spotvin> (I mean an example of updating the existing to stay simple?)
[15:21] <tdonohue> +1 MWalsh. I agree...I think you want to stay simple. A few options would be to : (a) update the default "dc" schema so that it's more in line with standards, And/or (b) split the "dc" schema into multiple schemas (e.g. a new "dcterms" schema?) if needed
[15:21] <MWalsh> If we update existing it would be dc.identifier.bibliographicCitation
[15:22] <MWalsh> of course spelled right unlike my typing
[15:23] <Amy_> so what I'm hearing is that we should take tdonohue's option a first, then, if we can and think it in our purview, move on to option b
[15:23] <MWalsh> I think as a first step we should look at the exsiting and update the ships with to be current and in same model
[15:24] <MWalsh> then we look into creating a new namespace for terms - that way it can ship with both
[15:24] <Amy_> makes sense to me
[15:25] <tdonohue> Admittedly, my options "a" and "b" could be done at the same time (or you could do them in order). In some ways, there's a lot of non-standard-DC stuff in the "dc" schema that probably needs to be moved elsewhere.
[15:25] <MWalsh> so we have at least one release with an iterim step for people wanting to move to terms and a model for adding new namesapces
[15:26] <Amy_> spotvin and Maura-any thoughts on pursuing that option?
[15:26] <MWalsh> there is alos the issue of lock down. local additions abound. talk was with current to lock donw elements but leave qualifiers open
[15:27] <Amy_> yes, that's what I remember, too
[15:27] <spotvin> And the new namespace would go into a separate registry?
[15:27] <spotvin> Yes, I think that was mdiggory's suggestion in JIRA
[15:27] <MWalsh> the issue of non-standard gets at the metadata solutions for features
[15:28] <tdonohue> related to "lock down", I know the committers have been talking for a while (years?) about whether we should lock down the *entire* "dc" schema (and make it only DC-standard fields) and suggest people add new fields to a new "local" schema (for local metadata additions)
[15:28] <MWalsh> yes- separte registries
[15:28] <Maura> my concern is how terms metadata will be harvested
[15:29] <Amy_> tdonohue, I think there was some opposition in the survey to locking down dc entirely; doesn't mean it shouldn't happen, but I'm hesitant to do so
[15:30] <spotvin> tdonohue, would locking down include excluding those local qualifiers?
[15:30] <MWalsh> Maura - crosswalks will need to be addressed as well as any hard-coded dc that may be affected.
[15:31] <spotvin> MWalsh, could you give another example of a dc element that needs to be cleaned up?
[15:31] <tdonohue> spotvin: what do you mean by "local qualifiers"? I don't understand the context? I just meant you'd do the following: (a) change the "dc" schema so that only standard DC fields/qualifiers exist in it, (b) lock down the "dc" schema for editing, but allow people to create/modify all other schemas as needed.
[15:32] <spotvin> tdonohue, I mean the homegrown qualifiers (like dc.identifier.madeuplocationschema) that might be added. It seems like these would be relegated to another schema.
[15:32] <spotvin> or, rather, to another registry
[15:33] <MWalsh> local qualifiers are things that are "standard" now in DSpace, as "advisor"
[15:33] <tdonohue> correct, spotvin. The committers have talked about creating a default "local" schema for that purpose. So, you'd add your local fields qualifiers to a "local" schema...e.g. local.identifier.onlinecatalog (or similar)
[15:33] <cwilper> barmintor: I couldn't figure out why the mptstore issue was happening, but did enough manual testing last week and this week that I was satisfied that it's not a blocker. queries such as the one being tested work fine manually. It seems pretty likely that it's a test-related problem. But it'd be nice to get to the bottom of the test issue eventually. Any insight you can muster would be appreciated.
[15:34] <tdonohue> but, you can take my suggestions as just brainstorms... I admittedly am not a metadata expert here.
[15:34] <spotvin> thanks, tdonohue
[15:35] <Amy_> MWalsh, as someone who's dealt with DSpace and metadata on a pretty intense level, what do you think of locking down dc entirely?
[15:38] <MWalsh> For our current model, I do think locking down the element is important. Sharing via simple OAI-PMH is standarized if the standard crosswalk is used, but locking down the schema doesn't lock down the exposure per se
[15:39] <MWalsh> I think that a lot of the localization is due to limitations of the one schema
[15:39] <spotvin> That's interesting, MWalsh. My concern would have been that the local schema items wouldn't be exposing via the simple OAI-PMH.
[15:39] <spotvin> exposed, that is.
[15:40] <Maura> I agree, but would the manager have to create a new schema for each small variation among collections
[15:40] <MWalsh> Until we have other options, I not convinced of locking down the qualifier
[15:41] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) Quit (Quit: mdiggory)
[15:42] <Amy_> so what are the next steps if we're going to move forward with the 'simple' task of bringing the current schema up to date?
[15:43] <MWalsh> I think we need to start with 1.8 ships with and compare with current DCMI
[15:44] <spotvin> I actually have a spreadsheet put together by a metadata librarian that maps the 1.8 ships with and the DCMI (http://dublincore.org/documents/dcmi-terms/)
[15:44] <MWalsh> OK. we can work via email on that
[15:45] <spotvin> My confusion, though, is that beyond the citation example,
[15:45] <spotvin> I'm not really seeing any immediate comparisons that would help clean up a DC element set
[15:46] <MWalsh> tdonohue, how do you see a dc and a local working together, say for item import
[15:47] <Amy_> spotvin, could you send that to us by email, and perhaps give us each a chunk of the sheet to work on?
[15:48] <spotvin> Yes, just sent it
[15:48] <tdonohue> MWalsh... I think it could be possible to "prepopulate" the "local" schema with some general suggested fields that could be already configured to work for item import / OAI harvesting, etc.
[15:48] <Amy_> just got it spotvin, thanks!
[15:49] <tdonohue> I think the most important thing here (from a developers standpoint) is getting some suggestions on how to "clean up" the "dc" schema to make it more standard, and suggestions on other schemas (dcterms, local, etc) that may need to exist & their fields.
[15:49] <MWalsh> tdonohue, do you see a repo using local or a combo of the two
[15:49] <tdonohue> Once we get those suggestions, the developers can try to figure out whether there's a way to make it work (it may require some programming, but hopefully not much)
[15:50] <tdonohue> MWalsh -- you'd use a combo of schemas.. Things that are in standard DC would get saved to "dc" fields...things that are non-standard would get saved to "local" fields
[15:51] <tdonohue> So, many items would have metadata that includes multiple schemas, "dc", "local", possibly "dcterms", etc.
[15:51] <tdonohue> (or at least, that's my brainstorm)
[15:51] <spotvin> Yes, I know in our IR now we have local and thesis registries, so ETDs are likely to have metadata from dc, local, and thesis
[15:52] <Amy_> same here
[15:52] <MWalsh> tdonohue, with the current dc, and what is by default exposed, the element is the standard. Do we want local for a standard element but local qualifier?
[15:55] <tdonohue> MWalsh -- not sure I understand the question...can you give an example of what you mean?
[15:55] <Maura> I don't know how we could cover all the local qualifiers in any one standard
[15:55] <spotvin> tdonohue, I'm also curious about what is default exposed with QDC-- is that standard across DSpace IRs?
[15:56] <MWalsh> The QDC crosswalk is problematic, and I don't think it ships "on"
[15:57] <spotvin> Ah, ok, I've noticed some trouble with the QDC for our IR and wondered whether locking down the dc registry to only include what would go out in QDC could help determine what should be local and what should be dc.
[15:57] <tdonohue> DSpace has a QDC crosswalk for OAI-PMH, but it's not enabled by default (it could be..if we felt the need to enable by default)
[15:57] <MWalsh> tdonohue, current dc had dc.contributor.advisor for example. As discussed above, that would go to local.contributor.advisor, although as simple exposed it is standard dc
[15:58] <tdonohue> The QDC crosswalk is actually controlled by a "QDC.properties" file that actually *maps* many current DIM fields into dcterms...so it could be used as a starting point of sorts: https://github.com/DSpace/DSpace/blob/master/dspace/config/crosswalks/QDC.properties
[15:59] <MWalsh> tdonohue, yes, by not shipping "on" I meant by default it is not enabled
[15:59] <tdonohue> MWalsh -- in terms of "exposure" (via OAI-PMH), we can create custom crosswalks to "map" local.contributor.advisor so that it is exposed as "dc.contributor".
[16:00] <tdonohue> I think it's worth pointing out that we already do a *lot* of mapping of DIM fields to DC/QDC, etc. for exposure. So, changing that default mapping should not really be a big deal
[16:02] <spotvin> This file is very interesting, tdonohue, thanks for sharing it
[16:02] <spotvin> so it looks like dc.contributor.advisor wouldn't be mapped out through QDC, anyways, in the current configuration?
[16:03] <tdonohue> currently yea, it looks like dc.contributor.advisor isn't mapped into QDC by default (it's commented out in that file)
[16:03] <Amy_> right--my metadata people have complained about that before
[16:03] <MWalsh> sptvin, the QDC that ships is still the preliminary mapping made quite a while ago. when no mappings were found they were left out
[16:04] <spotvin> Ah, so interesting. thanks.
[16:04] <spotvin> so maybe we should also update the QDC that ships ;)
[16:04] <MWalsh> local IRs have more work with tha crosswalk than others for use
[16:04] <tdonohue> In general, I think the committers/developers just need some suggestions on how to "clean up" our metadata schemas, and whether there are ways we need to *change* what is exposed via OAI-PMH. None of us are metadata experts -- we know there are likely issues currently, we just don't know what all those issues may be
[16:05] <tdonohue> so, if you could pull together suggestions on a wiki page or JIRA ticket, I think we'd be very willing to make them happen
[16:06] <MWalsh> the QDC along with the other mappings will need to be addressed, but the QDC has never been enabled by default due to its 'preliminary' state
[16:06] <MWalsh> I think with the QDC we need to address how we are handling dcterms before we alter the mapping
[16:07] <spotvin> So the current ideas are:
[16:07] <spotvin> 1. clean up the dc registry (the question of lockdown is open)
[16:07] <spotvin> 2. possibly suggest a new dcterms registry
[16:08] <spotvin> (well, I should say that the question of lockdown for qualifiers is open. elements should be locked down)
[16:08] <MWalsh> if we lockdown then I think we need to ship with a local mocked up
[16:09] <spotvin> that makes sense to me
[16:09] <Amy_> +1
[16:09] <spotvin> I am still vague on how a dcterms and dc registry would coexist
[16:09] <spotvin> would the dcterms registry be complete, or only contain items not covered in dc?
[16:09] <spotvin> like dcterms.educationLevel?
[16:10] <Amy_> I think it would need to be complete
[16:10] <MWalsh> if we added a new dcterms namespace we should add a standard dcterms namespace independent of what we are doing in other namespaces, becaseu we want to go in that direction, adding otehr namespaces as well
[16:10] <tdonohue> Not to add to the list, but the one other thing that was implied in the above discussion is "possibly determining if there are other often-used schemas (e.g. "thesis" or "etd" schema) that DSpace should ship with"
[16:11] <spotvin> yes, there is a standard ETD schema (thesis.x.x) that we could recommend
[16:11] <spotvin> that would be a huge deal for that community
[16:12] <spotvin> maybe we could consider that when thinking about what local mocked up items to include
[16:12] <spotvin> I am happy to work on the thesis question, since I am neck-deep in that work for my own IR
[16:13] <spotvin> but it seems like a big question in terms of other schema...
[16:13] <MWalsh> If we add on now to what we are doing by adding additional namespaces, I would want to not add rthem to local, but add standard namespaces
[16:13] <tdonohue> yea, I think figuring out a thesis schema would be great...it's actually been in our JIRA for some time (and we just need some suggestions): https://jira.duraspace.org/browse/DS-531
[16:14] <spotvin> yes, I agree MWalsh
[16:14] <Amy_> sorry to bail, but I need to run to my next meeting. spotvin, Maura and/or MWalsh would you send an email and let me know what you need me to do next?
[16:14] <spotvin> yes!
[16:14] <Amy_> thanks, all!
[16:14] <tdonohue> MWalsh -- correct. I would not want to shove a bunch of stuff into a "local" schema. Instead, the Thesis fields should be in their own schema (e.g. "thesis")
[16:14] <MWalsh> ok. we will email
[16:14] * Amy_ (80cea088@gateway/web/freenode/ip.128.206.160.136) Quit (Quit: Page closed)
[16:15] <spotvin> MWalsh and Maura, would a good next step be to divide and conquer using the spreadsheet I sent out
[16:15] <spotvin> to consider what a cleaned up dc and new dcterms registry would look like?
[16:16] <Maura> I am happy to take half the spreadsheet
[16:16] * MWalsh (8092add0@gateway/web/freenode/ip.128.146.173.208) has left #duraspace
[16:17] <spotvin> Thanks, Maura
[16:17] <spotvin> let's hash out next steps over email
[16:17] <spotvin> tdonohue, thanks so much for your help
[16:18] <Maura> I see Maureen left. I also have a meeting, so let's email
[16:18] <spotvin> are you going to be at this curation conference in Atlanta in August?
[16:18] <tdonohue> you're more than welcome!
[16:18] <spotvin> ok. bye, Maura!
[16:18] * Maura (80c1a3fa@gateway/web/freenode/ip.128.193.163.250) Quit (Quit: Page closed)
[16:18] <spotvin> tdonohue, yes, very helpful to have that clarification about QDC OAI-PMH, as well, that's something that has been bothering me
[16:19] <spotvin> bye!
[16:19] * spotvin (80c25750@gateway/web/freenode/ip.128.194.87.80) Quit (Quit: Page closed)
[16:47] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:16] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:36] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:03] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Quit: Leaving.)
[21:30] * barmintor is now known as barmintor_afk
[22:19] * barmintor_afk_ (~ba2213@franklin.cul.columbia.edu) has joined #duraspace
[22:20] * barmintor_afk (~ba2213@franklin.cul.columbia.edu) Quit (Read error: Connection reset by peer)
[22:20] * barmintor_afk_ is now known as barmintor_afk
[22:27] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.