Next meeting of the TOS/EULA working group: Tuesday, June 30 at 20:00 GMT

[Steven Greenberg]

I'd like to discuss some updates I've made to the document on the wiki, and have some more that I hope to have integrated before the meeting.  

20:00 UTC is 4pm New York, 1pm San Francisco, 10pm Berlin, 6am Sydney (sorry, Elias)

Other time zones: http://bit.ly/jx0ad

Skype: +9900827043965594
Dial-Up: 1-201-793-9022 Room Code: 3965594

[Christian Scholz / Tao Takashi (SL)]

Hi!

Due to being at the EuroPython conference I probably won't make it
tomorrow. But I hope for notes! :-)

-- Christian

--
Christian Scholz
http://mrtopf.de/blog

New Podcast: http://datawithoutborders.net

[Elias Bizannes]

I've made some changes to the draft.

Based on the discussions Christian and I had several meetings ago, he
put to me that meta data shouldn't beas a standalone data type. We
resolved to do some scenario testing, and the following meeting I
discussed with the chair Steve Greenberg that Christian's point was
valid.

I also discovered during my scenaro testing, that the usage of the
metaphor approach was superior, and any attempt to specifically define
technical types of data portability (like export, import, access, etc)
was difficult to apply. This is because each scenario of data usage is
different, and there is no inherent value in trying to define specific
technical means to portability.

As a result I've made the following changes
- Made "identity" and "media" as primary data types. These are
standalone objects, or "assets" of an individual
- Made "meta data" a derivative data type. These can be considered
standalone but in essence they only derive their value if associated
with a primary type ie, the title and tags associated with a photo are
independent data types but useless unless associated with a picture
itself. Arguably, a primary data type + a meta data type are together
functionally considered "information" - but by differentiating the
core data and the meta data this allows a better way of identifying
things. I still think it's important to have recognition of a metadata
type ie, your relationships with friends on a social network are
metadata linking identity objects (you and your friend) --> the
connections are expected to be your data and although you don't own
your friends identity, you do have a right to aligning your identity
profile to theirs to create a connection.
- I've therefore decreased the focus of defining the data types, and
simply flagged the above as helping clarify what's in scope

- Similarly, I've played down the technical definitions of data
portability (like export, import) and simply said they are examples of
data portability (but not definite types and are dependent on the
scenario). So the language is considered "guided" rather than
"definitive".

- I believe the metaphors are the most appropriate way to depict data
portability, because they signify the start of a relationship, the
maintenance of a relationship, and the end of a relationship. This
cycle approach mimics how a user has a relationship with a service
provider. The different cycles reflect the expectations in the
mutually beneficial relationship.
- This approach is also appropriate as it ties with the Kantara
workgroup that was formerly known as the VPI group. Their approach is
for end-users to have a contract that vendors can sign that respects
the usage rights of their data. This therefore is compatible with the
EULA task force which shows the status of the relationship ie, the VPI
group reflects a relationship, but simply has a more definitive
expectation of that specificic type of data portability.
- I believe the three metaphors can be depicted by three icons: "Opens
arms" would be an orange tick; ever-fresh would be a green line with
arrows pointing in both directions; and graceful exit would be a red
cross.

Overall, I believe we have achieved our objective (to build a
conceptual framework) and this can now be released to the world to
further build on it. Below I will describe to practical implementation
of the conceptual work

--------------

Consider three social networking profiles:
- Facebook profile
- MySpace profile
- Orkut profile

Common to all three profiles, you have your name, marital status and
current town of residence.

So on the 30 June 2009, you will see:
Name: Elias Bizannes
Marital status: It's complicated
Current town: Sydney

Now imagine on the 30 July, I updated my Facebook profile to the
following:
Name: Elias Bizannes
Marital status: Single
Current town: San Francisco

...and my Orkut profile on the 31 July to the following:
Name: Elias Bizannes
Marital status: Single
Current town: Oakland

...but my MySpace profile still shows the original profile
information.

Further, let's imagine there is some metadata embed into my social
network profiles. The following is an XML representation (badly
formed!) of my original social network profile

<identity>
<name>Elias Bizannes</name>
<marital status>It's complicated</marital status>
<current town>Sydney</current town>
<update>2009-06-30T08:15:3000:00</update>
</identity>

This group of data is lumped together as a cluster of identity data.
Furthermore, the data has been stamped with the last time it was
updated.

Separately, imagine I have an file stored on my personal website
eliasbizannes.com. It's another XML file which states my current data
portability relationship with service providers.

<facebook>everfresh</facebook>
<myspace>everfresh</myspace>
<orkut>openarms</orkut>

When I updated my Facebook profile, it will check this file and note
that
- I will like Facebook to syncronise my data with myspace in a two way
fashion. They are considered peers with respect to my data.
- I will like Facebook to send updates to Orkut, but I do not want
Orkut to send back to Facebook changes as it's a one way transfer.
Ever fresh means constant updating and sync'ing, whereas open arms
will only receiving updates but will not post updates.

The net result is that
- your Facebook, MySpace, and Orkut profiles on 30 July 2009 are
identical
- your Facebook and MySpace profiles on 31 July 2009 are identical.
But your Orkut profile is different.

Similarly, let's say your Orkut profile has "graceful exit" as a
relationship status with you. When Facebook has an update, it will
ignore Orkut and not ping it with an update. It's been excluded from
the data federation that you permit for your identity data.

What does this mean?
- You allow your social network information to be ported to other
social networks
- You can control how exactly that data flows. You can control if it
affects data stored on the one system or multiple systems.

Of course, the actual implementation is not something the task force
has agreed on as it's not part fo the charter. But hopefully this can
illustrate how to apply the conceptual framework.

[Nicholas Givotovsky]

sorry I missed the meeting today  had hoped to join you on the call - will catch up as catch-up can.. best - nicholas

--
re:defining the digital deal