The Second Data Sharing Summit was a great success here are all the notes summarized along with the links to the wiki. If you were in a session feel free to add more content to the wiki. We are sending out a survey in the next day and are currently planning on moving ahead with a 3rd summit in September a year after the first one.
Data Sharing Events (link to wiki)
Data Sharing Events are independent open gathering spaces where all parties interested in challenge of data sharing can work together.
* Affiliate with a something like IC to build credibility
* Do AGAIN in SEPTEMBER.
Friend Connect etc. (link to wiki)
- Friend Connect is a Platfrom support of OpenSocial, not a data collection exercise
- Makes any site an OpenSocial Container
Activity Data (link to wiki)
- More Information / Discussion is needed around the rules for exposing activity beyond that which is avaliable through RSS, APML, etc. (i.e. how to promote and standardize the sharing of activity data which is avaliable behind the wall, through oAuth and other standards)
- Contact of the stream matters more that delivery mechanism
- People who are consuming the new structure will likely encounter new types of Activity Structures
Digital Public (link to wiki)
- The models of people in our heads don’t fit into schemas.
Linked Data (link to wiki)
Presentation will be up on http://blogs.sun.com/bbefish
* Demo of http://summer.dev.java.net/Addressbook.html
* Illustration of distributed social network
* How to add security
What’s Real & Tech Best Practices (link to wiki)
- Use OAuth & Portable Contacts
- Tech Best Practice Will be updated
MySpace Profile (link to wiki)
- JSon (Open Social), hCard | XFN or FOAF, SemWeb, OpenDD, Portable Address Book (Plaxo)
- Persistent Data Agreements
- User Types
Personal Address Manager using ID-WSF Working Demo (link to wiki)
- Discovery of Delivery Service disc
- Clear use-case and flow
- Discussion of iCard and point of “mosaic” authorization (mashup of dereferenccable claims)
R-Cards Demonstration and Discussion (link to wiki)
- R-Cards enable a ‘feed’ not just claims
- Setting up the relationship is:
* different and positioned orthogonal to login.
* sometimes longterm (not necessarily continuous), or 1x, or short term.
- R-Cards need a common data format (or formats) for RP’s
- 1 issuer, multiple claims (links) to multiple sources
(pagan -> ptolemic -> copernican -> newtonian -> einsteinian)
Event Attendance Data Sharing (link to wiki)
- Add event data API to Open Social Spec
Service Providers Matrix From Data Sharing Summit (link to wiki)
This Group Session was to create a Service Provider grid that illustrated the state of what features are available and if providers are using open standards to implement them.
Grid as produced in the session can be accessed here: (click on Service Provider name along the top to see what data was inputted)
-NOTE: Since this data was put on the grid by both representatives of the service providers as well as other attendees at the Summit- this data is not verified
Daniela Barbosa of the DataPortability Project Group has volunteered on behalf of the Data Sharing Summit and the DataPortability group to find a home for this grid so that it can be verified and expanded upon. Information to be posted here as that is finalized.
Laws of Data Sharing From Data Sharing Summit (link wiki)
Jeff Hodges and Bob Blakely
Key words and phrases
- Rights (legal)
- social graph
- social contract
- Permissions Metadata
- Open XML format for contact info
- Delete Account
- What expectations are being set?
- Whose expectations Matter?
- How do we avoid confusion?
- What confusion has to be overcome?
- What language is “product specific” and what is “market” specific?
- How does “identity”, or the understanding of identity, relate to the benefit and threat of data sharing.
- What should be my expectation about “private” data
- What datasharing norms “cultural”
Principles of Data Sharing
- Data Sharing principles should follow social norms — or at least not be destructive of social norms.
- Context is critical to decisions and expectation about the sharing of data
- Expectations about sharing should be clear to the parties…[and preserved “downstream”]
- There can be no expectation of “private” information and all expectations should operate accordingly, unless modified specifically by social contract
- The community should support standard “best practices” and policies about preserving “permissions”
- Bob Blakley and Dan Carroll to follow up with Mary Rundle about work on Creative-Commons-like icons for Data Sharing.
- Compile a bibliography of existing work around data sharing.
Some additional comments:
- This isn’t exactly a new topic. Lots of existing organizations who are already dealing with issues around data sharing.
Data Sharing and Privacy (link to wiki)
The common stories about social network portability are all about letting data flow freely. There are many purposes — personal privacy; community norms; legal risks; business competitive issues — that might cause people to want use discretion and context in social network sharing. In this session, we’ll brainstorm stories for social network data sharing that incorporate concepts of privacy and context.
Everything is locked down, private, non portable. Or everything is open, public, and free-flowing.
But data sharing and privacy are not black and white. In real life, people share and present information based on social context. There are gradations of privacy and information sharing.
There are interesting social trends as people negotiate the increased default level of fame in internet life. And cautionary tales about data sharing gone wrong.
There are times when it is right to share data in a way that preserves privacy. Family members use different photo services, and want to share photos with each other but not the rest of the world. A group working on mergers and acquisitions absolutely needs to keep information confidential. In these cases one give permission to family, friends, or business associates based on membership in a group.
Signal to noise, social context
There are many circumstances where information isn’t truly private. But people choose to share with smaller groups. Someone doesn’t want to bore all of their friends with information about knitting or rock climbing, when that information is relevant only to a few. Information about one’s political or religious affiliation isn’t a secret, but it may not be the information one chooses to share when meeting new people at a professional conference. In these cases, it would be useful to have the ability to create tags for the relevant groups, and share by tag. The tags can capture the nuances of subgroups: knitting hats vs. knitting sweaters, say.
There are circumstances when people want to start by sharing with a smaller group, and invite more people. Or start by sharing a little bit of information about common interest, and later share more sensitive information.
The signal to noise and progressive disclosure patterns are about the person sharing information. Stream filtering is for the recipient. Sometimes one wants to “people watch” a diverse stream of information. And sometimes one wants to focus on the current work project, or upcoming social events. Stream filtering is used by individuals who want to apply a context to the information they receive.
People use identifiers — dress or email address — to represent more than one persona. The same person wears different clothes, with co-workers, at a customer meeting vs. a barbecue.
Personal vs. admin control
In organizations, there are some things that an individual may want to control, and some things that admins want to control. A person might want to share soccer pictures with the soccer league. An admin may want to ensure that people aren’t sharing the sports illustrated calendar widget.
Reuse of Shared Information
As feeds for status and information shared in one service with its given context are used in different services and contexts there are increasing difficulties thinking through the implications of extended use and reuse of shared information. Often Facebook or Twitter (as example) status messages are pulled into Skype, but the contexts can be quite different as one is playful and the other is business context and the same message that is humorous in one can be damaging in the other.
ON THE INTERNET, EVERYONE IS FAMOUS
We talked about people’s experiences handling the increased visibility of internet life.
Managing one’s reputation
People share about their experiences in order to get their side of the story out and create a public image. Among digital natives, “it’s not a real breakup until you’ve listed it on facebook.
Before the internet, there were only a small number of people who had more followers than people can confortably manage socially. Now many more people do. More widespread fame means that more people have the issues with stalkers and pestering fans.
Cautionary and instructive tales
At the session at the data sharing summit, the conversation turned to cautionary tales about social data sharing gone wrong.
Failed white lies
Someone begs out of a work-related social event by claiming the flu. His boss discovers a picture on flickr of the guy wearing a skirt and holding a drink. The picture is timestamped at the same data as the work party. His boss sends him a note suggesting that that may not be an effective way to recover from the flu. The lesson here is that some things that feel private are more public than we think.
Social network molting
It is socially awkward to unfriend people. Some people get around obsolete lists of friends by “forgetting” their password and needing to invite their current lists of friends with a new password. The lesson is that declared, public friends lists are inherently awkward.
The ex-girlfriend effect
The list of “people you should know” in social network recommendations often includes exes and enemies. These are people who are part of your social graph – but you are not connected to directly. The algorithm doesn’t know that some gaps in the social graph are deliberate.