Page 1 of 20

LibriVox API Discussion Thread

Posted: January 26th, 2013, 1:08 pm
by hugh
Dear Developers...

LibriVox is rebuilding its API. If you are planning, or already have, built apps or web services on the LibriVox catalog, please post here so we know who you are & also, pls monitor this thread.

We'd like you to test, and give us feedback.

The information about the NEW API can be found here, and will be updated as the project progresses:
http://dev.librivox.org/public/temp_info/api [edited: now found at https://librivox.org/api/info ]

If you have questions/comments/feedback/thoughts, please post them in this forum thread.

Thanks!

Hugh.

Re: LibriVox API Discussion Thread

Posted: January 27th, 2013, 4:07 am
by ekzemplaro
Hello Hugh san,

I use LibriVox API to update the information at the following pages.

http://ekzemplaro.org/librivox/statistics/
http://www.hi-ho.ne.jp/linux/librivox/statistics/index.htm
I request readers information is included.

Another request is to provide information for sections.
Information about readers, recording time & language.

Cheers,
Masa

Thank you Masa-san,

I have added to the Sections data:
-- language (In English, capitalized & possibly more than one word - ex. Old English. We have never had codes, but I will try to match them up - some of our languages are pretty obscure)

-- playtime - in seconds. NOTE: the total playtime for the project is still TODO, though is on my list for today

-- file_name -- just the file name and extension without any path info, if that proves useful

Re: LibriVox API Discussion Thread

Posted: January 27th, 2013, 8:00 am
by tbook
Here is a "wishlist" of features that I would like to see in the new API

* Ability to access "works" even when they are distinct from books
- eg. in the case where a book has multiple works in it, such as "Short Story Collection #987"

So, you would like a parameter: ?work_id=123 which would return all the books related to a single work group?

* Ability to access readers for any work

readers being added asap

* Ability to access cover art for all books when it is available
- for some reason the current api usually returns a default image, even when there is cover art

I'll look into fix that up in new api

Those are the main things that come to mind. I will post any additional thoughts as they come along. I've taken the alpha API for a little spin, and it looks like it is coming along well!

Re: LibriVox API Discussion Thread

Posted: January 27th, 2013, 8:26 pm
by hugh
thanks guys, we'll be reviewing this thread as the work progresses...

Re: LibriVox API Discussion Thread

Posted: January 27th, 2013, 8:33 pm
by dlolso21
Thanks for the information.

If we are in the process of fixing things shouldn't we be aiming for co-relation and consistency?

Project ID is the identifier number for Librivox Project ID
Project URL is the URL for the Wiki Project URL
Librivox URL is the URL for Librivox Project URL

So that the two Librivox pieces are more in line with each other could the
Project ID be renamed to Librivox ID
or
Project URL used for the Librivox URL and WIKI URL be used for the Wiki URL ??

It is probably too late in the process, but never hurts to ask?

David O

sorry, little late. The api is generated directly from the database table fields & I'd prefer not to alias to much for maintainability reasons

Re: LibriVox API Discussion Thread

Posted: February 7th, 2013, 9:28 pm
by tbook
Sorry to be slow in responding! I thought that I had this thread marked to notify me on changes, but apparently, I didn't.

Regarding works, I would like to be able to access things smaller than a book directly. I think there is some support for that in the database already, as search results return works that are inside a larger collection. For example, I just looked and there is a story entitled "Laura" by Saki in the first Ghost Story Collection. I would like to be able to have a unique identifier (like the ones for the books) that I could use to reference that story, access it by paging through all the works, and even have a way to attach additional metadata to it - like a description, and maybe even an image. It seems to me that most people would prefer to access the story individually, as opposed to seeing it as part of a group of other stories that happen to be bundled into that particular collection.

I'm glad to hear about the reader data being added!

Thanks for all you are doing! Keep up the good work!

Re: LibriVox API Discussion Thread

Posted: February 8th, 2013, 5:24 am
by ekzemplaro
Hello,

Thank you for your message.
I have added to the Sections data:
Let me explain what I need.
For a solo project current API is OK. We need new API for Collections.

As a example I use this
http://librivox.org/librivox-multilingual-short-works-collection-002/

If I use New API like this
http://dev.librivox.org/api/feed/audiobooks/?id=6701
<language>Multilingual</language>
What I need is as follows,
<section>
<language>Bisaya</language>
<reader>April Gonzales</reader>
<totaltime>03:18</totaltime>
<title>Ang mga Mahadlokon</title>
</section>
<section>
<language>Japanese</language>
<reader>ekzemplaro</reader>
<totaltime>12:35</totaltime>
<title>Trokko</title>
</section>
<section>
<language>Spanish</language>
<reader>AnabelleC</reader>
<totaltime>02:56 </totaltime>
<title>Dia de bronca</title>
</section>
If you have questions, please feel free to ask.

Cheers,
Masa

Re: LibriVox API Discussion Thread

Posted: February 8th, 2013, 7:37 am
by tbook
That somewhat corresponds with my thought about "works". Sometimes a "book" is a single work by a single reader, sometimes it is a single work by multiple readers, and sometimes it is multiple works by multiple readers. We use the same section / chapter concept to represent both chapters in a book and multiple works in a collection of books. I don't know if there is anything in the existing database that distinguishes between the two, but if there is, it would be great to have access to it, and if not, it would be nice to at least have a way to add that functionality.

Re: LibriVox API Discussion Thread

Posted: February 13th, 2013, 4:22 am
by dsforge
Maybe i'm missing something but when i try to query the db by language i get incorrect results

i.e.
http://dev.librivox.org/api/feed/audiobooks/?language=italian

displays the first 50 "usual" results (and they are english books so obviously the query didn't work)

I also tried

http://dev.librivox.org/api/feed/audiobooks/?language=^italian

without luck.
Same with genres, I don't seem to be able to perform a genre search with the new API.

Thanks a lot for the hard work.
joe

Re: LibriVox API Discussion Thread

Posted: February 13th, 2013, 8:18 am
by tbook
Another note on the idea of "works" that I've been talking about. I've mostly been emphasizing the case where there are multiple works in a book, but there is also the case where a single work spans multiple books. For example, Les Miserables spans 5 books. It would be good to have a way to access them as a single entity.

Re: LibriVox API Discussion Thread

Posted: February 13th, 2013, 10:39 am
by Cori
tbook wrote:For example, Les Miserables spans 5 books. It would be good to have a way to access them as a single entity.
We have the concept of grouping volumes now, I don't know if it appears in the API in any way but it seems like it would be helpful.

Re: LibriVox API Discussion Thread

Posted: February 13th, 2013, 1:11 pm
by tbook
Thanks for the response! It would be great to get that into the API.

Re: LibriVox API Discussion Thread

Posted: February 13th, 2013, 1:16 pm
by annise
Grouping is used for other things too Cori - so we would have to have some way of differentiating between War and Peace in 15 parts and the short story collections - all 50 odd of them and something like the Trollope Palliser series for example.

Anne

Re: LibriVox API Discussion Thread

Posted: February 13th, 2013, 1:44 pm
by Cori
Oh, I'd not thought about that, thanks Anne! Not sure what to suggest, then.

Which API to choose

Posted: February 27th, 2013, 1:39 pm
by happymindsparker
Hi, I was wondering whether it's safe to use the new dev API yet? Or should we stick to the old API?
Thanks