See also: IRC log
<danbri> hi folks
<danbri> i might be irc only today i'm afraid (drupalcon multitasking)
<rreck> hhalpin did you send out minutes to approve?
<rreck> low voter turnout
<rreck> looks like the past minutes are not posted yet?
<pchampin> it is :)
<rreck> looks like the webpage links to minutes are wrong, many link to jul 22
<pchampin> the last minutes I recieved are http://www.w3.org/2009/08/19-swxg-minutes.html
<pchampin> and the link sZ works
links to agenda, etc should be OK here - http://www.w3.org/2005/Incubator/socialweb/wiki/Telecons
<hhalpin> Last meeting minutes are linked from agenda
<rreck> you mean victim
I don't mind if nobody else wants to.
<rreck> +1 tinkster
<DKA> ScribeNick: tinkster
<DKA> Scribe: Toby
<rreck> i saw dan perform some incantation
DKA: Let's kick off. First item on our agenda is (as usual) to review last week's minutes.
<danbri> didn't we do webfinger last week?
<rreck> +1 approve minutes
<bblfish> yes, I understood sparql webfinger right after the end of the conf
scribe: Any objections to approving last week's minutes?
<rreck> +1 meet again
scribe: Moving swiftly on: general organisations. Still not completed my action on OSLO/geolocation
scribe: Focus today on discussing use cases and results of poll. Move onto that?
Harry: that sounds fine.
Harry: Most productive to continue from last meeting, walking through use cases.
Harry: Most use cases have a champion. Some can clearly be dropped - bidirectional; drag and drop; etc. Some have almost unanimous support. Some more mixed.
DKA: CRUD is on a much lower level than the others; can't really be argued against.
Harry: Last time we got up to "Adding new features to Social Networks" case.
<hhalpin> Developers should be able to expose existing data in new and interesting ways. But at the same time, people should be made aware of how their data is being used, and updated when this changes
Harry: To me this is talking mostly about widgets.
<hhalpin> Maybe we should separate those out
DKA: There's widgets as in browser-widgets, but also those that live on the page, and APIs, etc. This encompasses both of those aspects.
Harry: should separate out?
<Yuk> ??P36 is me
DKA: Not so sure they should be separate. They seem related.
<hhalpin> The issue with this usecase is needs a champion
<rreck> i think there should be an opt in policy about newly added functionality
<melvster> I'll champion this one if no one wants to
hhalpin: Anyone want to champion it?
DKA: yay for melvster championing.
<hhalpin> To find the original source of a meme or piece of information.
hhalpin: Tracking of sources use case. We want to find the original source of the information.
tinkster: am happy to champion this use case.
<rreck> i just disagree with christine
hhalpin: Multiple identities / anonymous identities - merge?
<hhalpin> To provide information without being the attributed source or “whistle blower”.
<hhalpin> Anonymous information usecase
<hhalpin> Provenance is effectivelzy blocked or unknown, i.e. anonymous, or anonymous identity.
hhalpin: this could also be considered to be merged with source tracking / provenance.
<rreck> yeah provenance is an anonymous node
DKA: curious to understand the argument against.
<rreck> i want to share it, just not have it attributed to me
oshani: there could be a set of people you are comfortable with sharing information; other people not so much; so have two identities - a real one and a pseudononymous one.
<hhalpin> anonymous could also be wikileaks-style, i.e. truly anonymous
DKA: Not sure this answers the whistleblower use case completely anonymously.
<hhalpin> this can be accomplished technically via messages sent out over mixminion for example
<rreck> yeah someone on my street put up a sign saying the water wasnt safe. im sure it made him a target
DKA: Whistleblower use case more interesting if we look at it from a gov't agency point of view.
<bblfish> what is the problem with having identifiers for people with no info linked to that id?
<bblfish> then you get id, and anonymity
<pchampin> +1 bblfish
hhalpin: if rreck wants to champion it, we should keep it around, but note its links to related use cases.
<jsalvachua> +1 bblfish
<hhalpin> I think if Ronald wants to champion if Ronald making sure its suitable, especially if we can track back to merging source...
oshani: From a social net point of view, what does this encompass? How does it relate to e.g. Webcams.
<rreck> i want to protect my friends from something, but i dont want it tracked to me
hhalpin: there exists technical infrastructure that can provide pretty good anonymity.
<rreck> i think its null provenance
<rreck> ill talk to oshani offline
hhalpin: should champions be rewriting use cases, cleaning up, fleshing out?
<hhalpin> ACTION: rreck to flesh out anonymous usecase connecting to multiple identies and null provenance [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action01]
<trackbot> Created ACTION-71 - Flesh out anonymous usecase connecting to multiple identies and null provenance [on Ronald Reck - due 2009-09-09].
<hhalpin> "Removing Data or Changing Data permission" Use-case
hhalpin: next use case is removing data / changing permissions use case. Most people not in favour of keeping. Perhaps use case is too abstract?
<bblfish> there really is not much text at http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#Removing_Data_or_Changing_Data_permission
hhalpin: relates to the more
concrete 10 year and takedown cases.
... Merge these three use cases?
<hhalpin> Document Takedowns Propagators Use-case
<Adam> are all of them really related to the life cycle management of data?
DKA: Seems sensible to me.
<rreck> i think all this case could be solved with obligatory metadata stating time to life
hhalpin: 10 year use case had a lot of support, no champion. Would oshani like to incorporate this into document takedown?
oshani: yes, I can do that.
hhalpin: 10 years is just a time-related document takedown.
bblfish: if you do everything by reference (rather than by copying) then you only need to take down the original.
<hhalpin> ACTION: Oshani to merge document takedown with time-related takedown "forget this in ten years" and more general concept of data removal. [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action02]
<trackbot> Created ACTION-72 - Merge document takedown with time-related takedown "forget this in ten years" and more general concept of data removal. [on Oshani Seneviratne - due 2009-09-09].
DKA: example is a photo that I've
taken, which includes bblfish's face, and bblfish annotates it.
Someone else in the photo asked DKA to take down the
... DKA should be able to remove photo. What happens to annotation? What is bblfish's right to the image vs DKA's right?
<rreck> DKA's example happened to me
bblfish: it's complicated - that's true.
<hhalpin> "Last Will" usecase
hhalpin: last will and testament use case.
<rreck> time to life for information
<rreck> obligatory metadata
hhalpin: very popular, but
lacking a champion.
... perhaps should be merged with takedowns? but it's a very special case.
<rreck> i will champion that but solve it with obligatory metadata
<MacTed> everybody's gonna... :-)
DKA: this is something we'll all end up facing!
DKA: worth keeping on its own. volunteer champion?
MacTed: this could be solved by including a time-to-live (TTL) for every piece of content.
<hhalpin> is an option on time-to-life?
<bblfish> yes, but it is weird. I think that removing information is problematic.
everyone: "if you know the exact time of your death".
MacTed: copyright is based on death date.
<Yuk> it also happens that one's parents/friends want to see his/her history
tinkster: it's based on the author's death date, but calculated *after* death. (currently)
Ah, so MacTed above is rreck. (Note to editor!)
(Or maybe not?)
<hhalpin> Hmmm...it seems like what we need to do next is move to group permissions
<Adam> is some of that regarding permissions of access versus time of life?
MacTed: TTL could be fragmented by different groups.
<rreck> that is an awesome point, its much more complicated than i had appreciated
<jsalvachua> unix like permissions?
DKA: Death use case needs a
champion, even if nobody wants to be the "champion of
... I'd be happy to take it on myself.
<rreck> one of my FB passed, and i wondered what will happen to his page
<hhalpin> ACTION: DKA to take on "Last Will and Testament Usecase", referencing it as both a legal issue and with regards document takedown [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action03]
<trackbot> Created ACTION-73 - Take on "Last Will and Testament Usecase", referencing it as both a legal issue and with regards document takedown [on Daniel Appelquist - due 2009-09-09].
DKA: What happens right now on social networks when people die? What happens if someone is believed dead, their account deleted, and it turns out they're alive?
<MacTed> mostly someone finds their username/password, and assumes ownership of the account ...
tinkster: there exist facebook memorial pages (I'm told)
<danbri> i'd like to spend some time chasing up this issue, seems a useful kind of thing for w3c to investigate
<MacTed> if that doesn't happen, most accounts I've known have just sat there untouched (sometimes years) like any other inactive
hhalpin: multiple identities use case. champion bblfish?
<hhalpin> "Multiple Identities" Use-case
<Yuk> Social network for the dead Respectance crosses the ocean http://thenextweb.com/2008/10/03/social-network-for-the-death-respectance-crosses-the-ocean/
<hhalpin> Sort of built from multiple identities over multiple networks to metadata about the management of data over multiple networks to access control.
hhalpin: Maybe this could be the starting point for other use cases.
<MacTed> demerits for me, I found no window to review/restructure :-(
hhalpin: e.g. identities on mutiple networks.
bblfish: Multiple identities seems like a good idea - easy to do.
<rreck> acceptable use is a problem, i dont think FB let's you do it
hhalpin: Could you maybe merge this with no-password use case?
<hhalpin> "Using a web service should not involve password or account name creation" Use-case
<hhalpin> but these seem kinda of technically separate
<hhalpin> so keep them separate?
<rreck> tons of cross talk
bblfish: the user not needing to have a password doesn't mean they can't identify themselves. It's a question of ease-of-use. A bit technical.
<Adam> think its henrys line
bblfish: repeated setting up of accounts is unnecessary and tedious.
<hhalpin> are we losing bblfish?
bblfish: data portability problem?
hhalpin: so bblfish wants to keep multiple identities and passwordless use cases separate?
bblfish: yes. latter is about ease of use.
<MacTed> sounds like OpenID?
<jsalvachua> sorry have to leave, see you.
<rreck> tough to hear agreed
<bblfish> another use case that this makes me think of is: Identifiers on SN should not be resold to other people, as this would mess up the web of relations on the web. Eg: people saying they are firends of http://facebook.org/joe#me and then this being reassinged to Joe BadGuy
DKA: problem with zakim
... let's move on; for now Henry as champion for multiple identities.
<rreck> yes better
<bblfish> yes, the point is that the DataPortability group have mentioned that loggin in to every web site is a big problem
<bblfish> This is solved by OpenId, Passport, foaf+ssl
hhalpin: next use cases are all about group access control.
<bblfish> the data portability video: http://blogs.sun.com/bblfish/entry/data_portability_the_video
hhalpin: first is more abstract; second is the concrete example of family-access for a resource.
<rreck> agreed kinship is cultural
hhalpin: Most comments suggest merging these.
<hhalpin> Distributed Group Access Control" Use-case
DKA: who would agree on what a family is? link identity to genome?
hhalpin: who will champion this/these use cases?
<hhalpin> ACTION: bblfish to merge Family and Group access usecases [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action04]
<trackbot> Created ACTION-74 - Merge Family and Group access usecases [on Henry Story - due 2009-09-09].
bblfish: yes, I'm championing this. Don't need to link in genome (scribe notes that FOAF does have an appropriate property) - just need to link to your family.
<hhalpin> Intransitivity of Policies Applied to Social Network Data" Use-cas
<rreck> but family markedness is cultural
hhalpin: intransitivity use case.
<rreck> some cultures mark siblings but not gender
<danbri> (tinkster - new foaf properties can be had for as little as 5 euros... send me mail :)
<hhalpin> Current social networking platforms implement very rudimentary data usage policies. These mostly focuses on the immediate individuals concerned and do not have much consideration about the data transfer beyond them. Policy conflicts are also not properly handled. If the policies applied to social networking data are made to be transitive, we can make sure tha
oshani: facebook quizzes - I'm not just giving out my own data, but my friends' data. This is a problem.
<rreck> yeah that is a problem
<danbri> (ah, i read "doesn't" :)
<danbri> (yeah, dnachecksum started as a joke, but i think a few folk would like a real one!)
<Yuk> can the friends choose not to have their data being taken from one website to another?
DKA: oshani, could you find a link to quizzes example?
<hhalpin> ACTION: oshani to flesh out "Intransitivity of Policies Applied to Social Network Data" [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action05]
<trackbot> Created ACTION-75 - Flesh out "Intransitivity of Policies Applied to Social Network Data" [on Oshani Seneviratne - due 2009-09-09].
hhalpin: bidirectional use case - everyone agreed to drop it. too vague?
<hhalpin> ACTION: hhalpin to drop bidirectional use case [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action06]
<trackbot> Created ACTION-76 - Drop bidirectional use case [on Harry Halpin - due 2009-09-09].
<rreck> peer pressure
hhalpin: virtual private organisation use case - create a temporary internal (or cross-organisation) network.
<hhalpin> "Virtual Private Organization" Use-case
<hhalpin> No champion
hhalpin: make sure it doesn't leak data.
<hhalpin> I thought it came from joaquin...
DKA: Isn't this the corporate SN use case?
hhalpin: related to that heavily.
<bblfish> I suppose this is also very similar to "Distributed Group Access Control"
<hhalpin> it is very similar to distributed group access contol.
Adam: I can champion this use
case. Can look at this two ways - internally, people could
create their own groups, which they could make private (even
within the company) or not.
... Or is this more complicated.
DKA: It's pretty bare-bones right now. It seems to point more to organically-growing networks.
<pchampin> sorry, I have to leave
<rreck> groove does what you are describing
<hhalpin> take care pchampin!
Adam: if you were to create one of these private virtual organisations, people would need to agree to its terms. Right now, our IT dept can create private organisations like this, and use the group to post some specific public content too.
<hhalpin> maybe add links to Distributed Access control?
DKA: Can you add this as a sub-usecase?
tinkster: if what Adam describes could also take in people and departments at other organisations too.
bblfish: related to distributed access control, which would be an enabling technology for it.
DKA: we're at the end of our slot.
<rreck> we did pretty well getting through them
<rreck> bye DKA
hhalpin: three more use cases to go through. Should we go through them now?
<rreck> so keep geo is clear
<bblfish> +1 for talking about these now
<hhalpin> ACTION: Adam to work on fleshing on "Virtual Private Organisation Use Case" reference distributed data access control policy [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action07]
<trackbot> Created ACTION-77 - Work on fleshing on "Virtual Private Organisation Use Case" reference distributed data access control policy [on Adam Boyet - due 2009-09-09].
<bblfish> did we doo the Too Many Channels?
hhalpin: geo use case. Inferences on location-based contextual data. We should have privacy controls on this, but should be able to share it if we want. Relates to portability and access control.
oshani: happy to champion this. can't see anything to merge with.
<hhalpin> "Too many channels" can be move across different channels
<hhalpin> ACTION: hhalpin to drop "too many channels" [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action08]
hhalpin: "too many channels" use case - allow data to move across between different SNs. Pretty much covered by other portability and access use cases. We should drop.
<trackbot> Created ACTION-78 - Drop "too many channels" [on Harry Halpin - due 2009-09-09].
hhalpin: Data protection use case. This is not easy.
<oshani> hhalpin, nope, I am not a champion for that
bblfish: the question is very interesting, but I don't know what the answer is.
<hhalpin> Alice is not a member of a given walled-garden social network and Bob tags her in an image from an event they were both at. Given that Alice finds out about this image, through word of mouth or by whatever means, should she be able to ask for her depiction to be removed? If she somehow manages to confirm that indeed it was a picture of her, should she be abl
hhalpin: similar to document takedown perhaps, but also need to look at legal requirements.
<oshani> I think I am
<Adam> data protection to me infers controlled access
<hhalpin> controlled access
<hhalpin> Could be kept separate there...
<Adam> is this use case more about Alice's right to have the image removed?
<bblfish> Could be an intro to a number of use cases
oshani: this is different fron document take down in that it's initiated by an outsider.
hhalpin: perhaps it needs a bit of rephrasing.
bblfish: I'll think about that.
<hhalpin> ACTION: bblfish to relabel data protection use case to be about controlled access and takedown to data "about" you [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action09]
<trackbot> Created ACTION-79 - Relabel data protection use case to be about controlled access and takedown to data "about" you [on Henry Story - due 2009-09-09].
<rreck> +1 yeah
<bblfish> we have a few extra use cases that were added
hhalpin: I think we've managed to drop three use cases and merge about four.
<rreck> what about the shill one? can we keep it
hhalpin: Next week after a bit
more boiling down, we can maybe freeze the use cases and start
drafting a full document.
... Document structure maybe: identity, metadata, access?
<hhalpin> do you know who added that one?
I think I might have added one - commercial incentives for social networks to open their data.
<Adam> yeah, toby did and there was one other as well
<bblfish> this one perhaps?
There was bblfish's plastic toy one too.
<rreck> hhalpin: i added shill
<Adam> i'm happy to champion the Social Web for Business Intellegence
<bblfish> was this one new too http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#Shills_Posting_False_Information_to_Dilute_the_Truth
<hhalpin> oshani and henry
tinkster: I don't have any special interest in the use case I've recently posted - just wrote it up as I'd been actioned. Someone else can champion.
<bblfish> yes, I can do that.
hhalpin: bblfish and oshani to edit full use case document?
oshani: happy to help.
bblfish: not edited a w3c doc before.
<bblfish> don't think I did edit a doc
<bblfish> apart from wiki
hhalpin: I'll show you the process next week. Draft it on Wiki; cut out HTML and put it on CVS; then edit it from there.
<hhalpin> ACTION: Explain to henry and oshani doc editing process for usecases [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action10]
<trackbot> Sorry, couldn't find user - Explain
<hhalpin> ACTION: hhalpin explain to henry and oshani doc editing process for usecases [recorded in http://www.w3.org/2009/09/02-swxg-minutes.html#action11]
<trackbot> Created ACTION-80 - Explain to henry and oshani doc editing process for usecases [on Harry Halpin - due 2009-09-09].
hhalpin: that's all folks.
<hhalpin> Meeting adjourned
hhalpin: sorry for overrunning.
<bblfish> ok by
<rreck> i wont be here next week.
<hhalpin> trackbot, end meeting