Skip to content
This repository has been archived by the owner on Feb 19, 2022. It is now read-only.

Opening up to CORE API #126

Open
scottkleinman opened this issue Aug 6, 2013 · 4 comments
Open

Opening up to CORE API #126

scottkleinman opened this issue Aug 6, 2013 · 4 comments

Comments

@scottkleinman
Copy link
Contributor

Paste of tweet from @petrknoth:

@briancroxall Seen your Serendip-o-matic. Fancy feeding it with 12M+ open access articles from CORE http://core.kmi.open.ac.uk through its API?

I think this is a great idea, but I want to note some challenges. We need to consider the impact on design. Returning articles would make Serendip-o-matic a better research tool, and that's good. But would we need to change the tone? More importantly, we would probably have to detect media type more efficiently and allow the user to filter by it. In theory, this should be possible, but does it require enough coding muscle that it should be delayed until version 2?

Alternatively, @petrknoth may mean submitting CORE articles to Serendip-o-matic to generate image results. If that's the case, would we need something like the Zotero form to allow the user to submit a query to CORE? @petrknoth promises example deployments, so perhaps that will clear this up.

This is a bigger issue because there are numerous other aggregators that could be approached. I'm thinking particularly of NINES, 18connect, and MESA (all part of the same network). Needs some discussion.

@mialondon
Copy link
Contributor

See also #125

@petrknoth
Copy link

Hi all,

Let me briefly describe what CORE is. CORE is a large collection of open
access research articles (currently about 12M+ and still growing)
aggregated from hundreds of open access repositories and thousands of open
access (OA) journals. All the materials are freely available research
papers. CORE, as opposed to other OA aggregators, aggregates content at a
full-text level, not just metadata.

In relationship to Serendip-o-matic, CORE provides a recommendation system
(for detecting related resources to a piece of text), which has been
already adopted by a number of organisations, including The European
Library (
http://www.theeuropeanlibrary.org/tel4/record/core:core:query%3Dsemantic&collection-id%3Dcore&idx%3D2?query=semantic),
see the Similar in CORE link. Other users include Open Research Online,
Glasgow University, UCL Computer Center, UNESCO, etc. Can give more details
if needed. CORE has other applications, such as a mobile client for OA
papers or a dashboard for repository managers. There is a paper about CORE
in D-Lib if you're interested:
http://www.dlib.org/dlib/november12/knoth/11knoth.html . CORE has now over
0.5M monthly visits. We are also a partner in the Europeana Cloud project
were we are trying to build a shared European infrastructure for
aggregators.

What I am suggesting is that Serendip-o-matic could make use of the CORE
recommendation API (Called CORE Plugin:
http://core.kmi.open.ac.uk/intro/plugin). The user provided text in the
Serendip-o-matic text field could be sent to the CORE API which would
respond with the suggestions. We can also supply thumbnails, etc. so there
is no problem in adjusting it to your needs. In this way you could blend it
with the suggestions from other aggregators, such as Europeana. Now what is
cool is that the CORE recommender guarantees to only provide links to
full-text OA content, so everything the users will click on they will be
able to download and read.

Please let me know if you want more info. The usage of the system and the
API is, of course, completely free.

Petr

On 6 August 2013 17:10, scottkleinman notifications@github.com wrote:

Paste of tweet from @petrknoth https://github.com/petrknoth:

@briancroxall https://github.com/briancroxall Seen your
Serendip-o-matic. Fancy feeding it with 12M+ open access articles from CORE
http://core.kmi.open.ac.uk through its API?

I think this is a great idea, but I want to note some challenges. We need
to consider the impact on design. Returning articles would make
Serendip-o-matic a better research tool, and that's good. But would we need
to change the tone? More importantly, we would probably have to detect
media type more efficiently and allow the user to filter by it. In theory,
this should be possible, but does it require enough coding muscle that it
should be delayed until version 2?

Alternatively, @petrknoth https://github.com/petrknoth may mean
submitting CORE articles to Serendip-o-matic to generate image results. If
that's the case, would we need something like the Zotero form to allow the
user to submit a query to CORE? @petrknoth https://github.com/petrknothpromises example deployments, so perhaps that will clear this up.

This is a bigger issue because there are numerous other aggregators that
could be approached. I'm thinking particularly of NINES, 18connect, and
MESA (all part of the same network). Needs some discussion.


Reply to this email directly or view it on GitHubhttps://github.com//issues/126
.

@briancroxall
Copy link
Contributor

Thanks for weighing in, @petrknoth. This is helpful information to have.

I think the Serendip-o-matic team needs to resolve what our immediate and longterm vision for the product is. At the moment, we're focused primarily on exposing GLAM materials. Using CORE would, as @scottkleinman suggests, make Serendip-o-matic more of a research tool. There are pluses and minuses to moving in that direction. We hope to have a conversation in the coming week about this with the project leads.

@mialondon
Copy link
Contributor

Looking at this quickly, it sounds like it'd work best as a parallel offer to Serendipomatic? i.e. a service that I could feed draft text into and get possible resources back would be ace, but it's also quite a different role and vibe to the light-hearted 'chuck stuff in and be delighted' focus we currently have? So creating a version that worked with CORE would be as simple as cloning the repo and going from there...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants