| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

API Wishlist

Page history last edited by christopherdtaylor@gmail.com 9 years, 6 months ago

API specification wishlist

This wiki is owned by Suzanne Hardy at the MEDEV Subject Centre. If you have any problems with it, please contact suzanne@medev.ac.uk

 

Please feel free to outline what you would like to see in future iterations of the API. It would be particularly useful to know:

  • What functionality you would like.
  • How you would use it.
  • How you would prioritise it (e.g. using MoSCoW prioritisation).
  • The range of data you require and in what formats.
  • When you would need it by.

 

Feature  Priority  Usage 
Issue date  

MEDEV

Bioscience

Latest additions  

MEDEV

Bioscience

Keywords (dc: subject)
 

MEDEV
Open Fieldwork 

Bioscience

Collection   MEDEV

Jorum unique_id

(useful for harvesting / updating)

 

MEDEV

Bioscience

Feeds of searches

(eg. http://www.medworm.com/rss/userss.php?qu=cardiology )

   
Identifier
 

Open Fieldwork

MEDEV

Bioscience

Rights info
 

Open Fieldwork

MEDEV

Bioscience

     

 

Examples of the kinds of APIs we are currently using at MEDEV:

Xpert - look here for great examples of feeds and formats useful to us.

Picasa

Google Maps

Vimeo

Diigo

etc etc

 

The more open and complete the data set we have access to the more customised services we can build to match our local user requirements, mashing Jorum data with data from elsewhere (like Xpert)  in one user interface.

 

From the Open Fieldwork (OF) project perspective...

 

  • ditto keywords (dc.subject) 
  • identifier (i.e link of actual resource if outside JO)
  • rights info 

 

The OF project is exploring geotagging and ideally this kind of information would be captured in something like dc.coverage - I don't think this is supported by JO and even if coverage is in there somewhere there is currently  no way for a depositor to populate this field. As a work around we are producing guidance that recommends putting basic coordinates in the description.  

 

Searching with API

  • Search by combination of jorum dc field(s), defined by the user as part of the API call e.g. return all dc:subject=ukoer and dc:rights=[some cc license]. To allow specific searches that can be then contextually displayed for different requirements/areas of our site.
  • Limit search to a selection (user defined) or all Jorum sectors/collections, this would be in addition to providing field specific criteria above. So for example we would be able to use the api to query just the medical collection, with dc:rights cc and a authors name.
  • score/relevance in search.

 

 

Bioscience p.o.v.:

We would as a minimum like to be able to recreate what we were forced to do ourselves using Feed43 (but this time without massively skewing JorumOpen's search statistics data) as we documented here: http://biooer.jiscinvolve.org/wp/2010/04/28/outputting-rss-feeds-created-from-custom-searches-in-jorumopen/ 

and an example of can be seen here: http://www.bioscience.heacademy.ac.uk/resources/oer/projectpartners_Biodiversity.aspx 

(I'm sure most of you have seen these so apologies for repeating them once again, but for completeness...)

 

I.e. pull out links to selected resources to redisplay contextually within our own website.

 

It looks like the points mentioned by Suzanne and Mike above should cover that, so to just reiterate we'd need an absolute minimum of of Author and keyword fields to interrogate.

 

Also, I'm not sure if the responsibility for this would lie on our side (my technical expertise are... woolly here), but the ability to embed it in our MediaWiki would be high on the list.

 

Chris.

 

In addition we would wish for current number of downloads for each resource in this JORUM record. This is not a request to dynamically run a script on the web logfiles to count the number downloaded over a set period, it is to have a mechanism in place which counts downloads as they are requested into a seperate record within JORUM itself, which could then be easily included in the resource record returned by the API. Each contributor would like to be able to declare how many downloads they have generated from their work.

Terry.

 

Comments (0)

You don't have permission to comment on this page.