Difference between revisions of "ListenLog Meeting Notes"

From Project VRM
Jump to navigation Jump to search
m
m
Line 2: Line 2:
 
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.
  
===1/12===
+
==/12===
====Parking Lot====
+
===Parking Lot===
------------------------
 
 
* Where is data stored (by default)? Does it sync to a local store or just stream out?
 
* 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?
 
* Is there any concern from collaboration stations and partners that there's no exclusive access to data / analytics?
Line 31: 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?
  
===1/13===
+
==/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 53: Line 52:
 
** Endorsement / assignment to my identity
 
** Endorsement / assignment to my identity
  
====Core Requirements====
+
===Core Requirements===
 
* what data is going to be captured
 
* what data is going to be captured
 
* where is it stored and in what format
 
* where is it stored and in what format
Line 62: Line 61:
 
* Determine protections for communication and storage between client app and repository authenticated, encrypted, etc.
 
* Determine protections for communication and storage between client app and repository authenticated, encrypted, etc.
  
====Action Items====
+
===Action Items===
 
* 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===
+
==1/20==
 
* There is a core set of things to figure out to proceed with this project. We'll focus on those:
 
* There is a core set of things to figure out to proceed with this project. We'll focus on those:
 
** What data will we capture?
 
** What data will we capture?
Line 94: Line 93:
 
** Simpler way?
 
** Simpler way?
  
====Action Items====
+
===Action Items===
 
* Diagram high-level architecture
 
* Diagram high-level architecture
 
* Prep for discussing identity options next week
 
* Prep for discussing identity options next week
 
* Look into Sound Exchange reporting formats and PBcore formats
 
* Look into Sound Exchange reporting formats and PBcore formats
  
===2/26===
+
==2/26==
====Action Items====
+
===Action Items===
 
* Make some design decisions to get us started with POC development
 
* Make some design decisions to get us started with POC development
 
* Create a boxes and arrows diagram to help represent the data sets and functional entities and where they live
 
* Create a boxes and arrows diagram to help represent the data sets and functional entities and where they live

Revision as of 15:32, 3 March 2009

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

/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?

/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. We'll focus on those:
    • What data will we capture?
    • What format will we send and store the data in?
    • How is this data being transmitted and stored?
    • How do we maintain integrity, privacy, and provide the required minimum of user control (e.g. "delete my data")?
    • How do we assign or associate identity?
  • 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
  • XDI can be used to transmit and/or store; X3 looks promising
  • 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)
  • At what level will we register?
  • How will we maintain this registry?
  • How will other applications that write to LL handle XRI? Will they resolve to their own server?
  • What about dupes?
    • xri synonyms is the answer?
  • Use iname registration for digital identity?
    • might not need an icard selector on the iphone
    • Simpler way?

Action Items

  • Diagram high-level architecture
  • Prep for discussing identity options next week
  • Look into Sound Exchange reporting formats and PBcore formats

2/26

Action Items

  • Make some design decisions to get us started with POC development
  • Create a boxes and arrows diagram to help represent the data sets and functional entities and where they live
  • Have a convo with berkman RE: servers and hosting the user data
  • Identity + claimant - how best to handle user identity (focus on near-term)?
  • XDI dictionary - designing what info is sent to log, registrants, etc.
  • Revisit user functionality on wiki - what do we really need to do? What role should XRI/XDI (and existing OpenXRI code) do for us here?