Timestamps are in GMT/BST.
[5:48] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[6:21] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[6:21] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[6:21] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[6:24] * eddies1 (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[6:24] * eddies (~eddies@unaffiliated/eddies) Quit (Read error: Connection reset by peer)
[6:24] * eddies1 (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[6:24] * eddies1 (~eddies@unaffiliated/eddies) has joined #duraspace
[6:45] -hubbard.freenode.net- *** Looking up your hostname...
[6:45] -hubbard.freenode.net- *** Checking Ident
[6:45] -hubbard.freenode.net- *** Found your hostname
[6:45] -hubbard.freenode.net- *** No Ident response
[6:45] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:45] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:45] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:29] * eddies1 (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[8:30] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[8:30] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[8:30] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[10:52] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[11:50] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[11:53] * eddies (~eddies@43.202-63-155.unknown.qala.com.sg) has joined #duraspace
[11:53] * eddies (~eddies@43.202-63-155.unknown.qala.com.sg) Quit (Changing host)
[11:53] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[11:59] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:03] * eddies (~eddies@bb116-14-159-229.singnet.com.sg) has joined #duraspace
[12:03] * eddies (~eddies@bb116-14-159-229.singnet.com.sg) Quit (Changing host)
[12:03] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:07] * eddies1 (~eddies@bb116-14-159-229.singnet.com.sg) has joined #duraspace
[12:07] * eddies1 (~eddies@bb116-14-159-229.singnet.com.sg) Quit (Changing host)
[12:07] * eddies1 (~eddies@unaffiliated/eddies) has joined #duraspace
[12:08] * eddies (~eddies@unaffiliated/eddies) Quit (Read error: Connection reset by peer)
[12:17] * eddies1 (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:21] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[12:21] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[12:21] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:25] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:02] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:12] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[13:14] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[13:16] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Client Quit)
[13:17] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[17:04] * PeterDietz (~peterdiet@dhcp-140-254-207-88.osuwireless.ohio-state.edu) has joined #duraspace
[17:18] * hpottinger (~hpottinge@161.130.252.93) has joined #duraspace
[17:40] * hpottinger (~hpottinge@161.130.252.93) Quit (Quit: Later, taterz!)
[17:51] * PeterDietz (~peterdiet@dhcp-140-254-207-88.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[17:58] * PeterDietz (~peterdiet@dhcp-140-254-207-88.osuwireless.ohio-state.edu) has joined #duraspace
[18:18] * PeterDietz (~peterdiet@dhcp-140-254-207-88.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[18:18] * PeterDietz (~peterdiet@dhcp-140-254-207-88.osuwireless.ohio-state.edu) has joined #duraspace
[18:23] * PeterDietz (~peterdiet@dhcp-140-254-207-88.osuwireless.ohio-state.edu) Quit (Ping timeout: 260 seconds)
[18:30] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[18:35] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[18:35] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[18:35] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[18:45] * PeterDietz (~peterdiet@d60-65-80-138.col.wideopenwest.com) has joined #duraspace
[20:09] * bram-atmire (~bram@94-225-36-191.access.telenet.be) has joined #duraspace
[20:10] <bram-atmire> Hi
[20:26] <PeterDietz> hi bram-atmire
[20:29] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:30] <PeterDietz> I would say to use DC schema as default untouched. Then have local people use local fields for custom. To also have a DSPACE schema, for any system generated/expected metadata things
[20:36] <bram-atmire> right
[20:37] <bram-atmire> "touching" the schema: adding/removing/modifying the scope of Elements, right?
[20:39] <bram-atmire> e.g. adding a qualifier doesn't necessarily touch/break the schema
[20:39] <bram-atmire> http://dublincore.org/documents/usageguide/qualifiers.shtml
[20:39] <bram-atmire> Implementors may deploy the qualifiers on these lists with confidence that they conform to the Dumb-Down Principle, and are encouraged to use these qualifiers as examples to guide development of local qualifiers for Dublin Core metadata elements.
[20:43] <bram-atmire> https://wiki.duraspace.org/display/DSPACE/proposal+for+metadata+enhancement
[20:45] <bram-atmire> (just pasting this because it was mentioned on the call)
[20:45] <PeterDietz> i'm not understanding the business value / the "why", of why this change to metadata is worth it. i.e what is it your not able to express currently.
[20:45] <PeterDietz> I'm not understanding the dc.subject.lcsh part
[20:46] <helix84> PeterDietz: one thing that we don't have but DCTERMS have is schema. think of it as data type - restrict range, enumerate the vocabulary for a field
[20:47] <helix84> but yea, i didn't understand the subject part, either
[20:50] <PeterDietz> so flat compared to nested xml was mentioned.. I'm guessing this allows for relationships between metadata. or do they just want more default fields...
[20:52] <PeterDietz> so i see dc/terms/isFormatOf that would be good on a bitstream. To say scan1.tiff.png isFormatOf scan1.tiff bitstream
[20:52] <PeterDietz> but that demands relationships between objects
[20:58] <PeterDietz> Main goal of these recommendations
[20:58] <PeterDietz> The ultimate goal of these recommendations is to implement fully functional DCTERMS as the default metadata schema, thus ensuring compliance with current standards endorsed by DCMI and linked data capabilities, and enabling a metadata infrastructure that supports other hierarchical and relational data structures.
[20:58] <PeterDietz> These recommendations also provide for intermediate steps towards this ultimate goal.
[20:58] <PeterDietz> By bringing the existing default 'dc' schema into compliance with the Qualified Dublin Core standard, we provide an intermediate migration step, enabling repositories to meet compliance with QDC upon upgrade, which will ease the transition to DCTERMS. (See "Possible Phases of Update," below, for further details about staging.)
[20:58] <PeterDietz> By locking down schemas (at least at the element level), we ensure compliance with QDC and DCTERMS standards but provide tools to allow customizations not compliant with QDC/DCTERMS to persist in local schema.
[21:03] <PeterDietz> i was just in an agile training session. So i need user stories, with acceptance criteria for this to be implemented
[21:06] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:07] <bram-atmire> Trying to think about a concrete user story
[21:09] <bram-atmire> Some institutions here are confronted with more strict compliance requirements when it comes to offering up their content for harvesting
[21:09] <bram-atmire> for example the OpenAIRE guidelines or RIOXX in the UK
[21:10] <bram-atmire> http://www.rioxx.net/v0-9/
[21:10] <bram-atmire> the problem is not that DSpace puts things really horribly wrong, or that some default crosswalks somehow prevent compliance
[21:10] <bram-atmire> however, the admin UI makes it so easy to mess with the DC Schema
[21:11] <bram-atmire> that some repository managers might have made some wrong decisions in the past, that now put the institution is a really hard, non compliant position when it comes to harvesting
[21:12] <bram-atmire> So the key to the proposal (for new instances) is to prevent this with the lockdown
[21:12] <bram-atmire> of the standard schemas
[21:13] <bram-atmire> and going further, if they are really getting to DCTerms with the ranges & domains, we could imply more strict validation requirements on what's actually inside the fields
[21:13] <bram-atmire> but one of the challenges I see is that if one institution really has a big problem with metadata consistency or a "mess from the past"
[21:13] <bram-atmire> like, if it's REALLY a problem
[21:14] <bram-atmire> they will have addressed it in another way, and they won't be sitting around for these future DSpace innovations in order to solve this
[21:14] <bram-atmire> So they might have gone in already and done some of the cleanup themselves with lots of manual labor and tears
[21:16] <helix84> I just want to say that the new OAI interface makes it rather easy to deal with "mess" in metadata by allowing one to create a different "view" of the schema visible via OAI-PMH. That is not to say that I'd recommend that approach over cleaning up the schema itself.
[21:17] <bram-atmire> I tend to agree:
[21:17] <bram-atmire> Ingest - internal representation - Export are three different ballparks
[21:18] <bram-atmire> actually, if you have good support for a wide range of ingest formats, and a wide range of export formats
[21:18] <bram-atmire> and the metadata is consistent
[21:18] <bram-atmire> than it suddenly becomes much less of a deal what the internal representation is
[21:19] <helix84> well put
[21:19] <bram-atmire> I also think some of the metadata schema field descriptions need a real brush up
[21:19] <bram-atmire> for example:
[21:19] <bram-atmire> dc.source Do not use; only for harvested metadata.
[21:20] <helix84> we can do that right away
[21:20] <bram-atmire> and all of the different dc.date variants we have in there
[21:21] <bram-atmire> created, accessioned, available etc
[21:21] <bram-atmire> I always need to look this up to know which of them comes with which implication in the code
[21:21] <bram-atmire> or this one: 68 dc.description.version The Peer Reviewed status of an item
[21:21] <bram-atmire> the metadata schema doesn't tell you that this is required/added because of the SWORD functionality
[21:22] <helix84> Bram, regarding the descriptions, I would encourage you to go ahead and change them as soon as you can determine what they currently mean
[21:26] <bram-atmire> this is the place where to do it, right? https://github.com/DSpace/DSpace/blob/master/dspace/config/registries/dublin-core-types.xml
[21:27] <bram-atmire> anyway, signing off for tonight ;) cu guys
[21:27] * bram-atmire (~bram@94-225-36-191.access.telenet.be) Quit (Quit: bram-atmire)
[21:28] <PeterDietz> i'm singing off too
[21:30] * PeterDietz (~peterdiet@d60-65-80-138.col.wideopenwest.com) Quit ()
[21:59] * tdonohue (~tdonohue@c-67-177-111-99.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.