search

backtracks / open-podcast-analytics

Open podcast analytics specification
Apache License 2.0
69 stars 8 forks source link

Differences with Open Audio Analytics? #1

Closed kookster closed 8 years ago

kookster commented 8 years ago

A brief look shows they are similar, is there a description of the differences?

jgill333 commented 8 years ago

@kookster, There is not an explicit listing of the differences...yet.

Open Podcast Analytics (OPA) is, as the name gives away, geared specifically towards podcast analytics and extends Open Audio Analytics (OAA) with a specific set of known types and properties that are specific to podcasting. This provides a base level of data to enable functionality for podcast analytics (applications, clients, and publishers as well as analytics providers can expect to have a certain baseline of data). Concepts like season, series, episode can be more important to podcasts along with categories, subscribe/unsubscribe semantics than for music purposes for example. It is a more defined extension, that may become more opinionated, that builds on Open Audio Analytics (OAA). If you have any suggestions on what we can add for known types and into the guide that benefits everyone, please do.

Open Audio Analytics (OAA) is a general purpose audio analytics spec that works for audio of all types, but it does not presume too much about the type of audio. OAA can handle music, audiobooks, podcasts, spoken word, station semantics, etc. but it is purposefully very open to enable that flexibility.

kookster commented 8 years ago

In regards to that, seems like those additional values would be valid but option props, why do you need a new standard for that? Seems like it's hard enough to get one standard adopted, you want to try and promote and support two?

jgill333 commented 8 years ago

@kookster It's really more about adoption and usage and perhaps we're wrong, but trying to communicate that something implements the Open Podcast Analytics guideline of the Open Audio Analytics spec/protocol makes it more difficult to communicate (even though that phrase is relatively clear in its meaning).

In terms of timeline we created tools and systems that revolved around OAA first then even internally got tired of explaining what different set of properties and uses podcasts have than music for example. It would have been odd for us to create OPA then dervive OAA from that just in terms of the history and that it started as an offshoot of things that deal with audio analytics in general.

We're also coming from the standpoint of an audio analytics provider, regardless of type of audio. We think there is indeed a clearer immediate need and use case for podcast analytics that can be provider agnostic in the data vs. dealing with something like the music industry exclusively. As you pointed out everything you can do with Open Podcast Analytics (OPA) you can do with Open Audio Analytics (OAA)...but that may not always be the case. Even new things have a bit of history.

Also as you can tell, we're focusing on the adoption of Open Podcast Analytics (OPA) first as that's where the need is.

As for props that up for debate. There are some advantages to having top-level properties that are reserved for use without requiring namespacing.

jgill333 commented 8 years ago

@kookster Think there was a misunderstanding on my part relating to your question, which may have been more related to the usage of props. Usage of props is up for debate, but it's our way of avoiding too much namespacing or reserved property names by allowing and isolating custom properties from the app/client/publisher perspective to be within props and the top level properties (or their children) are more fixed, fewer in number, and could be utilized now or appended to in the future without conflicts to apps/clients/publisher data.