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
...
...
- )
...
in the context of the DCAT work on metadata, we thought it would be a useful first step if DSpace 4 would include DCTerms out of the box, without enforcing its use just yet.
...
- , 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.
...
...
...
...
JIRA: https://jira.duraspace.org/browse/DS-433
- 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?
2) Discussion of project phasing
- proposal as written - passing through QDC before moving to DC Terms
- straight to DC Terms
Certainly to be discussed tomorrow, but I think with Richard's mapper and a standard DCTerms schema in place in 4.0, a whole year of ramp up to 5.0 should be enough to start taking care of a bigger shift towards DCTerms adoption. E.g. something like we have envisioned as the DSpace 6 situation in
https://wiki.duraspace.org/display/DSPACE/Proposed+phased+schemas
cheers
Bram
What could we get into 4.0? pull request by Oct 7, all work doesn't need to be finished but some kind of code needs to be in
- Richard tool and prelimary mapping - need to test
- should we add DC terms as an extra registry, but would have no OAI done for it
- should we admin schema
- --> not enough time, should really have some documentation to accompany/describe
Next steps - review groups - recruit specific people to get involved
1) feedback on all mappings
- dc terms mapping - need DC experts
- update dc
- admin - need dev expertise
- local
2) feedback on project staging