Use Cases
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.
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?
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.
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.
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.
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.
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.