70 likes | 80 Views
These guidelines provide repository managers with instructions on representing metadata attributes, including funder, project/grant, DOI, related datasets, and rights of use. The guidelines aim to be easy to implement and are part of an ongoing effort to address longer-term guidelines and measures concerns. Implementation work is expected to be completed by the end of the year.
E N D
outline • guidelines for repository managers, building on much previous work, including a report by Sheridan Brown, on how to represent certain metadata attributes • the project is wider than just the guidelines - for example, a certain (modest) amount of software development will be necessary to see the guidelines implementable in deployed repositories • these are interim guidelines - some aspects are expected to be superseded by a CERIF-based approach • this effort will be ongoing beyond these interim guidelines, to address longer-term guidelines and measures
concerns • primary: • how to represent the funder • how to represent the project/grant • secondary: • how to represent the DOI pointing to the item described • provisions of identifier(s) pointing to related dataset(s) • how to represent the rights of use of the item described • this is becoming more of an issue
principles • must be easy to implement, with little/no development required (e.g. a plugin for existing repository platforms) • are interim guidelines, so judgement needed about how future-proof these should be • should respect and even adopt, where viable, existing guidelines • OpenAIRE • EThOS • should seek to avoid being UK-specific, while serving UK goals • should be delivered yesterday.... (guidelines by end of September, implementation work by end of the year).
options for the funder and project/grant • use qualified Dublin Core • dc.relation.projectid for project/grant, containing: • a grant number, or an OpenAIRE compliant string for EU FP7 • dc.contributor.sponsor for the funder name • a string from a controlled vocabulary or an OpenAIRE string • use OpenAIRE 2.0 draft guidelines • either dc.relation.projectid or dc.contributor.sponsor, containing: • Jurisdiction/Funder/FundingProgram/ProjectNumber/ProjectAcronym/ProjectName • use DOIs provide by CrossRef (‘FundRef’): • dc.relation.projectid for project/grant, containing: • a DOI, which resolves to the Funder’s page or possibly GtR, and which offers metadata about funder and grant
how to represent rights • “access level semantics” • which articles are open • what re-use is allowed • embargoes • which articles are OA (flavour) • further study being resourced by the JISC, working with the Publishers and Library Solutions group (PALS) and the JISC’s Open Access Implementation Group.
discussion points (for the breakout?) • can we recommend the OpenAIRE approach? • Jurisdiction/Funder/FundingProgram/ProjectNumber/ProjectAcronym/ProjectName • can we, instead, make this an optional value in a multi-value instance of dc.relation.projectid? • what do people think of the idea of using DOIs (or some other PID) to identify funders and projects? Who maintains the metadata?