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?
