Use Cases
[NS Use Case]
A researcher is publishing an article with a CHORUS-enabled publisher. When CHORUS issues notification of publication, SHARE gets a copy via CrossRef. SHARE stores metadata related to this event (such as the source, the date of release, the researcher's ORCID, funding agency, grant ID, and the DOI of the publication at its publisher) in the notification service event digest.
Layers Involved
- Notification Service
Challenges
- Details of SHARE event metadata have yet to be determined. Grant ID is particularly troublesome and may not be possible for years to come.
Potential Requirements
- Harvesting reports via CrossRef API.
Notes
- What about publishers that do not participate in CrossRef? Does each need a use case or do we handle them similarly to CrossRef, supporting one-off API's for harvesting from each?
Comments
- kp2002 commented: I'll note that journals hosted by the Center for Digital Research and Scholarship at Columbia use EZID DOIs. Many are student journals but there are certainly publications from which SHARE would want to harvest.
[NS Use Case]
A researcher submits unpublished work to their local SHARE-enabled institutional repository. The repository collects ORCID, funder, and grant number associated with the work. Repository sends report of the submission with a Handle to the SHARE notification service. SHARE stores the event in its digest.
Layers Involved
- Notification Service
Challenges
- Many repositories are unable to distinguish research-related material from cultural heritage material.
- Identifiers like ORCID and FundRef are generally not collected by local repositories.
Potential Requirements
- Repository able to provide Handle or other persistent identifier for resources.
- SHARE push API to accept push reports from repository.
- OAI-PMH harvesting tool to gather reports from repository.
- ResourceSync harvesting tool to gather reports from repository.
comments
- Claire Stewart comments: Also: many probably do not have explicit version information recorded
- gailst comments: And many if not most repos are not collecting funder and grant information (I realize they can, but submitters are generally not required to provide this info)
- Catherine Mitchell comments: Agreed.
- Mark A. Matienzo comments: Perhaps identification of specific sets (a la PMH) or other groupings that would be likely candidates for harvesting?
[NS Use Case] - [Registry Use Case]
Staff at the university office of sponsored research want to be alerted to any new publication or data set arising from researchers at the university. They visit the SHARE dashboard and set up an email alert so that SHARE emails them a copy of the metadata for any new event which appears to be affiliated with the university.
Manager of an institutional repository set up email alerts so that SHARE emails the a copy of metadata for new events which appear to be affiliated with their institution.
Layers Involved
- Notification Service, Registry
Challenges
- Arbitrary stored searches could become unwieldy. Certain pre-defined channels, like institutions, may need to be defined.
- Affiliations with institutions may be difficult to determine. Email addresses of authors, or affiliations listed in author ORCID profiles may help make the connection. -ISNI may help identify organizations, but rarely included in metadata.
Potential Requirements
- Widespread adoption of ORCID or consistent capture of email addresses.
[NS Use Case] - [Registry Use Case]
A funding agency manages a system that registers all new work arising from projects funded by the agency. In order to learn about resources not reported directly to them by principal investigators and project staff, they arrange for a feed of SHARE notifications relating to their agency. These notifications are integrated into their registry so that appropriate references can by copied from SHARE with little additional effort.
Layers Involved
- Notification Service, Registry
Challenges
- Arbitrary stored searches could become unwieldy. Certain pre-defined channels, like funding agencies, may need to be defined.
Potential Requirements
- Widespread adoption of FundRef.
- Notification API to provide feeds to consumers.
- Use of Uber Research data to help identify grants.
Notes While it is easy to conceptualize this as SHARE "pushing" notifications to the agency system, it may actually be implemented more like RSS, with the agency system regularly polling SHARE for new notifications.
[NS Use Case]
The researcher registers her ORCID in the campus CRIS to make it even easier to update her profile. New notifications in SHARE bearing her ORCID now get automatically imported into her workspace for review and addition to the CRIS profile.
Layers Involved
- Notification Service
Challenges
- Campus CRIS would have to transform SHARE feed into actionable items for researcher.
Potential Requirements
- Widespread ORCID adoption.
[NS Use Case]
A publisher wants to get the word out about the research release events represented by their publication, but they are not satisfied with just communicating this to a United States audience. They report these events to SHARE because of SHARE's collaborations with Jisc in the UK, OpenAIRE in Europe, and other research awareness services around the world.
Layers Involved
- Notification Service
Challenges
- Coordination with Jisc Monitor, OpenAIRE, COAR and other worldwide efforts requires ongoing effort and vigilance.
Potential Requirements
- Worldwide metadata and interoperation standards.
[Registry Use Case]
[NOTE: This is not a Notification Service use case.]
An administrative assistant is looking for all publications by faculty member in past year in order to complete a faculty dossier for the year. The assistant visits the SHARE dashboard, provides the faculty member's ORCID and bounds the search by the previous calendar year. SHARE provides list of resources from its registry with an option to export the list in CSV form.
Layers Involved
- Registry, Discovery
Challenges
- Unclear what formats for export would be most helpful.
- Variety of resource types in registry may make uniform export of metadata difficult.
Potential Requirements
- Widespread adoption of ORCID would make author identification more feasible.
[Registry Use Case]
[NOTE: This is not a Notification Service use case.]
A grant administrator compiling the outcomes of a grant visits the SHARE dashboard and looks up their FundRef identifier. SHARE produces a list of the most recent resources reported that related to that funder. The administrator further limits the results to a set of researchers identified by ORCID who participate in the grant project. From this list the administrator finds three resources that are outcomes of the grant but had not yet been reported through university channels.
Layers Involved
- Registry, Discovery
Challenges
- Many sources may not report ORCID or FundRef identifiers.
- What dates indicate recency? Date of publication? Date of report to SHARE?
Potential Requirements
- Faceted searching of discovery system.
[Registry Use Case]
An institutional policy makes it mandatory for a researcher to keep her list of publications up to date in the institution's CRIS system. Instead of filling out the metadata by hand, the research adds individual items to the CRIS based on metadata retrieved from SHARE after searching on her own name through a live lookup integration between the CRIS and SHARE.
Layers Involved
- Registry
Challenges
- Ambiguous names present problems for researchers.
Potential Requirements
- API for searching SHARE registry and returning the data to local CRIS for presentation.
Running Harvesters with ScrAPI
Consuming Notifications - Feed Options
Issues & Using the Issue Tracker
SHARE is a project of the ARL, AAU, and APLU. Development of the SHARE Notification Service is being carried out in partnership with the Center for Open Science and is supported by generous funding from The Institute of Museum and Library Services (IMLS) and the Alfred P. Sloan Foundation.