Date
Nov 26, 2013
Attendees
Dial-in
We will use the international conference call dial-in. Please follow directions below.
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial in #
- Once on the call, enter participant code 2257295
Discussion Items
| Time | Item | Who | Notes |
|---|
| 5 min | 1) Review proposed agenda - add/change as necessary | Val | |
| 10 min | 2) Opportunity to include anything about recently included dcterms schema and other recommendations in documentation | Bram | |
| 15 min | 3) Non-intrusive approach to modifying hard-coded metadata values via JIRA tickets | | - Identify any hard coded occurrence of a field, make configurable, retain the same initial value. Will allow us to get rid of hard coding while still keeping everyone on same metadata schema for now
- Example JIRA ticket:
- "Remove hard coded references to dc.title"
- Identify all hard coded occurrences of dc.title and replace them with values that can be stored and retrieved from dspace configuration files.
- After all hard coded fields are configurable, repository managers could more easily switch to a new schema by moving all the metadata to the fields in the new schema and changing the configuration.
- Example: after moving every title from dc.title to dcterms.title, the repo manager would only need to do a search & replace on dc.title in a centralized dspace configuration file.
- Could a tool be built for this step?
- Could start project by identifying the kind of tasks for fields that have the most prominent hard coding problems (title, author, dates, url, description...)
- Any problems with this approach?
|
| 25 | 4) Impact of above approach on project phases: | | - Revised proposal as written: Proposed phased schemas
- do project phases change
- list of metadata implications - identify what needs to get cleaned up
- what tools would be helpful
- 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
- how could task & finish / review groups be helpful
- 1) DC mapping: find DC experts – after re-doing the proposal make list of questions, ask very concrete questions rather than open ended question or, if can't resolve for free, request DSpace Steering Cmte allocate funds for consultants
- 2) On application profile
|
| 5 min | 5) Next steps - including next metadata team mtg | | |
Discussion Notes
2) additions to 4.0 docs
-create concise list of fields in docs you can't delete because it affects functionality - either hardcoded or used for admin
-best practices for date field
-Maureen: needs to be in - not sure about whether it belongs on the Metadata Recommendations page
-Bram: could add brief explanation about what the plan is (sep metadata schemas for admin, etc.)
-start list on wiki, with examples, ask for dev and community input, then figure out what we could move to Metadata Rec
-Bram to create JIRA tkt - list of fields that are hardcoded that functionality would be affected, Bram to email metadata team with ?s
-create JIRA tkts to isolate hard coded fields to make them configurable - Bram to start page
-Maureen: include/change field scope notes, DC XML comments "used by system, do not remove"
-date issued field - need scope notes about leaving blank? implications for Discovery - not included in browse indexes
-Monica - negative dates
-Sarah - date ranges
-Maureen: very constrained on what you can put in dc.date,
Previous Action Items
- 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)
- Make old proposal page a child of current proposal page as reference point / to mtn history (Val)
- 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 (Maureen)
- 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 (UNKNOWN)