Page History

Attendees

Bram Luyten - @mire

Amy Lana - University of Missouri

...

Maureen Walsh - The Ohio State University

Sarah Molloy - Queen Mary, University of London

Sarah Potvin - Texas A&M University

Valorie Hollister - DuraSpace

Time

• 11:00am Eastern/16:00 UTC

...

...

Discussion Notes

Key points during the discussion:

Bram: Update to DCTerms and DCMI compliance ultimate goal – linked data compliance 

Jim: agree – concrete goal to have positive effect on user experience. There are a lot of stds to chose from – need to pick what is useful to end users of DSpace – more likely to influence how people use DSpace in the end – goal of having DSpace work better with linked data – need goals to broaden a bit – look at end result rather than just chosing a std

Maureen

: if goal is better user experience – DCTERMS – how do we do that w/DSpace - incremental step DCTERMS namespace as interium step (due to limitations of data model – has to be 2 steps) cannot assign ranges to values

: want to be moving in a future dir – not QDC – clean up QDC (admin fields, customized fields) and add DCTERMS namespace and eventually move to 

Amy

: ship DSpace with local registry and admin registry (more actionable, intergral to operation to DSpace)

: not much diff between updating QDC and flat DCTerms in terms of initial functionality

Maureen : add DCTerms namespace, DSpace would ship with 4 metadata schemas: QDC, existing/local and DCTerms

Jim: need to provide tools to migrate

Maureen

: more admin help on how to add metadata schema (how to do batch loading, cross walk – need cookbook for other (local) schemas)

: more attention to metadata fields are used for new features – more attn on if it is appropriate to chose (like emabargoo, new rss feeds) – how are we using metadata field to implement features – new feature is hinged on specific metadata field

--need to review what field new features use

--DC is assumed in a lot of places – be aware where the impact

--ex: item view page – dc.authors or dc.title – defined on item view page – need to discover where dc is hard coded – need to root it out

: need an update tool to update (oeverlay old) registry to new QDC,  DCTerms

Bram

: need cookbooks for 2 main user case: both new users and updating users

: why: importing/exporting metadata is ever increasing – if we aren’t compliant from the harvest to/from – migrations become more challenging

Jim: funding sources are requiring more of the use and re-use of data – linked metadata is important evolotion

Sarah

: would like someone with DCTerms familiarity review the proposal - Maureen offered 

: go through mapping

: confirming functionality and reqmts around DCTerms

Summary of DCAT proposal:

1) update/upgrade current QDC registry (current is DC/“DCMI Terms”

2) add DCTerms namespace – new parellel registry

3) Lockdown registries: offer migratory tool to pull out all local customizations, push into new local schema and lock everything else down;  make it possible, but not easy to change QDC and DCTerms

Review of next steps:

1) finalize draft a proposal on updating DC following DCAT feedback (DCAT sub-team:

...

Sarah P., Amy, Maureen, Maura)

• • identify main goal (why is it important/why should it be done) and
 - identify
• • key areas to address for the update
,
• • identify proposed direction forward along with the benefits/drawbacks/outstanding questions for cmtrs
and DCAT, should include:
Goal of update:
identify goal for the update - why is it important/why should it be done 
• • (and community)
  • identify what specifically DSpace DC should be updated to - QDC
vs
• • and flat DCTerms 
User Modifications:
• • identify what if any user modifications will be allowed 
Migration / Implementation:
• • identify any areas/processes that will be affected (forms, imports/exports, etc.)
• Other areas?
• 2) hold targeted DCAT discussion - for December DCAT mtg have targeted discussion about the proposal - validating / revising DC sub-team's proposal - Val to poll DCAT to see if everyone is available on Dec 18 or if we need to re-schedule
3) revise proposal based on DCAT discussion 
• • and path for migration / implementation

4) discuss proposal with developers/cmtrs to understand limitations/pain points

5) revise proposal based on developer/cmtrs feedback

6) hold discussion / allow for feedback on proposal by DSpace community - and maybe the broader repository community

4) JIRA workflow improvements

• useful improvements that should make it easier to understand what needs to be done on JIRA issues
• more tweaks coming before implementing - more feedback welcomed (email Tim) - will discuss in detail at a later point

5) Topic for developer overlap mtg

• too early for DC discussion 
• priority for developers on 3.0 release, forgo overlap for Oct and possibly Nov unless something comes up

6) Topic for Thurs/Fri discussion

• nothing identified
• Val to contact each DCAT discussion leader to identify status on their issues on the DCAT Discussion Schedule

Val to set mtg time w/developers

Actions Items from this meeting