Gather ideas for gathering content

[jamesvanmil]

Linda suggested making developer-driven content gathering a topic at an upcoming swarm. Opening this as a research issue to collect our comments on this topic.

[jamesvanmil]

We have access to the Scopus API, which gives us an interface for searching citations and getting metadata, including Open Access status and other information that we could collate with Sherpa/ROMEO to get information about self-archiving status.

My early thoughts are to use this to build a quick and dirty too gather intelligence about researchers to approach about getting content. Additionally, we might be able to use DOIs or publication info to generate OpenURL references directly to content, and gather pdfs to pre-ingest works into Scholar.

This API is on the radar of the research directory folks, too - I'm not sure if they've integrated work with this, but we should ask them about this.

[newmanld]

See JISC Publications Router http://broker.edina.ac.uk/repository.html — It uses the SWORD protocol for deposit and we would need to work out how that can happen.

[newmanld]

Symplectic elements - basically a system with some features in common with our local Research Directory, but with a workflow that ‘encourages deposit’ into a local institutional repository. Not sure yet how that encouragement workflow works: http://symplectic.co.uk/products/elements/

[newmanld]

The Center for Open Science is partnering with Notre Dame's Curate_ND to provide a portal from the COS Open Science Framework (https://osf.io/) to publication/storage in Curate_ND. See https://research.nd.edu/news/64035-notre-dame-center-for-open-science-partner-to-advance-open-science-initiatives/

[newmanld]

FigShare is another service in this space we should understand. I think that Figshare provides datastorage with tools to integrate with local campus research information systems (CRIS describes our Research Directory) and local repositories. See https://figshare.com/services/institutions

[newmanld]

And now that we have access to the ORCID API, if we are looking for a service to use somewhat like SCOPUS, to give us a feed of our faculty's publications, the ORCID API should also help. Initially it may be redundant with SCOPUS but over time as there is now a critical mass of funding agencies requiring ORCIDs (the ID) and ORCID profiles, the data should grow. We should have our ORCID API credentials soon.

[newmanld]

The Research Directory folks are using the SCOPUS API to add content (citations only) to faculty profiles. We can leverage their experience to see how much it can help us identify and obtain (either automatically or manually) open access content, not just citations.

[jamesvanmil]

Useful!: http://libguides.mit.edu/apis

[lawhorkl]

We should look into the various events that CECH and perhaps CEAS hosts year round for IT-related technologies. A lot of faculty and staff, as well as top brass from UC attend these events.

[newmanld]

I initiated an inquiry with Elsevier about Scopus API. I received a response (I will email this response to the team) that seems to indicate that use of the Scopus API alone will not yield links to content that could be automated - manual curation still required. According to the response, the use of Scopus API combined with Science Direct API may have some possibilities. JISC router (see above) is looking to me like the next best candidate for possible automated ingest. I have also made inquiries with Figshare and Symplectic Elements and will share info as I get it.

[jamesvanmil]

@newmanld even with direct links to content in the scopus API, some manual curation likely would still be needed, because:

• systematically accessing content on a platform would trigger anti-harvest blockers and library-wide access could be suspended on that platform
• Links to content often will send you to landing pages
• Most content isn't on ScienceDirect (yet)

JISC router looks neat

[newmanld]

See http://dev.elsevier.com/tecdoc_sd_ir_integration.html - there are possibilities with ScienceDirect. See email forwarded to team.

[scherztc]

Not our responsibility.