See also: IRC log
<trackbot> Date: 03 November 2009
<rigo> use cases for social web from primelife: http://www.primelife.eu/images/stories/deliverables/h1.2.5-requirements_selective_access_control-public.pdf
<rigo> see http://www.primelife.eu/
<FabGandon> Claudio Venezia introducing himself
<FabGandon> Tom (?) from NTT communications
<DKA> SWXG Wiki: http://www.w3.org/2005/Incubator/socialweb/wiki/Main_Page
<FabGandon> Adam Boyet from Boeing
<FabGandon> Rigo from W3C dark side of the law
<FabGandon> Rigo presents Prime Life and mentions its use cases in particular the problem of taking down the walls of the walled gardens
<FabGandon> "PrimeLife - Bringing sustainable privacy and identity management to future networks and services"
<FabGandon> Adam presenting the inSite plaform internal tool of Boeing
<FabGandon> Vagner talking head of W3C Brazil office
<hajons> Håkan Jonsson (hajons), Sony Ericsson
<VagnerW3CBrasil> Vagner Diniz is the head of W3C Brazil Office, joinning thhis session to know what is going on, particular interest in social web in mobile web
<VagnerW3CBrasil> ... and deployment of social web in W3C Brazil Office
<FabGandon> Yoshiaki internal student of W3C/Keio Univ
<martin> Martin Higham - Ocasta Labs
<rigo> I presented Primelife use cases that _exclude_ tearing down the walls
<FabGandon> Christian de Sainte Marie (RIF WG) just joined as an observer.
<FabGandon> Scribe: FabGandon
DKA flipping the agenda ; want to start with the use case documents.
User stories : http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories
<DKA> DanBri let me know if you want to skype in to our lovely session.
user stories are split e.g. http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories/BusinessIntelligence
<danbri> it's dinner time here soon unfortunately, perhaps I watch by IRC and jump in if something specific crops up?
DKA: users Users stories are to create a picture of the social web for the users ; looking at it from a user experience
Rigo: to get momentum we need to also include the social web makers in the picture
Fab: +1 for scenarios including all the people impacted by the stories
DKA: yep, service providers must be included too in the scenarios
Hakan: should we include third-party tools developers?
Rigo: PrimeLife developed Persona we can reuse.
DKA: Actors: people (end-users),
service providers, developers (3rd party)
... looking at the use cases one by one.
DKA reading use case "Download your data"
DKA: we didn’t mention taking the data and uploading them in to another service ; should it be part of it?
FabGandon: is this part of another Use case ? if so is there an opportunity to merge them?
DKA: is this about having a unified API to the social web ?
FabGandon: API (such as in the CRUD scenario) + Format and model (as in FOAF + Relationship)
DKA: Difference between having interest in data and having the ownership of data.
<rigo> the PrimeLife personae are published at http://www.primelife.eu/images/stories/deliverables/personas_primelife.pdf
Rigo: data self determination says person data is mine ; every where except in the US
Information self determination : http://en.wikipedia.org/wiki/Informational_self-determination
DKA: Alice becomes a member of a social network and populate here profile ; Bob connects and see here phone number ; is the phone number Alice’s data or also Bob's ?
... if you have spread data you have a right to get it back, modify, etc.
... data is mine and have a say on this data
FabGandon: application of the CRUD scenario http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#CRUD_Operations_on_Social_Data
DKA: Data copied from Alice’s by Bob are still Alice’s data?
Rigo: if its only Bob, this is
private data of Bob so there is nothing you canb do
... if the data are captured and kept by a Telco company then there is a problem ; no longer private copy of someone.
... in the case of Bob's copy there is no legal aspect to it.
... in the case of a Telco then there is a legal aspect to it.
DKA: DRM ?
Rigo: no privacy issue about this particular use case.
<rigo> I need to go to a telco
DKA: data + policy
FabGandon: see also Intransitivity of Policies Applied to Social Network Data http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#Intransitivity_of_Policies_Applied_to_Social_Network_Data
Hakan: “downloading” does not describe the intent of the user.
Adam: the use case even talks about aggregating
Rigo: opportunistic use of data ?
DKA: Changing the title to "Reuse your data" quote "I have made the change because I am God"
Now talking about Drag and Drop http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#Drag_and_Drop
Ann: not really different from previous use case
Adam: it is about adding information.
Ann: another use case would be
filling the blanks of some data I have.
... merging with data I have
Hakan: isn't it ease of use use case?
DKA: ok we should merge both use cases.
Liking to a remote Friend http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#Linking_to_a_remote_friend
Adam: connection request across networks.
Ann: “establishing a connection across networks” since the notion of request is dependent on some application.
Martin: follow and friendship are very different.
FabGandon: slash dot has "foes" that you won't find in Facebook.
Martin: the application you use to set the link will impose the type of link you set.
DKA: different kinds of links.
Martin: social network B will impose its rules.
DKA: Social network B needs to know the request and decide to grant it or not.
Adam: Joe will thus appear as a
User of social Network A although he does not use it?
... the social networks are actors.
DKA editing the page as we speak.
DKA: missing use cases : foe, blocking, ...
Adam: current text is in conflict with post-condition
Hakan: post condition should state what the social networks A and B claim about Alice and Joe
DKA writing alternative paths.
Adam: if I am on several network which one should deal with my request?
BREAK until 11AM
<mischat> right i am to treck to wimbledom to lug boxes half away around london
<mischat> wrong window:)
<danbri> btw if anyone is in Montreal, identi.ca / statusnet are hiring --- http://jobs.status.net/
dka: let me tell you where my
cursor is ... alternative path 2
... alternate path 2 needs to be filled out a little bit more so that SN B needs to find out more about SN A
martin: Alice request on SN B to
connect to Joe (who is on SN B), she provides her SN A identity
when doing this
... SN A asks/confirms that she did make the connection request on SN B. Alice confirms with SN A. Joe appears on Alices connections in SN A
... thats the basic course of events .... then there the case where SN B asks Joe if he wold like to connect to Alice as well
rigo: the desire of the business model is that SN A typically wants to rope in the user from SN B
martin: thats not the desire from the user
dka: captured that as an alternative path #2
oops, wrong URL
dka: the thing that makes
connecting connections across social networks (SN).. both SN
providers need to be aware
... even in an asymetric relationship, there is some symetry that SN B needs to know about that request, even if it doesn't need to approve
... thats the kind of leap we've been making
timbl: one way alice can tell sn
b, or a third party could crawl the web
... you could ask who's friending me, you could do that without coperation of the sites
dka: so you're saying another alternative path that SN B could only find out after the fact
timbl: another thing, you could send the requst by public email, alice could send it to bob's email
<timbl> Currently for example qdos.com has a reverse friend lookup serviuce over the FOAF graph
rigo: the notion of friend is a
central one ..... in that the thing you attch to when you
arrange a whole set of policies
... the act of making friends means that Alice can now set an access policy, that means that it would have to go in to the access control system of SN A .. in this case SN A would have to allow Joe to see it
dka: SN B is able to request from SN A are there any pictures that i can display from alice
rigo: if you tear down the silo of the walls, then you have to make sure you see the notion of friends ... then SN A has to be able to limit
dka: if joe goes to SN A to see Alice profile he says let me see the pictures i can see, then SN A needs to be able to identify joe
<danbri> (aside, when you say SN, ... increasingly it might just be 'site'?)
rigo: there are some providers that federate like plaxo like an rss feed ... but then how do you do access control
dka: i think this means we need to add a use case taht i don't think is accounted for
<danbri> re lookup services, also consider http://socialgraph.apis.google.com/
dka: joe visits alices profile page on SN A
<danbri> it is used by http://googleblog.blogspot.com/2009/10/introducing-google-social-search-i.html (and based on xfn and foaf)
timbl: there is some initial interaction that seems to be missing
rigo: the reported in the social
identity ???? they discussed unique identifiers and email
address as the unique identifier
... they discussed web finger
Haken: its a discover step that we're missing
dka: this use could be me
following steven fry, he doesn't know who i am .... it's
symetric in the sense that he knows that i'm following
... in this case, joe (SN B) knows about the relationship
Ann: i wonder if the title is
... maybe connection is misleading
timbl: there could be lots of
ways that alice knows about joe
... could be email, or could have found each other ... eventually they establsh this connection
dka: in the course of events its
implicit that if joe doesn't have alices identifier, by the
time this is done joe definately does
... if alice makes a request, then joe knows she made the request
martin: there is a post condition that joe knows about alice
<timbl> Missing step 2: Alice sees joe as an unconfirmed friend, Joe get extra rights to see Aice's stuff.
dka: right but is that true that we always want to have that, is it meaningful that alices identifier is not known by joe
rigo: typcially you have a public profile where it gives you a teaser to get you to join the SN
Ann: the profile could be obscure too
rigo: the web has unlimitted
number of possibilities to discover people
... in this case there is no back identifier
timbl: step that is missing, after alice requests SN B (joe) .... when she stated joe is her friend, she see joe is listed as her friend. second part is if he ever comes in to facebook now, he gets rights to see more about alice
<timbl> Missing step 2: Alice sees joe as an unconfirmed friend, Joe get extra rights to see Aice's stuff.
dka: adding that notion to the user scenario
refresh user scenario page
dka: does that mean we should delete the Accepting a Friend use case
<danbri> (another aside from me - I hope you can talk a bit about lists/groups, eg. the recent twitter 'list' feature is making quite a stir... and identi.ca/statusnet have groups)
martin: its seems to be talking about http ... low level stop
Ann: seems that there are components of accepting and rejecting that might be good to keep separate
dka: seems that rejecting is a different alternative path and that blocking may be a separate use case
FabGandon: maybe the blocking could be part of the CRUD one
Ann: one aspect of block that you just block people you don't know but then the case about a stalker, you are being stalked and want to block that person
dka: editing wiki, strying to add
... and then lets talk about that ... i think the relationship is binary but the meta-information is on top of that
timbl: thats how it is on
facebook, but they've had to start adding classification to
... but whether i classify you as a friend or a foe, is not visible to you
dka: i still like thats
classifications of your social graph
... i have linkage but i hang metadata off of that linkage
Hajons: but do you have to accept to be a foe
<danbri> all the services will add private and public categories, i'm sure of it...
dka: is there a case where anything more than the binary connection is a personal matter
<hajons> Håkan = hajons
dka: if listing that we, individually say we are w3c colleagues that doesn't mean as much as if we both agree to say that. there additional value in that
<danbri> here's an example i started btw, putting people into groups --- http://wiki.foaf-project.org/w/FOAFLists
Ann: what if you want to remove / revoke the relationship
martin: establishing the connection and then another could be managing the connection
dka: now we have establishing, managing, and blocking
Håkan: I'm thinking about the metadata. we're talking about establishing the relationship ... what about the rules of the relationship
dka: if SN A really didn't know about SN B, then somehow SN A would have to allow Alice to agree to SN B term and conditions
martin: with status.net all the content is pushed out to the network ... so alice wouldn't have to agree to SN B terms and conditions cause she's not creating any content on SN B
Håkan: providing some type of informationa bout the type of relation since there are no standards for this
scribe: but there is no way for
SN B to consider different types of relationships
... it can't apply policies
claudio: later on in the privacy
section of the use cases, there are some things about different
types of identities
... right now we are decoupling the identify from the SN account. what happens if we manage the different relationship profiles with these different identities ... are we over complicating the situation
dka: i think one of the preconditions is that SN A has already verified the identity of Alice
rigo: don't even get in to the
game of determining what an identity is
... we hit that problem in many areas .... now more than 6 years of research in this areas is a fan of multiple identities
... do not try to identify a physical natural person
... here we shouldn't think about identifying a natural person but should take some kind of virtual identity and person can have more than one
dka: agree we don't want to get in to solving the identity problem
dka: adding to preconditions that SN A has added Alice as an identiy
tbl: lots of personae around, some people can correlate others don't
dka: one use case missing,
relationship between different profiles to say "this is
... is a kind of managing personae idea
... actually there is no way to say that "this is me"
<danbri> re this is me, XFN handles that very concisely: rel=me
<danbri> i've been looking at foaf/xfn integration - via groups:
<danbri> here's an example i started btw, putting people into groups --- http://wiki.foaf-project.org/w/FOAFLists ... also as a plan for bridging foaf with xfn
dka: use case is e.g. to say to my phone that all of those different entries is me
CSM: is that related to the use case this morning?
??: can do the 'me' thing
<hajons> ?? = Håkan = hajons
<AnnB> also, TBL said FOAF can identify "me"
<danbri> FOAF has a few tricks for figuring out identity from descriptions (plus simple use of URIs and owl:sameAs)
<hajons> on the me rel tag: http://www.rexblog.com/2009/04/21/19358
<Adam> lots of discussion on how linking or saying this is me can cause concerns
rw: don't absolute IDs, just use relative identies wherever you find them
<AnnB> tlr: the "me" relationship might help one SN discover info from "me" in another SN
dka: how to see information flow
... how this is better compared to the current situation
... bad scenario: how to manage all fragmentation
HJ: want to link my professional profiles together and my private, but independent from each other
dka: managing connections, we
haven't anything yet
... if Alice and Joe have connected, SN A and SN B already know about each other
dka: even in asymetric relations, a and b have to know each other
dka: basic connection unless Bob has to agree
hj: connection only established after permission
MH: we are "managing"
HJ: we should include the possibility to reject a relation
CV: friend only discussion on
... normally you don't talk about nature of relations
HJ: not saying that we need always type of relation, but we should allow for it
dka: this can be
... if connection is established, the connection is categorized..
HJ: this is only about current things, not how this should be in the future
AB: friends that you don't care about
MH: there may be a level of control
AB: profile information is
something that you totally control
... not true in a corporation environment, no choice, company policy. can't force people to put picture
rw: best practices document for corporate environment may be interesting
MH: establish connection with your business network, it is not only you that determines
AB: they struggle already with
... already big warnings about not giving names
... most worried about phishing attacks
DKA: not talking about your secret company projects ...
<hhalpin> hey sorry I'm late
dka: capture some stuff on enterprise
<hhalpin> how is the meeting going?
FG: it would be good to have use
cases from inside big corp viewpoint
... it would be 5.14
<hhalpin> Just ping me if you need any help, otherwise I'll monitor in and out via IRC.
FG: another one on the mailing list
AB: different in business intelligence, here rather somebody from inside the corp communicating outside corp
FG: we do not capture use of
social networks inside corp
... on the intranet
<DKA> ACTION: Adam to write a use case about business social networks - on an intranet - e.g. when ownership or editorship of certain parts of your profile are not under the user's control. [recorded in http://www.w3.org/2009/11/03-swxg-minutes.html#action01]
<trackbot> Created ACTION-104 - Write a use case about business social networks - on an intranet - e.g. when ownership or editorship of certain parts of your profile are not under the user's control. [on Adam Boyet - due 2009-11-10].
RW: in corp environment, linking several instances of SN needs super social network with ID
dka: do we need to have specific relationship vocab
FG: recategorizing existing relation
Adam: categorization, should Bob be aware.
dka: different from requesting
friendship to share information
... or some additional functionality
tbl: categorization of relation
and categorization of persons
... facebook makes classes, related to me, "my friends". Box of students, want to be able to treat them the same as the list of students that MIT has published
<harryhalpin> to ask a quick off topic question in irc, any idea what happened to henry story? does he need any help, and is there anything I can do?
tbl: or class of people that have
attended a certain conference
... some will be public, some private. Notion of Group is very general
FG: case: party with all colleagues except one... intersection, challenge to do that ergonomically
tbl: all my friends except this persons is difficult
AB: you have the list of friends, then you can unclick the preselected,
tbl: so procedural?
Adam: Tbl wants to use the groups consistently across different groups
tbl: to every relation, there is a class
MH: does this have an impact on later interconnect? We should focus on those
<danbri> are you talking about what i think you're talking about?
<danbri> groups/lists vs relations?
<harryhalpin> sounds like rdf domain and range...but not *required* class? Open world or closed world?
<Adam> yeah, kind of :)
<danbri> my current example is
<danbri> #danbri-wouldliketoknowbetter a :Group;
<danbri> :member [ a :Person;
<danbri> :homepage <http://tantek.com/>;
<danbri> :account <http://twitter.com/t> ] .
<danbri> ... but not clear how much logic to put into Group versus simply using OWL and subclasses of Person
<Adam> out to lunch all
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Insight/inSite/ Succeeded: s/Wagner/Vagner/ Succeeded: s/aspect of block/one aspect of block/ Succeeded: s/being a stalked/being stalked and want to block that person/ Succeeded: s/Hayen/Hajons/ Succeeded: s/sitation/situation/ Succeeded: s/determinging/determining/ FAILED: s/sitation/situation/ Found Scribe: FabGandon Found ScribeNick: FabGandon Found ScribeNick: Adam Found Scribe: Adam Inferring ScribeNick: Adam Found Scribe: Rigo Inferring ScribeNick: rigo Found ScribeNick: rigo Scribes: FabGandon, Adam, Rigo ScribeNicks: FabGandon, Adam, rigo WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: AB Adam Ann AnnB CSM CV DKA FG FabGandon Hakan Haken Kai MH RW Rigo VagnerW3CBrasil claudio claudio2 csma danbri hajons harryhalpin hhalpin hj lkagal martin matt mischat nord_c oshani scribenick tbl timbl tlr tlr_ trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Found Date: 03 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/03-swxg-minutes.html People with action items: adam WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]