Difference between revisions of "ListenLog Meeting Notes"

From Project VRM
Jump to navigation Jump to search
(editing...)
Line 1: Line 1:
 
Below are meeting notes and ongoing issues and action item lists. For a detailed description of ListenLog, visit the main [[ListenLog]] page.
 
Below are meeting notes and ongoing issues and action item lists. For a detailed description of ListenLog, visit the main [[ListenLog]] page.
  
===12/12===
+
===1/12===
 
====Parking Lot====
 
====Parking Lot====
 
------------------------
 
------------------------
Line 30: Line 30:
 
* Does there need to be database legal protection underlying data rights access to drive user terms?
 
* Does there need to be database legal protection underlying data rights access to drive user terms?
  
===12/13===
+
===1/13===
 
* How do we make the data inherently more anonymous?
 
* How do we make the data inherently more anonymous?
 
** Match account data between logs
 
** Match account data between logs
Line 64: Line 64:
 
* Draft functional requirements
 
* Draft functional requirements
 
* Doc talk to Berkman legal re: user rights / terms
 
* Doc talk to Berkman legal re: user rights / terms
 +
 +
==1/20==
 +
* There is a core set of things to figure out to proceed with this project. Other things can and should be considered, but aren't critical to building the core aspects
 +
** What data are we capturing
 +
** What format are we sending and storing the data in
 +
** How is this data being transmitted and stored
 +
** How do we maintain integrity, privacy, and required minimum of control (e.g. "delete my data")
 +
** How do we assign identity
 +
 +
* XDI can be used to transmit and/or store; X3 looks promising
 +
 +
* In discussing data capture, Keith argued for being minimal and conservative and providing a mechanism for extending
 +
* Agreement that our proposed data, format, and services will deal with listening attention data only; both for on-demand (file) audio as well as streaming audio
 +
* Open question about whether Sound Exchange / RIAA requires specific formats, if so, might be nice to comply
 +
* XRI be resolved / discoverability
 +
 +
XRI = identifier - resolvable to an XDI endpoint
 +
XDI dictionary - like an XML schema
 +
 +
XRI authority resolution server (open XRI)
 +
- community iname registry
 +
- inumber (this is how you handle reassignment)
 +
- are we doing this on their behalf or are we doing self-registration?
 +
 +
xri synonyms is the answer?
 +
 +
iname registration for digital identity
 +
- might not need an icard selector on the iphone

Revision as of 22:14, 21 January 2009

Below are meeting notes and ongoing issues and action item lists. For a detailed description of ListenLog, visit the main ListenLog page.

1/12

Parking Lot


  • Where is data stored (by default)? Does it sync to a local store or just stream out?
  • Is there any concern from collaboration stations and partners that there's no exclusive access to data / analytics?
  • What data do we capture? Application behavior data in addition to basic listen data? What about rating data? Location data?
    • Should the standard by minimal for extensibility vs. maximal for enhanced value/functionality
    • Privacy concerns (EFF Chair Brad Templeton)
  • Security / encryption on the stored data? Which bits?
  • How best to communicate and promote the ListenLog concept and where the key benefits and differentiators are? How do we address naysayers and differentiate from alternative approaches, e.g. APML?
  • How do we do identity? How do we make it swappable? Do we use icards, openID, Oauth?
  • How do we start the service without identity? (e.g. access to device ID?)
  • Do users have control over what's stored?
  • What's the absolute minimum of device-side functionality?
    • Opt-out(?)
    • Change repository
    • Assign identity
  • Where does legal and TOS come in? (see rights and contracts below)
  • Does anyone enforce standards compliance?
  • Who does the work / coding?
    • PRX + who?
  • Do we think about revenue / sustainability? PRX has two roles here - one to build codebase and standards for storage, the other to think about services and how we'd use the data.
  • Do we do opt out for data capture? (probably yes)
  • Do we provide "public by default," e.g. ubiquitious, anonymous access to the data out of the box (probably no)
  • Can we open source iphone bit? Publicly available libraries?
  • What's in the first release?
    • Should we provide ability for users to release data? How and to whom? What capacity for sharing? What terms? Anon vs. nonanon?
  • Does there need to be database legal protection underlying data rights access to drive user terms?

1/13

  • How do we make the data inherently more anonymous?
    • Match account data between logs
    • Make timestamp and LAT-LONG fuzzy?
  • What data rights can a user authorize for third parties?
    • propagation rights (the grantee can't extend to someone else)
    • public rights vs. directed/granted rights (e.g. for anyone to use vs. for specific entity to use)
      • anon/non-anonymous
      • Most rights issues/rats nests are associated with granted rights
    • How long you can use the data for? Keep the data?
    • Rights to cease use, remove data(?) + confirmation(?)
    • Can't use this to try and find/identify someone - reverse-engineering rights
    • commercial/non-commercial?
    • Contact me (e.g. DNC)
    • Compare to IRB
  • Contract rights
    • Investigate proactively - what is it that pandora might want to do? What is reasonable?
      • give me audio recommendations
      • use for product development
    • Don't cross-correlate/aggregate (e.g. social network correlation, Ben Laurie) - piercing identity/privacy data
    • Endorsement / assignment to my identity

Core Requirements

  • what data is going to be captured
  • where is it stored and in what format
  • how does one identify oneself / assign identity
  • what's the minimum functionality that needs to live on the device
  • what's the minimum functionality that needs to live remotely
  • additional / core functionality to prove value necessary?
  • Determine protections for communication and storage between client app and repository authenticated, encrypted, etc.

Action Items

  • Draft functional requirements
  • Doc talk to Berkman legal re: user rights / terms

1/20

  • There is a core set of things to figure out to proceed with this project. Other things can and should be considered, but aren't critical to building the core aspects
    • What data are we capturing
    • What format are we sending and storing the data in
    • How is this data being transmitted and stored
    • How do we maintain integrity, privacy, and required minimum of control (e.g. "delete my data")
    • How do we assign identity
  • XDI can be used to transmit and/or store; X3 looks promising
  • In discussing data capture, Keith argued for being minimal and conservative and providing a mechanism for extending
  • Agreement that our proposed data, format, and services will deal with listening attention data only; both for on-demand (file) audio as well as streaming audio
  • Open question about whether Sound Exchange / RIAA requires specific formats, if so, might be nice to comply
  • XRI be resolved / discoverability

XRI = identifier - resolvable to an XDI endpoint XDI dictionary - like an XML schema

XRI authority resolution server (open XRI) - community iname registry - inumber (this is how you handle reassignment) - are we doing this on their behalf or are we doing self-registration?

xri synonyms is the answer?

iname registration for digital identity - might not need an icard selector on the iphone