Page History

...

Minutes

Amy

Sarah Potvin

Sarah Malloy

Bram

Maureen

Jim

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

Ships with 4: QDC, existing, local and DCTerms, ETC

Jim: 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

Maureen: 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

Insert – after dis with develpers, before final proposal to community

Need Would like someone with DCTerm familiarity review the proposal? 

-go through mapping

-comfirming functionality and reqmts around DCTerms

this is what we are prposing for 

QDC – upgrade to current registry – current is DC (“DCMI Terms”) – updateing the existing registry

DCTerms namespace – new parrell registry

Lockdown – migratory tool pulls out all local – and pushes into new local schema and lock everything else down;  make it not easy, but possible

Val to set mtg time w/developers

1) Good discussion last month in DCAT mtg, but not much of an asynchronous follow up discussion - how can we best move this forward?Minutes

• • Amy: need to chat with cmtrs about limitations
  • Maureen: need more clarity of what direction we should go before taking w/cmtrs
  • Proposed process
    
    • 1) draft a proposal on updating DC from DC sub-team (Sarah P., Amy, Maureen, Maura)  - 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 
        • identify what specifically DSpace DC should be updated to - QDC vs DCTerms 
      • User Modifications: identify what if any 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 
    • 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

Actions Items from this meeting

...