1) Discussion of project phases / staging
- as currenly laid out - proposal as written - passing through QDC before moving to DC Terms: Proposed phased schemas
- straight to DC Terms in 5.0, assuming time for full vetting, guidance from DC experts, feedback, documentation, more tool building
2) Discussion on what to include in 4.0 – given project phase discussion what makes sense?
- Bram's proposed addition of dcterms schema to the default install of DSpace (creating an xml file for dspace/config/registries and a small entry in build.xml so the schema gets registered during the installation of DSpace), without enforcing it as a default yet.
- By having the schema available, developers and members of the community can start experimenting changing their input forms, OAI crosswalks – gradually adopting schema.
- Links
- https://github.com/DSpace/DSpace/pull/340
- https://jira.duraspace.org/browse/DS-433
- code changes: https://github.com/bram-atmire/DSpace/commit/58ec299121205bc84e613d3aeaddcc97910f4bb0
- Scope notes from the DCMI definitions here: http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#
- Bram's questions: Does this look appropriate? These scope notes tend to talk about "resources" a lot, while I don't know exactly if "resources" is a term frequently used in DSpace. (usually we say items & bitstreams, so maybe some of these "resource" wording can be changed into "item"?)
- Questions from Ivan:
- How does this PR fit into the stages of metadata schema upgrade as proposed by DCAT?
- What I mean is does this do all that DCAT proposed for 4.0 (for example, I notice this doesn't add the proposed "local" schema)? And what work is planned for 5.0? (6.0?)
- Next steps / what's still possible? Can code still be merged?
- Dimitrios XSL transformation -
- provides exhaustive map of the DSpace AP elements to dcterms (a la the old qdc.properties).
- additional elements are now exported
- language tags are now exported
- map everything under the dcterms namespace (rather than mixing dc with dcterms. See also [1])
- Provide additional LOM mappings to dcterms elements (in case LOM metadata exist)
- assign types to non-literal values
- You can check it out at [2]. We are using this XSLT as the basis for populating the DSpace ontology of our Semantic Search plugin.
- provides exhaustive map of the DSpace AP elements to dcterms (a la the old qdc.properties).
3) Next Steps
- what work needs to be done for 4.0?
- what work is next before setting up review groups?
Notes
Code freeze yesterday
Dec 4th is release - "experimental phase" - schema added for testing purposes, include update scripts in registry, Bram will f/u and make sure documentation covers change, get feedback from anyone in the community (new install or upgrade of 4.0) - if you don't touch use it, it won't affect you
Dimitrios - did DC to DC Terms mapping
We need DC Terms for OAI - can't add this now - not exposed to OAI - not option for OAI (unless OAI for 2.0 included one)? Display issues / item import are no different from any other schema - must be added.
display
item import
OAI
---
doc - for testing purposes, point to current doc for adding local schema if you want to use locally (Bram)
check on OAI for 3.2 see if DC terms is in (Maureen)
---
implications for new features, like RequestCopy, what metadata to use? dc.requestcopy.email, dc.requestcopy.name – use dspace.requestcopy.email, and dspace.requestcopy.name – need to keep running list of what needs to be cleaned up
--
revised proposal - make old one a child (to mtn history), revise proposal page on main page - streamline, focus on standards, don't focus on 'easing' as much, goal for 5.0 is to have everything in
new installs everything deafults to DC Terms, 2nd phase coould be to create tools to help w/upgrade
---
task & finish group - get DC experts, ask very concrete questions rather than open ended questions, after re-doing the proposal make list of questions,
Sarah: does this create a need for hiearchal metadata; Maureen - have to think flatly, it is easier, less complicated
Sarah: do we need application profile or validator to support; Bram: already a default app profile with the req'd fields of title and date; Marueen: app profile is in order, would be good to create a draft application profile so it can be vetted – easier for people to give feedback on
---
tool richard talked about – query service to find out out people are using metadata fields - list schemas defined and identify the ones being used - web svc add on to dspace that could remotely query
task & finsh on project phasing
---
Next mtg for metadata team on 11/26 at 10am Eastern
