SHARE Notification Service, December 2014

As presented by Eric Celeste to the DuraSpace Hot Topics webinar, December 2014.

Transcript

1. THE SHARE NOTIFICATION SERVICE Hot Topics: The DuraSpace Community Webinar Series 10 December 2014 Eric Celeste, SHARE Technical Director, efc@clst.org
2. TODAY •  Brief background on SHARE •  Description of Notification Service •  Early Lessons of Notification Service •  Hint of plans for Phase II •  Opportunities to Participate •  Questions & Answers
3. WHO & WHAT IS SHARE? SHARE is a higher education initiative to maximize research impact.
4. WHO & WHAT IS SHARE? SHARE envisions an environment where researchers can keep interested parties seamlessly informed of their activities, where funders can easily determine the impact of their investments, and where institutions can readily collect and assess the output of their community members.
5. FUNDING $1,000,000 to develop Notification Service and long term SHARE vision March, 2014 through September, 2015
6. MISSION Maximizing Research Impact Infrastructure Workflow Policy
7. NOTIFICATION SERVICE Who is producing what? and Who wants to know?
8. USER STORIES As an IR Manager, I would like to know what output of our researchers is deposited in repositories at other institutions so I can approach them about a copy for our collection. I am a sponsor and I want to know what products have resulted from the research I sponsored so I can determine what additional revenue the original grant may have generated. I am the Director of Institutional Research and I’m tasked with notifying campus stakeholders, including University Communications and Office of Contracts and Grants, when our university’s faculty publishes an article (or other output) funded by an awarded grant.
9. RESEARCH RELEASE EVENTS Data Sets Articles Preprints
10. CONSUMERS OF RESEARCH RELEASE EVENTS Funders Campus Repositories Sponsored Research Offices
12. SHARE Notification Service
13. CENTER FOR OPEN SCIENCE “We foster openness, integrity, and reproducibility of scientific research” centerforopenscience.org & osf.io
14. THE TEAM AT COS
15. SHARE Notification Service
23. RSS •  “Really Simple Syndication” designed for blogs and breaking news. •  Struggles with large number of updates at one time. •  Very easy to set up, a fun way to see what flows through the Notification Service.
29. PUBSUBHUBBUB •  Developed by Google •  “An open, simple, web-scale and decentralized pubsub protocol. Anybody can play.” •  Another way for “publisher” like SHARE to inform “subscribers” like our consumers of changes to “our content” like our notifications.
30. RESOURCESYNC •  Developed by library community. •  Uses PubSubHubbub too. •  “A synchronization framework for the web consisting of various capabilities that allow third-party systems to remain synchronized with a server's evolving resources.”
31. SEARCHING VIA OSF
32. SEARCHING VIA OSF
33. STATUS AT END OF SUMMER Planned for 3 platforms, 5 institutions, 2 agencies, and 5 publishers, 50 research release events, including papers and data. COS harvesting data from Clinical Trials, DOE’s SciTech and Pages, PLoS, UC eScholarship, Wayne State Digital Commons, VTechWorks, NLM PubMedCentral, CrossRef, arXiv, and DataONE. Experimental RSS feed to see output.
34. RESEARCH RELEASE EVENT REPORTS Only a dozen sources Over 40,000 reports
35. PROTOTYPE PROVIDERS •  ArXiv •  California Digital Library eScholarship System •  Carnegie Mellon University Research Showcase •  ClinicalTrials.gov •  Columbia Adacemic Commons •  CrossRef •  DataONE: Data Observation Network for Earth •  Department of Energy Pages •  Digital Commons at Cal Poly •  DigitalCommons@WayneState •  DSpace@MIT •  OpenSIUC at the Southern Illinois University Carbondale •  Public Library Of Science •  Repository at St. Cloud State •  ResearchWorks at the University of Washington •  Scholars Portal Dataverse •  SciTech Connect •  University of Illinois at Urbana •  University of Pennsylvania Scholarly Commons •  University of Texas Digital Repository •  Virginia Tech VTechWorks
36. STILL WORKING ON Push protocol Creation of a “push API” to make participation simpler for some sources. Consumption of notifications Provide subscription methods Recruit trial subscribers Public release Early 2015 beta release Fall 2015 first full release
37. SOME EARLY LESSONS Metadata rights issues. Some sites not sure about their right to, for example, share abstracts. Metadata inclusion and consistency. Most of our sources do not even collect email addresses of authors, much less universal identifiers such as ORCID or ISNI. Most sources make no effort to collect funding information or grant award numbers. This data needs to be collected and distributed to make effective notifications. The need for a Phase II. Some consumers will want the enhanced records it will provide.
38. METADATA RIGHTS Does metadata gathering violate your terms of service? If so, are we granted explicit, written rights to gather data? Does metadata gathering violate your privacy policy? If so, are we granted explicit, written rights to gather data? Does our sharing the metadata we gather from you violate your policies? If so, are we granted explicit, written license to share the metadata? Do you use an explicit license for your metadata (for example, CC Zero)? If not, do you have plans to explicitly license the content?
39. VARIETY AND AVAILABILITY •  We accept that we will have a variety of providers with a variety of expressions. •  But we need some key identifiers to be available in order to create effective notifications.
40. GET https://frogworld. com/api/frogs Request Response [ { name: Kermit, color: green, type: felt }, { name: Travis, color: green, type: tree } ]
41. Resource 1 Resource 2 { title: Easy Being Green?, contributors: [ Kermit, Travis ], source: frogworld, id: 10.100/frogworld.102 } { title: Easy Being Green?, contributors: [ Kermit, Travis ], origin: frogworld, id: 10.100/frogworld.102, description: Exploring greenness. }
42. Resource 1 Resource 2 { title: Easy Being Green?, contributors: [ Kermit, Travis ], source: frogworld, id: 10.100/frogworld.102 } { name: Easy Being Green?, contributors: [ Frog Scientists Intl, Amphibians United, ], origin: frogworld, doi: 10.100/frogworld.102 }
43. Resource 1 Resource 2 { title: Easy Being Green?, contributors: [ Kermit, Travis ], source: frogworld, id: 10.100/frogworld.102 } { title: Easy Being Green?, contributors: [ No Contributors ], source: frogworld, id: 10.100/frogworld.102 }
44. POST https://osf.io/api/share Request Response { title: Easy Being Green?, contributors: [ Kermit, Travis ], source: frogworld, id: 10.100/frogworld.102 } Success
45. RIOXX •  See http://rioxx.net/v2-0-rc-2/
46. OPENAIRE •  See https://guidelines.openaire.eu
47. http://xkcd.com/927/ (CC-BY-NC)
48. GUIDELINES? •  See https://www.coar-repositories.org
49. INCLUSION OF IDENTIFIERS •  Researcher identifiers such as ORCID, ISNI, and so on. •  Funding identifier such as FundRef. •  Grant award identifiers. •  Further metadata elements encouraged by COAR, CASRAI and others.
50. CONSISTENCY ACROSS PROVIDERS •  We can manage the variety. …however… •  Consistency reduces errors. •  Consistency simplifies preparing for new providers. •  Consistency will be required for push reporting.
51. SOME USER STORIES MAY NEED PHASE II As an IR Manager, I would like to know what output of our researchers is deposited in repositories at other institutions so I can approach them about a copy for our collection. I am a sponsor and I want to know what products have resulted from the research I sponsored so I determine what additional revenue the original grant may have generated. I am the Director of Institutional Research and I’m tasked with notifying campus stakeholders, including University Communications and Office of Contracts and Grants, when our university’s faculty publishes an article (or other output) funded by an awarded grant.
52. SHARE Notification Service SHARE Registry SHARE Discovery For Systems via Protocol & API For People timely, structured, comprehensive organized and related source of linked data searchable and friendly
53. CHALLENGES •  Adoption of key identifiers just getting underway, requires international collaboration, •  Inferences prone to error, •  Duplicate detection difficult, •  Scale quite large, not well understood, •  This is a never-ending task requiring sustainable funding and governance.
54. SHARE Notification Service including Phase II? SHARE Discovery For Systems via Protocol & API For People timely, structured, comprehensive, reconciling incoming reports with what we already know and can learn from other sources searchable and friendly
55. PHASE II BENEFITS •  Researchers can keep everyone informed by keeping anyone informed, •  Institutions can assemble more comprehensive record of impact, •  Open access advocates can hold publishers accountable for promises, •  Other systems can count on consistency of metadata from SHARE.
56. OPPORTUNITIES •  Sign up for monthly SHARE update •  Subscribe to the RSS feed •  Join the Beta in 2015 •  Become a prototype participant •  Look for SHARE enabling guidelines
57. CONTACT US www.arl.org/share www.facebook.com/SHARE.research www.twitter.com/share_research share@arl.org (or efc@clst.org) bit.ly/sharegithub