ListenLog: Difference between revisions
No edit summary |
(→Purpose & Deployment: added two principles links) |
||
| (41 intermediate revisions by 16 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Media Logging]] | [[Category:Media Logging]] | ||
ListenLog, or [[Listen Log]] is a form of [[Media Logging]]. It is required for [[ | == Overview == | ||
The VRM ListenLog is a proposed method for integrating simple user-driven functionality into an online audio player device or application. A ListenLog is a consolidated and documented history of an individual's online listening activity. It is simply a recorded activity log, in a standard and open format, capturing an individual's listening actions from multiple online applications. The ListenLog is unique in that its aim is to give the user the ability to accumulate and control the use of their listener activity data. The data is the user's. It does not belong to any vendor or intermediary. The user alone should have control over where the data lives, what applications write to it, what gets logged, who to share it with, and how it can be used. The ListenLog concept was devised in part for the [http://publicradiotuner.com Public Radio Tuner iPhone project], where it is first being introduced. Plans are to put it on other handhelds as well. (And, as an open source project, there is nothing to prevent others from doing what they like with it.) | |||
== Purpose & Deployment == | |||
ListenLog, or [[Listen Log]] is a form of [[Media Logging]]. It is required for [[EmanciPay]] to work. EmanciPay is a new business model for otherwise free media goods -- one that sharply reduces the frictions involved in paying for media. By increasing the number of people who pay for free media, PayChoice also helps stigmatize non-payment for those goods. | |||
Logging of listening is required to answer all these common questions: | Logging of listening is required to answer all these common questions: | ||
| Line 12: | Line 16: | ||
#Do I have a relationship with the source? (Such as membership, or past transactions.) | #Do I have a relationship with the source? (Such as membership, or past transactions.) | ||
ListenLog is a simple utility that does nothing more than record listening data for the user. It will store it in a form that can be crunched in many ways and for many purposes -- all by the user's choice and at the user's discretion. It will be data that can go in any database or spreadsheet. It can also be shared in a selectively disclosed way. (See [[ | ListenLog is a simple utility that does nothing more than record listening data for the user. It will store it in a form that can be crunched in many ways and for many purposes -- all by the user's choice and at the user's discretion. It will be data that can go in any database or spreadsheet. It can also be shared in a selectively disclosed way. (See [http://cyber.law.harvard.edu/projectvrm/Main_Page#VRM_Principles VRM Principles list] and the earlier [[Principles]].) This will make possible a marketplace for third-party services that help both listeners and the institutions with which they relate. (Starting with stations, but also including program producers, artists and others.) | ||
With ListenLog data, listeners can make fully informed choices about how they support streams, podcasts and on-demand sources of programming. | With ListenLog data, listeners can make fully informed choices about how they support streams, podcasts and on-demand sources of programming. | ||
| Line 18: | Line 22: | ||
Listeners can also form better relationships with stations and program sources. Membership can come to mean far more than serving as a future target for pitches and billing. | Listeners can also form better relationships with stations and program sources. Membership can come to mean far more than serving as a future target for pitches and billing. | ||
Both Media Logging and | Both Media Logging and EmanciPay are being pioneered with the Public Radio Tuner, which is currently being developed by [[http://prx.org PRX]] and other partners, including NPR and ProjectVRM at the [[http://cyber.law.harvard.edu Berkman Center]]. Neither, however, are to be limited to the iPhone, or any other platform. But the iPhone and the Public Radio Tuner are where we are starting. | ||
There are challenges posed both by the pioneering nature of the work and the limitations of the iPhone. | There are challenges posed both by the pioneering nature of the work and the limitations of the iPhone. | ||
| Line 26: | Line 30: | ||
Because this distances the user's data from the user's devices, and requires trust in PRX (or any host), questions of trust are naturally raised. These are the same issues raised by any cloud service, including Gmail and Amazon S3. Establishing trust mechanisms -- both technical and contractual -- are non-trivial. But they are also essential for laying the groundwork required for this new business model to work. | Because this distances the user's data from the user's devices, and requires trust in PRX (or any host), questions of trust are naturally raised. These are the same issues raised by any cloud service, including Gmail and Amazon S3. Establishing trust mechanisms -- both technical and contractual -- are non-trivial. But they are also essential for laying the groundwork required for this new business model to work. | ||
=== | == History == | ||
While tracking listener behavior data is not a new concept, the ListenLog is a novel approach to deploying early VRM functionality. While a simple activity log might not appear as the killer app, it succeeds by putting in place a small piece of user-driven infrastructure into a larger application - one with a promise of relatively wide distribution. Since this infrastructure component will write, store, and share listener activity in an open and standard format, we hope that such a log will become significantly more useful as other devices and tools leverage the standard to increase what an individual can do with their ListenLog data. This type of sideways approach holds the promise of planting the seeds of VRM onto lots of devices without requiring the primary application functionality (i.e. audio listening) be purely user-driven. | While tracking listener behavior data is not a new concept, the ListenLog is a novel approach to deploying early VRM functionality. While a simple activity log might not appear as the killer app, it succeeds by putting in place a small piece of user-driven infrastructure into a larger application - one with a promise of relatively wide distribution. Since this infrastructure component will write, store, and share listener activity in an open and standard format, we hope that such a log will become significantly more useful as other devices and tools leverage the standard to increase what an individual can do with their ListenLog data. This type of sideways approach holds the promise of planting the seeds of VRM onto lots of devices without requiring the primary application functionality (i.e. audio listening) be purely user-driven. | ||
A user-driven activity log works well for an application that pulls together audio streams and files from a number of different sources. Of course, online audio providers (vendors in the VRM model) can already track and aggregate listening behavior data, but only for the audio they control. When the user acts as the sole point of integration, pulling together audio from multiple sources, their own consolidated log becomes uniquely powerful. Only when the listener is the point of integration does such an approach yield a new type of value. | A user-driven activity log works well for an application that pulls together audio streams and files from a number of different sources. Of course, online audio providers (vendors in the VRM model) can already track and aggregate listening behavior data, but only for the audio they control. When the user acts as the sole point of integration, pulling together audio from multiple sources, their own consolidated log becomes uniquely powerful. Only when the listener is the point of integration does such an approach yield a new type of value. | ||
== | == Specifics == | ||
Initially, the ListenLog will capture online audio stream and file listening behavior occurring through a specific application and device in a standard format. At minimum, the log will capture audio stream/file identification, user agent, listen start time, listen duration and device location information. Extending this data to incorporate unique device IDs, audio meta data, rating (e.g. thumbs-up/down), referral, or other application behavior data is | Initially, the ListenLog will capture online audio stream and file listening behavior occurring through a specific application and device in a standard format (see the [[ListenLog XDI]] page for an example). At minimum, the log will capture audio stream/file identification, user agent, listen start time, listen duration and device location information. Extending this data to incorporate unique device IDs, audio meta data, rating (e.g. thumbs-up/down), referral, or other application behavior data is under consideration. | ||
The application supporting ListenLog recording capability will host the minimum of user-facing functionality. Specifically, the individual user will be able to choose a digital identity(s) with which to associate their listening data, and can also choose where the data is stored, as it will be dynamically written by the device application to any ListenLog standards compliant service provider (host). | The application supporting ListenLog recording capability will host the minimum of user-facing functionality. Specifically, the individual user will be able to choose a digital identity(s) with which to associate their listening data, and can also choose where the data is stored, as it will be dynamically written by the device application to any ListenLog standards compliant service provider (host). | ||
A separate ListenLog Service interface, perhaps integrated with the ListenLog storage provider, will enable the user to choose if and how to share their ListenLog data, either anonymously or as associated with digital identities. For example, an individual may choose to share all data publicly and anonymously. All users selecting this option would, in aggregate, create a single, public "firehose" feed of all listening activity. It is our hope that third-party developers will offer user-driven functionality based on your ListenLog functionality, helping you share selected data conditionally with vendors for example, or providing agnostic recommendations based on your listening habits. | A separate ListenLog Service interface, perhaps integrated with the ListenLog storage provider, will enable the user to choose if and how to share their ListenLog data, either anonymously or as associated with digital identities. For example, an individual may choose to share all data publicly and anonymously. All users selecting this option would, in aggregate, create a single, public "firehose" feed of all listening activity. It is our hope that third-party developers will offer user-driven functionality based on your ListenLog functionality, helping you share selected data conditionally with vendors for example, or providing agnostic recommendations based on your listening habits. | ||
== Enabled Functionality == | |||
The power of ListenLog is not in the log itself, but what the activity history might enable. As an open standard, the ListenLog format will enable third-party relationship services to be developed for users to interact with. Possible examples include: | |||
==== [[EmanciPay]] ==== | |||
By keeping track of what files, tracks and programs are listened to, users can more easily allocate voluntary payments across properties without resorting to the transaction burden of micropayments. | |||
==== Detached Recommendations ==== | |||
Audio recommendation systems are typically integrated into a single vendor offering and based on your (and your peer's) internal listening behavior. A third party recommendation system could avoid lock-in of data and stimulate competition from pure-play recommendation systems. Additionally, listening behavior would be aggregated across devices, applications, and formats to provide a greater depth and breadth of material to work from. | |||
==== Personal History Search ==== | |||
The ability to apply an "I've listened to this" filter when you perform an audio search. | |||
== More == | |||
* [[ListenLog Meeting Notes]] | |||
* [[ListenLog Identity]] | |||
* [[ListenLog XDI]] | |||
* [[Listen Log]] (a higher-level more general page on this topic) | |||
Latest revision as of 13:40, 13 October 2011
Overview
The VRM ListenLog is a proposed method for integrating simple user-driven functionality into an online audio player device or application. A ListenLog is a consolidated and documented history of an individual's online listening activity. It is simply a recorded activity log, in a standard and open format, capturing an individual's listening actions from multiple online applications. The ListenLog is unique in that its aim is to give the user the ability to accumulate and control the use of their listener activity data. The data is the user's. It does not belong to any vendor or intermediary. The user alone should have control over where the data lives, what applications write to it, what gets logged, who to share it with, and how it can be used. The ListenLog concept was devised in part for the Public Radio Tuner iPhone project, where it is first being introduced. Plans are to put it on other handhelds as well. (And, as an open source project, there is nothing to prevent others from doing what they like with it.)
Purpose & Deployment
ListenLog, or Listen Log is a form of Media Logging. It is required for EmanciPay to work. EmanciPay is a new business model for otherwise free media goods -- one that sharply reduces the frictions involved in paying for media. By increasing the number of people who pay for free media, PayChoice also helps stigmatize non-payment for those goods.
Logging of listening is required to answer all these common questions:
- What was that (program, segment, piece of music)?
- Who was that (host, guest)?
- Who produced that (program, segment, piece of music)?
- When and where did I listen to that?
- How often did I (listen to, watch or read) that in the past?
- Do I have a relationship with the source? (Such as membership, or past transactions.)
ListenLog is a simple utility that does nothing more than record listening data for the user. It will store it in a form that can be crunched in many ways and for many purposes -- all by the user's choice and at the user's discretion. It will be data that can go in any database or spreadsheet. It can also be shared in a selectively disclosed way. (See VRM Principles list and the earlier Principles.) This will make possible a marketplace for third-party services that help both listeners and the institutions with which they relate. (Starting with stations, but also including program producers, artists and others.)
With ListenLog data, listeners can make fully informed choices about how they support streams, podcasts and on-demand sources of programming.
Listeners can also form better relationships with stations and program sources. Membership can come to mean far more than serving as a future target for pitches and billing.
Both Media Logging and EmanciPay are being pioneered with the Public Radio Tuner, which is currently being developed by [PRX] and other partners, including NPR and ProjectVRM at the [Berkman Center]. Neither, however, are to be limited to the iPhone, or any other platform. But the iPhone and the Public Radio Tuner are where we are starting.
There are challenges posed both by the pioneering nature of the work and the limitations of the iPhone.
For example, the iPhone has a tiny memory for data and no persistent and user- (or program-) accessible data store on the host computer with which it syncs through iTunes. But iPhone does provide means for that data to be stored remotely, in a trusted "cloud." For this purpose, PRX has created ListenLog.org as a site/service for storing each user's data and making it available through standard web service interfaces.
Because this distances the user's data from the user's devices, and requires trust in PRX (or any host), questions of trust are naturally raised. These are the same issues raised by any cloud service, including Gmail and Amazon S3. Establishing trust mechanisms -- both technical and contractual -- are non-trivial. But they are also essential for laying the groundwork required for this new business model to work.
History
While tracking listener behavior data is not a new concept, the ListenLog is a novel approach to deploying early VRM functionality. While a simple activity log might not appear as the killer app, it succeeds by putting in place a small piece of user-driven infrastructure into a larger application - one with a promise of relatively wide distribution. Since this infrastructure component will write, store, and share listener activity in an open and standard format, we hope that such a log will become significantly more useful as other devices and tools leverage the standard to increase what an individual can do with their ListenLog data. This type of sideways approach holds the promise of planting the seeds of VRM onto lots of devices without requiring the primary application functionality (i.e. audio listening) be purely user-driven.
A user-driven activity log works well for an application that pulls together audio streams and files from a number of different sources. Of course, online audio providers (vendors in the VRM model) can already track and aggregate listening behavior data, but only for the audio they control. When the user acts as the sole point of integration, pulling together audio from multiple sources, their own consolidated log becomes uniquely powerful. Only when the listener is the point of integration does such an approach yield a new type of value.
Specifics
Initially, the ListenLog will capture online audio stream and file listening behavior occurring through a specific application and device in a standard format (see the ListenLog XDI page for an example). At minimum, the log will capture audio stream/file identification, user agent, listen start time, listen duration and device location information. Extending this data to incorporate unique device IDs, audio meta data, rating (e.g. thumbs-up/down), referral, or other application behavior data is under consideration.
The application supporting ListenLog recording capability will host the minimum of user-facing functionality. Specifically, the individual user will be able to choose a digital identity(s) with which to associate their listening data, and can also choose where the data is stored, as it will be dynamically written by the device application to any ListenLog standards compliant service provider (host).
A separate ListenLog Service interface, perhaps integrated with the ListenLog storage provider, will enable the user to choose if and how to share their ListenLog data, either anonymously or as associated with digital identities. For example, an individual may choose to share all data publicly and anonymously. All users selecting this option would, in aggregate, create a single, public "firehose" feed of all listening activity. It is our hope that third-party developers will offer user-driven functionality based on your ListenLog functionality, helping you share selected data conditionally with vendors for example, or providing agnostic recommendations based on your listening habits.
Enabled Functionality
The power of ListenLog is not in the log itself, but what the activity history might enable. As an open standard, the ListenLog format will enable third-party relationship services to be developed for users to interact with. Possible examples include:
EmanciPay
By keeping track of what files, tracks and programs are listened to, users can more easily allocate voluntary payments across properties without resorting to the transaction burden of micropayments.
Detached Recommendations
Audio recommendation systems are typically integrated into a single vendor offering and based on your (and your peer's) internal listening behavior. A third party recommendation system could avoid lock-in of data and stimulate competition from pure-play recommendation systems. Additionally, listening behavior would be aggregated across devices, applications, and formats to provide a greater depth and breadth of material to work from.
Personal History Search
The ability to apply an "I've listened to this" filter when you perform an audio search.
More
- ListenLog Meeting Notes
- ListenLog Identity
- ListenLog XDI
- Listen Log (a higher-level more general page on this topic)