I'm working on an API that doesn't suck that will represent TV, Movies, Podcasts, WebTV, and other forms of media.
A stack-overflow inspired reputation system will reward community members to contribute translations, new shows, movies and corrections.
Background workers interface with EPGs, other APIs and streams of data from other sources.<p>An image proxy server means openmedia.io will do the heavy lifting delivering images in the dimensions that you want, backed by a speedy CDN.
For movies only (I understand that you service does more than just movies, but for my application this is currently irrelevant), are there key differences (benefits and weaknesses) compared to TMDb : http://www.themoviedb.org/
This looks really interesting for a project I'm working on. The license being used is obviously very open, but at the say time, does it effectively preclude proxying requests or caching returned results?
Basically, if I wanted to offer the data from this system as a data layer to my front-end, would I need to hit your server for every request?
I'd second this, there's distinct datasources for it (IIRC Diamond publish release dates for all titles they ship, which is practically everything in North America and England), but there's no way to consolidate it. Could create some cool tools with it as well.
@carbuncle - If TMDB's licence allows, I can absolutely imagine offering the webhooks, and changes stream and a Movie type backed by TMDB. It's something I'll have to take up with their moderators.
@theallan - It depends whether that would be a competing service under liberal interpretations of the law, when the legal chap has drawn up the API permission guidelines, I'll be sure to notify the mailing list. Under German law we have to be quite explicit about granting permission, but the beta list will be notified of the full terms of usage before the API opens. (My gut-feeling, no problem with using the data to back an app, that's sort-of what the data's for!)
I believe trakt.tv is the kind of service that might benefit from a simplified back-end system if it were to use openmedia.io. They likely use thetvdb, or epguides or similar now, or may even have their own integrations with EPGs.
Similar services:
* Web: trakt.tv, watched.it, watched.li, gomiso.com, getglue.com
* Android: TV Series, TV Show Favs, Twee, DroidSeries, MyEpisodes
I don't think that trakt.tv is really competing on an API level, but the data from openmedia.io would make building and maintaining a TV and movie tracker trivial.
The intention is to provide an API that requires little or no work on the part of the service relying on the data. Having had to work with thetvdb's API I can attest to having to download ~100 XML files (all languages…) in order to determine if anything is new, their API is often 2/3 days out of date, some internal caching problems and problems with scaling, they only deliver XML, poorly compressed (owing to key structure).
I believe services such as trakt.tv and similar should be able to do one thing, and do it well, offer a to-do list of shows you should watch, and summarise what you have watched. And they shouldn't have to write thousands of lines of code to interface with an API for what's actually quite simple.
In my (admittedly contrived, and not representative) benchmarks the JSON representing a typical TV series is 76% smaller, and parses 56% faster (that is probably representative of years of research and work into making fast XML parsers, and JSON being a relatively young format)
Also, I find it strange that they don't provide a notifications API or changes stream.
I don't want to call thetvdb specifically, many API and data providers make the same mistakes, if one can call a missing feature a mistake. (TradeDoubler, many financial APIs, etc)
Another departure from typical API design is to accept that many movies, shows, books and so forth are provided simultaneously (or, close to simultaneously), world wide, in multiple languages.
Therefore any API that purports to represent them must acknowledge that English isn't the default language, but it may have been the language in which the media was authored, and that airing dates, shipping and printing dates are worthless without timezone and language information.
My goal is to make an API that is easy to use, and can open the creativity of the community up, by allowing something that is now rather difficult to become easy.
To call out some of the problems I've tried to solve: timezones; networks; outlets (web); airing dates vs. availability dates (locale specific); actors vs. hosts vs. cameos; returning series under the same name; specials vs. pilots vs. shows about a series; treating different languages with equal weight; encoding (utf-8 naturally); gzip; msgpack... I'm sure there are many more which I've forgotten, but that's the gist of it :-)
<troll-feed>
I asked, In the small sample I questioned, not a single f* was given. Now troll off somewhere else, or alternatively actually make a useful contribution to increasing opportunities and interest for women in tech.
</troll-feed>
You know..I just did, and she does not give a shit. She cares a heck of a lot more that her male colleagues earn more than she does.And that being of child bearing age somehow counts as a strike against her at her job.
Maybe YOU should try talking to an actual woman and asking her what she cares about.
To quote my significant other: "who the f* actually cares about this!?"
Of course you will find women who support your point - as you will find people who support $something, no matter what it is.
The fine line between caring and taking care of a problem and moving every topic off topic, justifying it with something small, unimportant, knowingly wrong interpreted and ripped out of context is the key to change something without creating a mass of people who are just sick of a topic because of the mentioned behavior.
If it's small and unimportant, why not do the right thing and use a non-sexist term instead of a sexist term?
Why are we defending the use of a masculine mass noun to refer to all humans when it confers no advantage over an equivalent non-sexist term while adding, however incrementally, to the totality of messages that women are not welcome in tech?
> If it's small and unimportant, why not do the right thing and use a non-sexist term instead of a sexist term?
Because we don't agree that it is a sexist term at all, and altering common usage to suit the sensibilities of a tiny group of people[1] is a) pandering, which is discriminatory, and b) impossible.
> Why are we defending the use of a masculine noun to refer..
Well that's just it. It isn't a masculine noun. It's gender neutral. It takes no stance on the debate whatsoever. Its resemblance to a masculine noun is interesting but not relevant. If the author had meant it in a gender specific way, he would have committed a grammatical error.
Right bark, wrong tree, I think. You're just making easy noise. If you are passionate about the underlying issue which you've conflated here, I hope you also spend energy in more fruitful efforts.
[1] by which I mean the tiny group of people offended on behalf of the larger 51% of the population, the vast majority of which doesn't even recognize this conversation as linguistically, much less socially, interesting.
Dear Hacker News: this persistent blind spot about the many casual, unconscious and dismissive ways the tech community excludes women - and get nerd-rage defensive about it when confronted - is a big part of why there are not more women in tech.
I'm generally in favour of calling out sexist bullshit in tech, but in this case you're talking about a very specific phrase that's been in semi-popular usage since the 1800s.
I don't believe it is cultural, I believe it was based off shortening 'mankind' to 'man'. However, I'm not a linguistics specialist and have no idea the roots of the phrase, but I've come across it in many contexts.
... and yet by 21st century cultural norms the word 'man' is still not considered sexist by many.
Besides, strictly from an etymological perspective you should not be calling for the eradication of the 'man' when used to speak of the species, rather you should call for a prefix to be used when talking of the gender (e.g. werman).
The habit of grepping all content for keywords without understanding context or definition inhibits rational discourse. Getting third-party apologist about it when confronted is a dead stop appeal to authority.
I understand the context and definition. It's still sexist. It's unnecessary and would be extremely easy to replace with a non-sexist term that is equivalent in both meaning and elegance. The extreme resistance even to acknowledge that there's something wrong with using "man" to mean "humans" is very telling.
A word to the critics (thanks!), the copy has been modified to be less rhetorical and to be absolutely gender neutral. I've also switched away from Raleway as a body font, it looked a lot better on a retina display than on something with a more widespread resolution.
I'm wondering about the kind of data you provide and what it's applications would be. Just to be sure, would this API somehow let me know if a new episode of say.. Mad Men comes out ?
Or is it only for me to query info regarding a specific episode ? What kind of data are you going to provide ? Some examples would really help!
One would be able to look up a complete representation of the current known state of Mad Men, all known airing dates in all countries, places where it might be available to (legally.) steam in your jurisdiction, etc, etc.
These are all the features of a normal API. As well as access to the above, you could (selectively) register for updates to be pushed to a URL of your choosing when there are additions or amendments to the data held about the show. (or all shows, or all shows matching your criteria, etc)
Plex and XBMC would be ideal candidates for this API, each user could easily maintain their own pointer to the data set, and their synchronisation would be faster and more efficient than it is right now.
There's also a provision with the API (for personal use, so far) which turns a filename (and metadata, if you have it) into a JSON hash (or msgpack, of course) of the episode, show and season, etc.
This is also a potential avenue for being more widely made available.
40 comments
[ 51.7 ms ] story [ 246 ms ] threadA stack-overflow inspired reputation system will reward community members to contribute translations, new shows, movies and corrections.
Background workers interface with EPGs, other APIs and streams of data from other sources.<p>An image proxy server means openmedia.io will do the heavy lifting delivering images in the dimensions that you want, backed by a speedy CDN.
Or just scraping imdb
Basically, if I wanted to offer the data from this system as a data layer to my front-end, would I need to hit your server for every request?
there's actually a pretty large need for a comic api and there's only one right now (comicvine) that has been neglected for 2 years.
I fear that existing APIs, through design and coincidence fail to address the needs of flexibly covering media of all types.
Join the list, look me up, or feel free to contact me to discuss
@theallan - It depends whether that would be a competing service under liberal interpretations of the law, when the legal chap has drawn up the API permission guidelines, I'll be sure to notify the mailing list. Under German law we have to be quite explicit about granting permission, but the beta list will be notified of the full terms of usage before the API opens. (My gut-feeling, no problem with using the data to back an app, that's sort-of what the data's for!)
Similar services: * Web: trakt.tv, watched.it, watched.li, gomiso.com, getglue.com * Android: TV Series, TV Show Favs, Twee, DroidSeries, MyEpisodes
I don't think that trakt.tv is really competing on an API level, but the data from openmedia.io would make building and maintaining a TV and movie tracker trivial.
I believe services such as trakt.tv and similar should be able to do one thing, and do it well, offer a to-do list of shows you should watch, and summarise what you have watched. And they shouldn't have to write thousands of lines of code to interface with an API for what's actually quite simple.
In my (admittedly contrived, and not representative) benchmarks the JSON representing a typical TV series is 76% smaller, and parses 56% faster (that is probably representative of years of research and work into making fast XML parsers, and JSON being a relatively young format)
Also, I find it strange that they don't provide a notifications API or changes stream.
I don't want to call thetvdb specifically, many API and data providers make the same mistakes, if one can call a missing feature a mistake. (TradeDoubler, many financial APIs, etc)
Another departure from typical API design is to accept that many movies, shows, books and so forth are provided simultaneously (or, close to simultaneously), world wide, in multiple languages.
Therefore any API that purports to represent them must acknowledge that English isn't the default language, but it may have been the language in which the media was authored, and that airing dates, shipping and printing dates are worthless without timezone and language information.
My goal is to make an API that is easy to use, and can open the creativity of the community up, by allowing something that is now rather difficult to become easy.
To call out some of the problems I've tried to solve: timezones; networks; outlets (web); airing dates vs. availability dates (locale specific); actors vs. hosts vs. cameos; returning series under the same name; specials vs. pilots vs. shows about a series; treating different languages with equal weight; encoding (utf-8 naturally); gzip; msgpack... I'm sure there are many more which I've forgotten, but that's the gist of it :-)
How about some non-sexist boilerplate?
Of course you will find women who support your point - as you will find people who support $something, no matter what it is.
The fine line between caring and taking care of a problem and moving every topic off topic, justifying it with something small, unimportant, knowingly wrong interpreted and ripped out of context is the key to change something without creating a mass of people who are just sick of a topic because of the mentioned behavior.
Why are we defending the use of a masculine mass noun to refer to all humans when it confers no advantage over an equivalent non-sexist term while adding, however incrementally, to the totality of messages that women are not welcome in tech?
Because we don't agree that it is a sexist term at all, and altering common usage to suit the sensibilities of a tiny group of people[1] is a) pandering, which is discriminatory, and b) impossible.
> Why are we defending the use of a masculine noun to refer..
Well that's just it. It isn't a masculine noun. It's gender neutral. It takes no stance on the debate whatsoever. Its resemblance to a masculine noun is interesting but not relevant. If the author had meant it in a gender specific way, he would have committed a grammatical error.
Right bark, wrong tree, I think. You're just making easy noise. If you are passionate about the underlying issue which you've conflated here, I hope you also spend energy in more fruitful efforts.
[1] by which I mean the tiny group of people offended on behalf of the larger 51% of the population, the vast majority of which doesn't even recognize this conversation as linguistically, much less socially, interesting.
"known to man" does not, and is not.
Besides, strictly from an etymological perspective you should not be calling for the eradication of the 'man' when used to speak of the species, rather you should call for a prefix to be used when talking of the gender (e.g. werman).
Or is it only for me to query info regarding a specific episode ? What kind of data are you going to provide ? Some examples would really help!
These are all the features of a normal API. As well as access to the above, you could (selectively) register for updates to be pushed to a URL of your choosing when there are additions or amendments to the data held about the show. (or all shows, or all shows matching your criteria, etc)
Edit: I would also very much like to see something like this in ifttt.com
There's also a provision with the API (for personal use, so far) which turns a filename (and metadata, if you have it) into a JSON hash (or msgpack, of course) of the episode, show and season, etc.
This is also a potential avenue for being more widely made available.