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?
Notes
- Code freeze yesterday
- Dec 4th is final release
- we should describe the addition of DC Terms as being for test purposes and include update scripts in registry
- need to make sure documentation covers change
- new install or upgrade of 4.0 - if you don't touch use it, it won't affect you
- if you want to use it, will need to add it as a local schema - point to documentation for adding local schema
- implications for display issues, item import and OAI harvesting
- Dimitrios' work
- did DC to DC Terms mapping - doesn't seem to impact our project at all
- we need DC Terms for OAI - can't add this now - new DC Terms will not be exposed to OAI - unless OAI for 2.0 included it?
Immediate Actions for 4.0
- Update documentation - DC Terms added for testing purposes, point to current doc for adding local schema if you want to use locally (Bram)
- Check on OAI, see DC Terms schema is included (Maureen)
Project Re-phasing Work
- Revise proposal page
- make old proposal a child of current proposal page as reference point / 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 included, new installs everything defaults to DC Terms
- perhaps 2nd phase could be to create tools to help w/upgrade
- keep metadata flat - if you add hierarchal metadata it complicates the use of DSpacee
- create an application profile or validator to support – so assumptions can be questioned and vetted – makes it easier for people to give feedback on
- create web services query tool (Richard's idea) - to find out how people are using metadata fields - list schemas defined and identify the ones being used
- Start a list of metadata implications for new features – identify what needs to be cleaned up
- like RequestCopy, what metadata to use? dc.requestcopy.email, dc.requestcopy.name – use dspace.requestcopy.email, and dspace.requestcopy.name
- Task & finish groups
- DC mapping
- find DC experts – after re-doing the proposal make list of questions, ask very concrete questions rather than open ended questions
- or, if can't resolve for free, request DSpace Steering Cmte allocate funds for consultants
- On application profile
- Others?
- DC mapping
Next mtg for metadata team on 11/26 at 10am Eastern
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