Community Acceptance Plan
From DigiRepWiki
This document is a DRAFT.
|
[ Home | Functional Requirements | Application Model | Application Profile | Community Acceptance Plan | Mapping to Simple DC | XML Format |
Scholarly Works Application Profile Community Take-Up and Acceptance Plan
This is a plan for community take-up and acceptance of the SWAP. It outlines a deployment path for implementation and take-up, including requirements for developers, repositories and service providers. Recommendations for further community engagement and future maintenance of the Scholarly Works Application Profile are also included.
Uptake and deployment of the Scholarly Works Application Profile should be driven by the user community, i.e. the repositories wishing to expose metadata and services wishing to consume it, and by the wider stakeholder community, including JISC and other funding bodies.
Background and scope
The background rationale for the Application Profile can be found in the Eprints Application Profile home page. The scope is detailed in the Functional Requirements document.
Stakeholders and designated community
Stakeholders and the designated community for this Application Profile are outlined in the Functional Requirements document.
Maintenance and responsibility
The current instantiation of Eprints Application Profile work was signed-off at in early September. This work has been coordinated by Julie Allinson, Digital Repositories Support team, UKOLN, and Andy Powell, Eduserv Foundation.
During the period May - July 2006, several documents have been produced to support the Application Profile.
- To ensure the Profile is embedded into repository practice in the UK and its currency maintained, it is recommended that JISC appoint an agency to maintain the profile.
- It is recommended that UKOLN, through the Digital Repositories Support team within whose remit the work currently falls, take on responsibility for maintaining the Profile.
- It is recommended that UKOLN register the DCAP with the prototype JISC IE Metadata Schema Registry.
- It is recommended that UKOLN take on responsibility for maintaining the new terms that have been created for use in the Profile, and for ensuring that descriptions of those terms are made available in accordance with current good practice guidelines
- Dissemination and community liaison would form part of this responsibility.
Substantive changes to the Profile would be out of scope for this maintenance activity, although UKOLN would be well-placed to alert JISC to additional work needed.
Community engagement plan
May - July 2006
As part of the Eprints Application Profile activity (May - June 2006), several community engagement activities have been undertaken, including:
- A Working Group was assembled to work on the Profile, including representatives of DCMI, the Digital Repositories Programme, Intute, Sherpa, AHDS, eprints, DSpace and Fedora.
- A wider Feedback Group invited comments from representatives of European projects, FRBR and other experts from the community.
- The eprints-application-profile@jiscmail.ac.uk mailing list was established to facilitate discussion across the working group and feedback group.
- The JISC Digital Repositories Programme wiki (http://www.ukoln.ac.uk/repositories/digirep/) was used for the development of all documents produced. At all stages, documents have been publicly available.
- Emails to relevant lists (dc-libraries@jiscmail.ac.uk, jisc-repositories@jiscmail.ac.uk) have alerted the community to the work. Several responses to these e-mail messages have provided additional members to the feedback group.
- Dissemination of the Profile has been undertaken wherever opportunities have arisen, in presentations, ah-hoc discussions and via jiscmail e-mail lists.
- for example Andy Powell and Julie Allinson have referenced this work in presentations at the JISC-CNI Conference, the Institutional Web Managers Workshop and the Intute UK repository search meeting.
August 2006 and beyond
As the activities of these groups are wound-down, the following recommendations for continuing and extending the level of community engagement achieved are proposed:
- Consider establishing a DCMI working group following on from the eprints workshop at the Dublin Core conference in October 2006. Roll the eprints-application-profile jiscmail list into a dc- list.
- (alternatively, if a DCMI WG is not established, invite the small feedback community established for the current work to maintain their membership to the eprints-application-profile mailing list; widen the membership of this list by inviting additional community representatives to join)
- open the membership of the working group and list to a wider audience, encouraging community discussion of issues raised by deployment of the profile.
- JISC Programme Managers disseminate the Profile
- Recommendations for use of the Profile should be built into future funding calls under the JISC Capital Programme to encourage uptake.
- Extend the work of the feedback group (unfunded) into a dissemination and feedback period (August - October 2006). Work to include the following:
- workshop at DC 2006
- general awareness-raising through posts to email lists, f2f discussions etc.
- original working group and feedback group members encouraged to continue ad-hoc dissemination
- Host a community engagement event (funded from existing budget) in September or October
- this would replace the proposed second working group meeting
- UKOLN will register the DCAP with the prototype JISC IE Metadata Schema Registry.
Deployment plan
In order to implement the Eprints Application Profile, the following deployment stages are anticipated:
Note: This is dependent, in part, on the availability of the Dublin Core XML/RDF schemas (see A note about XML)
Software developers:
- Initially, developers of DSpace, Fedora and Eprints create an add-on or plug-in to enable repositories to create and expose eprints-compliant metadata records. Roll-out as part of core future releases should be factored into development activities, as necessary.
- It is recommended that discussions with developers are held to agree development path. Initially, this should be limited to developers of commonly-deployed open-source repository software (see Responses from developers):
- DSpace, contact through Jim Downing and the DSpace UK User Group
- Fedora, contact through Chris Awre and the Fedora UK and Ireland User Group
- Eprints.org, contact through Chris Gutteridge, Jessie Hey and the Eprints Community.
Commercial suppliers should be engaged later in the process.
Repositories:
- Institutional (and other) repositories upgrade their repository software with the new plug-in or patch.
- Institutional repositories to test the profile, review current local metadata practices, make changes to metadata captured from the user and undertake any global editing or re-mapping of current content in order to comply with the eprints application profile.
- It is recommended that some early adopters are engaged to test the profile.
- It is recommended that any necessary (minor) revisions are incorporated; requirements for major revisions should be communicated to JISC
Aggregators/Service Providers:
- The Intute (ePrints UK) OAI-PMH harvester configured to harvest records compliant with the eprints application profile and related software modified to take advantage of the richer metadata contained therein.
- Other OAI-PMH harvesters (e.g. Southampton and EDINA) encouraged to do likewise.
- It is recommended that Aggregators/Service Providers recommend the exposure, by repositories, of metadata records compliant with the eprints application profile.
- It is recommended that JISC (and other funding bodies) recommend compliance, particularly through future funding calls.
Responses from developers
The following developers and service providers are considered to be key stakeholders for implementation. Repositories using other software or in-house development should be encouraged to adopt the Profile, using the community engagement mechanisms listed above. Successful uptake by the key stakeholders should encourage wider uptake.
Developers
- Eprints.org
- DSpace
- Fedora / VITAL
Service Providers
- Intute (and UKOLN)
- EDINA
DSpace
From Jim Downing:
The upcoming release of DSpace (1.4) has extensible metadata support, and the current production release has a technology to customize the forms in the ingest process, so in theory it should be possible for someone to create an add-on to support the JISC application profile. I'll go back to the software to check that this would work.
There's definitely an issue for the installed base in the UK - many installations don't upgrade for quite some time after a version is released. This would be an extra incentive though!
I think that this wouldn't be appropriate for inclusion in the core DSpace release. We're encouraging the development of this kind of functionality as add-ons, and there's a mechanism for adding them to a 1.4 DSpace source distribution. In practical terms, what this really means is that the JISC ePrints application profile will have to provide for it's own maintenance and distribution.
As far as harvesting exposure goes, then it would be straightforward to add an eprints feed alongside the current dumbed down feed.
EPrints
Christopher Gutteridge writes:
We intend that EPrints version 3 (coming soon!) will support the profile out of the box for both export and OAI.
If sites wish to support the profile before the upgrade to EPrints 3, we will provide a "how to" to add the profile to the EPrints 2 OAI interface.
Fedora
From Chris Awre:
Fedora as a system will not, as I understand it, have a problem implementing the profile, as the metadata structures and datastreams you can establish are flexible. It is on the harvesting side that I am unsure currently and where I will seek clarification. Fedora does allow OAI harvesting of DC metadata, but the documentation does not make it clear whether this is limited to simple DC or whether qualified DC would also count. I suspect not, and that an extension of what can be harvested will be needed. Having said that, this issue of only being able to harvest DC has been raised already and the Fedora team are working on a broader service that should allow multiple metadata datastreams to be harvestable, which would cover the eprints profile.
In summary, Fedora itself should have no problems working with the e-prints profile so long as the repository owner has set up the appropriate datastream. Such a datastream won't be pre-set as none are in Fedora (except a basic simple DC one for internal management purposes) so this would require some work on behalf of individual repositories. However, since Fedora adopters accept that they have to create all the different datastreams they need this should not be an issue. As regards harvesting, any individual datastream can now be harvested from Fedora. As such, if the e-prints profile datastream has been configured it can be set up as the one to be harvested.
Both VTLS and Fez have indicated they also do not see a problem working with the profile. I have directed both camps to the profile wiki, though, so they can take a more detailed look and I am awaiting feedback from this.
On the whole, then, it looks like the Fedora community will be able to work with the e-prints profile.
VTLS
From Carl Grant:
Thanks for sending this and I'm pleased to tell you that after a preliminary review, we see no problems with this approach. In fact, we find it very consistent with some design work we had been doing.
Intute
From Linda Kerr and Phil Cross, Intute:
Community acceptance of a standard ePrints Application Profile, based on DC, was identified in the eprints UK project final report as necessary for repository aggregators to reliably access the full-text of open access documents. Its wide implementation and use would therefore be beneficial to a UK Repository Search Service that seeks to provide added-value services based in part on data mining techniques requiring access to full-text documents. In addition, the extra richness of the ePrints Application Profile, together with its extensibility, will enable further added-value services not yet envisaged. (The first stage of the UK Repository Search Service project will determine what extra value-added services we will investigate, together with the implications for metadata collection these will have). The international adoption of the profile would improve resource discovery and metadata sharing between aggregating services further.
Adoption of the metadata standard by repository software developers in a way which would help users add appropriate metadata to their publications, automating as much of the process as possible, will be essential to providing high quality metadata across the different platforms available. It will also be necessary for repository administrators to be able to add the application profile as an option for exporting metadata (via the OAI-PMH protocol for our project) as easily as possible, and ideally via simple plugins that could be downloaded from the Search Service web site. These are clearly implications for how well the application profile fits with the data models used by the major eprint repository developers.
Edina
{to be added}
Internationalisation
The current activity has taken a UK-focussed approach to specifying an application profile. Where available, application profiles for international projects and services have been considered (see Functional Requirements) and international representatives invited to join the feedback group.
- Establishing a DCMI Working Group would promote international uptake and consultation.
A note about XML
The current Scholarly Works Application Profile hasn't committed to delivering XML schemas. The Profile is dependent on the revised guidelines for expressing Dublin Core metadata in XML and in RDF. These documents are currently being considered by the DCMI Usage Board prior to the October conference.
- Recommendation: {to be added}
Areas for future work
Discussions on the eprints-application-profile mailing list have highlighted the following areas for future work:
- Auto-extraction of metadata
- Automatic classification techniques
- Tracking metadata records through intermediate hosts
- Extending the profile for other types of Scholarly Works, e.g. aggregations of eprints (journal issues, overlay journals), non-text scholarly output (e.g. those listed in RAE description). It is hoped that JISC funding in the area of application profile development will cover some of these and that, in so doing, JISC will take a lead in ensuring that approaches are consistent.
- The use of service registries and other shared services, e.g. terminology services, identifier services, profiling services etc.
- more ...
