Date
- Tuesday, June 3, 2014
Time
- 10:00am Eastern/14:00 UTC
Dial-in
We will use the international conference call dial-in. Please follow directions below.
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial in #
- Once on the call, enter participant code 2257295
Attendees
- xBram Luyten (@mire) - @mire
- xElin Stangeland - University of Oslo
- xSarah Potvin - Texas A&M University
- xValorie Hollister - DuraSpace
- Pedro?
- Sue Kunda
Discussion Items
Time | Item | Who |
|---|---|---|
| 40 min | 1) Metadata Panel at OR14 | All |
| 20 min | 2) DCAT Charge | All |
Discussion Notes
1) Structure of the panel
goal - see what problems people care about - what should we be tackling with metadata project
- 5 min: introduction highlight WHO?
- what the work has looked like so far - update dublin core stds in DSpace - seems like an abitrary or narrow task; actuality in looking at how DC stds have evolved looking at more complex metadata needs in the community
- started in Austin committer mtg - commttters wanted to align DSpace dublin core with current std
- part of the goal is to broaden discussion w/community
- metadata std not performing the way we want it to
- as we look at D6 look more at our reqmts
- challenge aroudn flexibity:
- 1) ingest (material in diff std, need to map so fields import correctly)
- 2) crosswalks for exports - for harvesting or other purposes - metadata should be flex enought
- 3) what you want to do w/in your own dspace - how easy is it to manage local needs - separate from import/export needs
- point out problems
- not just stdardize to current dublin core
- adding new metadata standards
- clean ingests / or exporting - if funders have asked for clean ingests / harvesting - more plug and play / easy to use
- getting data in and out is very important for CRIS - ORCHID - ecosystem is much more complex - need to coordinate metadata on national level
- dspace was built to be metadata agnostic - some fields are hard coded - like date
- creating CRIS friendly metadata - creating separate namespace
- creating custom fields - requires you to login to XML in order to do so or sometimes a Java programer to do and rebuild
- why we are having panel, what we want to get out of it
- validate ideas/plans - not missing a reqmt from the community or reqmt by external standards
- 3 min or less each: each panelist present backgrounds and views
- specific examples of current challenges and some approaches/solutions
- summary of problems all dealing with
- set up to explain background - how and why we are invovled in this panel - show audience which person they might most closely relate to
- subtheme: how you have hacked dspace metadata has been hacked? what should be taken in consideration with future DSpace - so that you don't lose your local customization*
- what mistakes have you made with DSpace metadata - what are the implications of workrounds (address an unmet need)
- what would you prefer to do differently
- workarounds for metadata: what/how far have you stretched the metadata in DSpace
- discussion - list of issues - strawman of biggest issues that need to be addressed
- Pedro - adapting DSpace to meet OpenAIRE reqmts
- exporting metadata to diff schemas DC to METS
- doing metadata better for DSpace -
- clean importing /exporting / harvesting
- linked data
- Discussion: a few topic prompts to guide discussion
- how does this plan sync up or create conflicts with your current work?
- linked data - what benefits are there in linked data?
- how to serve common use cases - as everyone repositories evolve?
- how have people hacked DSpace to get it to do what they want - make sure current plan addresses some of those needs
- linking articles and journals in DSpace, ability to define relationships
- CRIS heiararchal metadata needs to be flattened in order to bring into DSpace
- what are the priorities and more imminent problems to tackle
Notes on Metadata Panel from April 30 discussion
1) A few questions that could fuel our agenda:
- have about 1 hour for the panel: https://www.conftool.com/or2014/index.php?page=browseSessions&form_date=2014-06-13
- need 4 or 5 panelists - shot for 5
- Sarah Potvin
- Elin
- Bram
- someone representing large harvesting initiative: OpenAir, SHARE, someone from Fedora linked data or EPrints, RIOXX, Eurpeaona, Metadata For All (Bram)
- Elin to get list of attendees to see if there is anyone who could be invited to participate
- Stephanie will check to see if there is anyone from Dublin Core community Jykha Jakula
- session moderator: Val
2) Structure of the panel
- 10-15 min: introduction highlight why we are having panel, what we want to get out of it
- validate ideas/plans - not missing a reqmt from the community or reqmt by external standards
- 5 min or less each: each panelist present backgrounds and views
- Discussion: a few topic prompts to guide discussion
- how does this plan sync up or create conflicts with your current work?
- linked data - what benefits are there in linked data?
- how to serve common use cases - as everyone repositories evolve? how have people hacked DSpace to get it to do what they want - make sure current plan addresses some of those needs
- linking articles and journals in DSpace, ability to define relationships
- CRIS heiararchal metadata needs to be flattened in order to bring into DSpace
- what are the priorities and more imminent problems to tackle
3) Meet at OR beforehand to talk through panel
4) Other ideas from Bram
I think it would be nice if we may be able to present a few opposing opinions on the three topics, and see how the audience reacts. e.g.
A new look at supporting and safeguarding standards
Someone who's highly in favor of doing a full migration to dcterms vs someone who presents the idea of a mixed approach where we keep some free text fields like dc.title.
Or someone who's in favor of adding custom/institution specific fields vs someone in favor of reusing external schema's like RIOXX or UKETD
Metadata for all: Maybe there's someone who wants to make a case for treating other dspace objects (coll, comms, bitstreams) differently when it comes to metadata?
Future proofing
Opposing/different opinions on what the priorities should be?
What do you think? would this make sense? How can we ensure that we "dumb it down" enough so that it appeals and affects the audience the most.
Action Items
- Meet at OR beforehand to talk through panel
