o2r-project / o2r-badger Goto Github PK

http://localhost:8089/api/1.0/badge currently gives

{

    "type": [
        "executable",
        "peerreview",
        "licence",
        "spatial",
        "releasetime"
    ],
    "services": [
        "o2r",
        "doaj",
        "crossref"
    ]
}

So different services can be used for different badges. The use does not know, which service+badge - combination will yield a result. That is not nice. Ideally, the user should not care about the service but only about the badge!

Therefore update the API to not require the services, but instead internally map from badge type to a suitable service. In case multiple services can provide information for a badge, we internally choose the "better" one (i.e. the one that is not N/A), or a "preferred" one if two differing results are obtained.

For transparency, a ?all_services could be appended and return a JSON providing all the different labels...

When a user left-clicks on the icon in Chrome, nothing happens.

Why not open the menu, just as with a right click?
Or show the number of retrieved badges for the current page?

Other ideas what could be shown welcome.

svg should support clickable links, hover texts, etc.

Sending a request to badger normally results in request to a third party server because the badge is returned. Therefore we should as much as possible cache our responses, where results are unlikely to change.

Evaluate these packages and then implement:

• https://www.npmjs.com/package/apicache (looks most promising)
• https://www.npmjs.com/package/express-cache-route
• https://www.npmjs.com/package/cacher

Right now the timeout is quite high, so the requests to the badger are open for quite some time, allowing a lot of time for the third party services in the backend to reply. This could be a good thing, but puts additional load on the badger (keeping all the connections open) and also is not an optimal user experience.

Therefore it should be possible to configure a timeout for each service (e.g. doaj, o2r) that is queried for badge information in the background, and return the request to the user of the badger API quicker.

see for example https://github.com/o2r-project/o2r-muncher/blob/master/Dockerfile

If there is a link to data in some database, is the data stored in an open repo (see re3data.org) ? What is the data license?

http://opendoar.org/

http://opendoar.org/

For a given DOI, search Zenodo, b2share, figshare if there is a supplement that belongs to a paper.

https://core.ac.uk/docs/

If a user clicks on a badge, he should be taken to a landing page with information why this concrete badge was awared. Links are generated in extender, but the landing pages should be provided by badger.

Related to #12 because we could distinguish the landing page and #12 simply by requested content type. If HTML is requested, a server-side rendering of the JSON that is returned to fulfil #12 is returned.

Instead of just rendering the badge, we could also provide JSON document with the same information for client side rendering.

Does this go against the badge idea?

Add tracking of API calls based on Piwik (we have a Piwik instance running)

• [ ] add docs or script to run piwik locally in a server for testing
• evaluate npm packages vs. express middleware
  • https://www.npmjs.com/package/piwik
  • https://www.npmjs.com/package/piwik-tracker
  • app level express middleware, see https://piwik.org/blog/2014/06/track-api-calls-node-js-piwik/ and https://expressjs.com/en/guide/using-middleware.html
• implement tracking for every URL call
  • use sensible action names, see https://developer.piwik.org/api-reference/tracking-api
  • custom variables to hold more information
• add configuration
  • Piwik token as env variable
  • enable/disable tracking completely via env variable

Questions

1. Which badge type is requested how often?
2. What are the most (Top 10, Top 20, Top 100) requested DOIs of publications?
3. Which research websites are used how often? (via referer header)
4. What are the shares of "n/a" - badges? (for each badge type)
5. Which data-backend/"service" ist used how often (only if we have a badge where the same information is queried from different sources) ?
6. How many requests do not come from the o2r-extender?
7. What are the shares for extended (/ svg / png) badges?
8. Which extender version are users using? What is the version distribution?

see muncher

How to do that for small and large badges? Find the best fitting region and use that name??