Social Web Incubator Group Teleconference -- 10 Feb 2010

<trackbot> Date: 10 February 2010

<tpa> ah. All alone again.

<manu> Zakim left the channel

<manu> ?

<danbri> i can't call in right now, will lurk in irc ... try to get on later

<manu> uhh

ill try :)

any quick tips?

(not scribed before)

<manu> scribenick: melvster

thanks!

Convene SWXG WG meeting of 2010-02-10T16:00-17:00GMT

<hhalpin> scribe: melvster

<tpa> yup?

<AnitaD> yes, Anita Doehler

<AnitaD> AD is the German number

<hhalpin> PROPOSED: to approve SWXG WG Weekly -- 27 January 2010 as a true record

hhalpin: approve meeting minutes?

<tpa> +1

<hhalpin> http://www.w3.org/2010/02/03-swxg-minutes.html

<hhalpin> APPROVED: SWXG WG Weekly -- 27 January 2010 as a true record

hhalpin: meeting next week dick hardt

<hhalpin> PROPOSED: to meet again Wed. February 17th: Dick Hardt on OpenID and WRAP

<hhalpin> RESOLVED: meet again Wed. February 17th: Dick Hardt on OpenID and WRAP

<rreck> +1 meet again

Action Reminders

<hhalpin> http://www.w3.org/2005/Incubator/socialweb/weekly-agenda.html

hhalpin: action reminders, see weekly agenda
... first step high level principles

Discussion of high-level discussions

hhalpin: there've been some emails

<hhalpin> http://lists.w3.org/Archives/Public/public-xg-socialweb/2010Jan/0019.html

<DKA> +1 for consensus

hhalpin: good discussion, we may want to try and reach consensus

AnitaD: a few different responses, perhaps we can restart the discussion
... perhaps misunderstanding over wording
... some of the discussion was related to apps rather than UGC

<hhalpin> +1 to misunderstanding :)

AnitaD: for example 1st principle -- what you see depends on who you are

<bblfish> yes, so for 1 the wording needs to be improoved a little

AnitaD: UGC depends on my relationship to the visitor, depending on what they can see

<bblfish> so the intetnion is good

hhalpin: im ok with that 1st principle
... christine did some good work putting this in a table

<hhalpin> http://www.w3.org/2005/Incubator/socialweb/wiki/SocialWebFrameworks#The_Terminology

bblfish: good thought, perhaps empahsis should be on the person publishing it

<hhalpin> "Who sees what depends on who they are"?

<rreck> or the role they are instantiating

bblfish: tricky to word, difficult to get it right

<rreck> a person can be fulfilling different purposes at different times

<rreck> horrible idea

<hhalpin> If you want, I can put out Chris Saad's point

DKA: idea -- each principle should be a haiku :)

<hhalpin> "Why? Maybe the site is designed to have a water cooler style 'what's

<hhalpin> popular' approach (like most sites today) - why mandate a personalized

<hhalpin> experience?

<hhalpin> "

<rreck> palindrome

<hhalpin> http://lists.w3.org/Archives/Public/public-xg-socialweb/2010Jan/0025.html

<hhalpin> no-one I can find objected.

AnitaD: 2nd principle, no objections recorded

<rreck> taking me a while to catch up

AnitaD: comments?

hhalpin: just returning to the first principle
... some apps dont want a peronalized experienced

<hhalpin> ""Who sees what CAN depend on who they are"

hhalpin: Chris Saad made the point that it should not be mandated

<bblfish> Aphorism is the word I was looking for. Each one of those lines should be an aphorism

<bblfish> (or a tweet)

DKA: takes back to conversations in santa clara and vodafone
... what differentiates the social web
... in santa clara we discussed 'why is created a friend different to following an rss feed'

<bblfish> yes: it is meaningful in a social context to know who you are communicating

DKA: agreed, that even in twitter there is an implicit bidirectional connection

<bblfish> with

DKA: social web seems to be stronger bidirectionality
... bidirectionality implies a different experience

<hhalpin> I'm happy to buy that different experience line, I was just bringing up Chris's point.

<bblfish> What you tell (publish) to someone depends on who they are in your social network.

<bblfish> idea: "What you tell (publish) to someone depends on who they are in your social network."

DKA: its not social unless there's bidirectional relationship

<hhalpin> Will having a different veiw, depending on who you are, be necessarily be

<hhalpin> RESTful?

<hhalpin> ?

<hhalpin> http://lists.w3.org/Archives/Public/public-xg-socialweb/2010Jan/0069.html

hhalpin: bringing up chris saads point

dont have a mic here im afriad ...!

<hhalpin> no problems, henry will talk about REST

scribe: will it be RESTful

<rreck> kinda obvious but information you disclose in a social network is based entirely on language, as oppose to real life social interactions

bblfish: important part of the web is that documents should link to other documents
... one way of doing social networks is to copy information from one network to another
... one of the key elements of the social web is to reference using links

<rreck> or based on volition

bblfish: email, for example, can be copied from inbox to inbox
... but in general there's no identifier

<rreck> yes

bblfish: if one speaks more in terms of linking between things, we get closer to the level of web architecture

hhalpin: agree with anitaD / DKA that connections are important, seems not terribly RESTful, but im ok with that, in certain contexts
... eg between friends you can access certain URIs
... that is sort of restful in a wierd way

<hhalpin> +1 to second (Chris also said "sure")

anitad: any comments to the 2nd high level principle?

<hhalpin> And I agree with first, but we might want to clarify the relationship to REST in our text.

anitad: no ...
... 3rd principle

<bblfish> yes for 3. That's a key REST principle

<hhalpin> I agree with the third. Chris disagreed..

anitad: You can expose your content (User Generated Content) to different > Social Networks or Social Applications, without the need to store the > content in these networks/applications.

<hhalpin> I think Chris mainly was worried that we were *mandating*, but then we're not looking for requirements but guiding principles

anitad: currently often need to store UGC on several different servers
... was that clear?
... continuing principle 4
... You can define the access control on a per item basis, either per contact, or per group.
... again referring to UGC
... user should be able to define access control to different attributes of UGC

<rreck> what is "an item"

bblfish: are we maybe missing the identity of the user?

<rreck> good question

bblfish: is global identity one of the principles

AnitaD: we discussed this internally

<rreck> i think they are instantiating a role

AnitaD: depends on terminology used

<manu> I have a question about the principles...

AnitaD: users can have different profiles

<DKA> Also users can have multiple legal identities (e.g. dual citizens)

<rreck> i operate as an admin, and as a user, i am the same person

AnitaD: i dont always need to disclose my real identity

<rreck> my identity is immaterial its the role im using

<rreck> role

bblfish: notion of type of identity is not so important, but we need a unique name
... name should refer uniquely to one thing, needs to be global
... to carry out the principles we need a global way of referring to something
... wondering if that's something that follows? or should it be a principle?

<manu> identity should be a principle... it doesn't have to be global

AnitaD: you cant force someone to use one global identity

<manu> but you do need it to talk about them - FOAF, VCARD, etc

<rreck> reference

<hhalpin> Maybe "Resources should have global identifiers (URIs), even if access to them is restricted on a contextual basis"

<hhalpin> Basically, that is the "Web" in "Social Web" :)

<rreck> +1 what harry said

bblfish: you dont need to force someone, but you need to identify they globally, you just need a handle on them, it's not a global identity, but in certain contexts they'll know it's me

<rreck> i think its a principle

<MacTed> doesn't need to be global identifier.

bblfish: you can also refer to me as 'henry story', or bblfish, but in a global name, we need to give people global name, so that we can know which resources to give access to who

<MacTed> just needs to be identifier.

bblfish: somehow the user needs to identify, so that the website can for example show a picture

who's speaking?

<rreck> doug?

<rreck> hi doug

<MacTed> identifier of unique resource/entity ... all identifiers of same resource/entity should be owl:sameAs'ed ... and presto

manu: mostly wondering if this group is going to apply principles to some of the leading social networks out there ...

<hhalpin> Manu, so we have a list of 50 top social networks we were going to test these and use-cases against

<hhalpin> (looking for wiki list)

manu: might be helpul, and also the reverse, eg finding something that the leading soc nets do that are not in the list ...

<cperey> this is a very good idea

<cperey> important to refresh this

<cperey> we didn't really go into the depth which is proposed

<cperey> haha!

hhalpin: covered 50 top social networks, inc. mobile, good suggestion to apply to soc nets

<cperey> and then be out of date a few days later

<MacTed> any site/service should be able to create their own Identifiers (URIs) for their members.

<MacTed> all members should be able to assert "I am also *that* member of *that* site" -- and perfect world, each service could verify that assertion

<hhalpin> "Resources should have global identifiers (URIs), even if relationship to them are restricted on a contextual basis"

<hhalpin> Broader than people

hhalpin: could we deal with henry's comment, by adding principle 6: something like resources should have global identifiers even if access is restricted
... you dont necessarily have to have the same access permission

<MacTed> "global identifier" remains troubling to me

<MacTed> "global" isn't correct

<MacTed> it's not the only identifier of the entity

<rreck> global means unique

<bblfish> Universal Resource Identifiers

<hhalpin> "Resources should have universal/unique/uniform identifiers (URIs), even if relationship to them are restricted on a contextual basis"

hhalpin: unique rather than global perhaps? universal? uniform?
... might be a nice addition?

<MacTed> Resources should have identifiers (URIs).

<MacTed> period

<hhalpin> "Resources should have identifiers (URIs), even if relationship to them are restricted on a contextual basis"

<bblfish> it would be interesting to get the Web Architecture people to look at those

<rreck> i agree on identifier but dunno about globalness

<hhalpin> ok, happy to drop globalness.

<hhalpin> +1 on last principle

<MacTed> that works :-)

<rreck> maybe its called for?

AnitaD: principle 5. You can communicate with connections no matter which Social Network or Social Application you share.
... that's it ...

<hhalpin> PROPOSED: Social Web XG adopts (puts in final report) Anita's principles plus a URI principle as our guiding principles

<rreck> +1

<FabGandon> +1

<Zakim> DKA, you wanted to suggest we at least reach consensus on the idea of publishing some principles into the final report + a survey of how current social networks show these...

<DKA> +1

<hhalpin> bblfish?

DKA: i support the proposed resolution, but also the idea of building outwards

<bblfish> +1 though I think we should be open to improovements to the lanauge

<hhalpin> Yuk?

<cperey> I would also like to build up or out

<tpa> +1

<hhalpin> Yoshiaki?

DKA: like the idea of looking at current soc nets and apps. and showcase these principles

<hhalpin> We can wordsmith a bit in the wiki

<cperey> I'm a little taken aback by going to resolution stage

<cperey> that's fine

hhalpin: i put a page called final report in the wiki, ill put the principles in there

<DKA> We can also move fast in W3C when necessary.

<hhalpin> RESOLVED: Social Web XG adopts (puts in final report) Anita's principles plus a URI principle as our guiding principles

<rreck> sure

<hhalpin> ACTION: hhalpin to put these principles in new wiki page [recorded in http://www.w3.org/2010/02/10-swxg-minutes.html#action01]

<trackbot> Created ACTION-124 - Put these principles in new wiki page [on Harry Halpin - due 2010-02-17].

<yoshiaki> +1

<DKA> Thanks Anita!

PaySwarm Discussion

Manu Sporny and Doug Schepers on Payswarm

hhalpin: have a special guest on the phone

<rreck> thanks anita

hhalpin: manu sporny and doug schepers on payswarm
... thankful about your work with html / rdfa
... doug is one of the api experts at the w3c

<manu> * The overall goal of PaySwarm

<manu> * build ability to buy/sell digital content into browsers

<manu> * We are discussing a system that has been implemented commercially

<manu> * bitmunk.com (website and peer-to-peer PaySwarm network)

<manu> * Digital Contracts and Electronic Signatures as a basis for

<manu> licensing and copyright-aware digital content distribution

<manu> * E-SIGN Act of 2000

<manu> * The typical participants on a PaySwarm network

<manu> * content owner

<manu> * The Sales Verificatin Authority

<manu> * sellers

<manu> * buyers

<manu> * How pricing is calculated on a PaySwarm network

<manu> * content owner royalty + seller distribution fee + network fees

<manu> * Licenses are sold separately from data

<manu> * A typical content transaction on a PaySwarm network

Manu: overall goal is to buy and sell digital content in web browsers

<manu> 1. content owner registers content with SVA and sets royalties

<manu> 2. buyers search for content to buy or visits a website with

<manu> semantic markup or a link to initiate a purchase contract

<manu> 3. buyer purchases content from the swarm

<manu> 4. buyer automatically joins swarm for re-distribution

<manu> 5. buyer becomes seller and gets a cut of each download

<manu> * More resources

<manu> * PaySwarm FAQ: http://payswarm.com/specs/payswarm-faq.html

<manu> * PaySwarm Use Cases: http://payswarm.com/specs/payswarm-use-cases.html

Manu: mobile, and from corporations to customers, and P2P
... there's a site called bitmunk.com ... im the founder of digital bazaar

thx: )

<bblfish> me too lost manu for a second

thx: it's more than high level, we have a lot of details worked out

<manu> hmm

<bblfish> I think it is

thx: please feel free to ask questions as we go alon

<bblfish> yes we hear you

<hhalpin> So basically let's do questions at end

<hhalpin> and add yourself as usual using "q+"

thx: basis of payswarm is using digital contracts and electronic signatures as a way to encode content and exchange
... esign act of 2000, is a basis
... if you can verify a person's identity (eg bankcard / electron signature) or drivers licence, their use of that is as binding as a pen signature
... this opens doors to using digital contracts
... not just small priced, but also high priced, up to $150,000 is enforcable in the US

<bblfish> lost manu

<bblfish> very echoy

<MacTed> sadly, IP telephony is really not up to what it could be

<bblfish> ouch! cell phone

thx: calling in on cell phone

<DKA> ...some drop-outs happening...

<DKA> ...maybe he fell down a well...

<bblfish> bzzzzt crscsssdfssdsd bzzttt

thx: 4 major participants
... content owner (creates digital content) music label, music studio, home studio, research, anything digital
... sales verification authority, identity management, collect royalties, distribute royalties, making sure the network is operating corrections, police DOS, eg digital bazaar, itunes/amazon could
... sellers
... buyers
... buyers and sellers are almost interchangable
... a buyer can become a source, just like bittorrent
... thats how we add scalability
... questions?

<bblfish> no that seems simple

<bblfish> you have 4 types of users

<bblfish> or 4 roles

thx: theres a lot of complexity behind the scenes
... pricing is calculated, you have to allow pricing independently
... content owner is allowed to set royalties, independent of the sellers prices
... sellers then set their prices
... then there are network fees
... final price is, royalties plus sellers distribution fee plus network fee
... spec allows more complexity
... the network we separate purchasing a licence with purchasing a good
... eg you can purchase a low definition or high definition stream
... typically how the content industry would like it to work

<bblfish> sounds sensible

<bblfish> though I would not have thought about doing that

thx: typical transaction ... content owner goes to the SVA and registers their content for sale, by uploading a reference file
... these are my royalties

<hhalpin> it seems like it is crucial to allow separate pricing, and that does keep it rather simple.

<hhalpin> may some issues about "network" i.e. in distributed apps where you get to one app via another one...

thx: once registered on the network, buyers will then find the file on the network

<hhalpin> like going to a ad via Google :)

<hhalpin> who gets the cash?

thx: doesnt have to happen on one website, the system is decentralized

<hhalpin> just the last network?

thx: eg can be download from a blog
... part of your pay goes to support a blog
... you can embed data using rdfa / micrformats
... buyers find information through a web based mechanism
... they can buy from an individual or from the swarm
... licence from one person
... each piece of data from 1000's of people
... hope it ends up driving distribution costs down
... eg distributing movies in HD
... dont need huge capacity, other people will help as they have a financial incentive
... buyers then seed files by default
... payswarm faq
... and payswarm use cases
... things we want to support in version 2.0 e.g. identity
... dont necessarily need that
... v 2.0 we're going to try and build in identity / financial management
... that's a quick overview
... questions?

<hhalpin> "network trails"

hhalpin: how about the idea of network trails
... look at distributed networks, you may have several layers to get to your content

<hhalpin> So let's say I go to Youtube

<hhalpin> that then sends me to a third-party, NoGoodTV

<hhalpin> I get content from that.

<hhalpin> Can Youtube get a cut?

manu: on a low level, we're going to use a bunch of REST api calls, json format, exchange pieces of information for the transaction
... send it to the SVA
... then the purchase process starts
... exchange between browser / SVA
... could you elaborate on network trails?

<hhalpin> yes, "referrer" is the right word

manu: a chain of multiple referrers, does everyone get a cut?

<hhalpin> so they CAN be compensated.

manu: currently no
... doesnt make much sense from a business perspective

<hhalpin> because that person sends them traffic.

manu: why would they want to pay some else

<hhalpin> the referrer sends them traffic.

<hhalpin> letting them sale more

<hhalpin> tpa? I also know you've thought a bit about micropayments..

manu: the seller would be able to choose who else to pay ... we are moving away from the concept of middle men on the network

hhalpin: might be a surprisingly popular option, to have referrers drive traffic to the long tail
... just throwing a thought out there

<bblfish> http://www.heppnetz.de/ontologies/goodrelations/v1

bblfish: does this fit in with goodrelations ontology?

AnitaD: talked to mfhepp about payswarm, and am sure we will end up integrating GR with payswarm
... one of the reasons we got involved with RDFa
... in our company we have a firefox plugin
... will work out all purchasable content on that page
... can use that info to generate a contract
... send it to the SVA
... in the future the browser will scrape the info e.g. in rdfa / microformats, then uses that to figure out the contract and send to the SVA

bblfish: at imperial 1995, people talked about micropayments, why hasnt it taken off? how are you keeping the costs low?
... fundamental to saving some content providers

<MacTed> if I choose to refer to a referrer to a seller, I should get a cut of the referrer's cut ...

<MacTed> if I choose to refer directly to a seller, I should get the entire referrer's cut...

<MacTed> by making the choice of how I refer, I have chosen how the payment should be made.

<MacTed> face-to-face business works well this way.

<MacTed> I think that empirically deciding "there will be no more middle men!" will tend more to stifle business than to encourage it

<bblfish> the same reason we no longer talk about semantic web ;-)

<hhalpin> its "linked data" now :)

<hhalpin> good idea MacTed

<shepazu> ("don't make me think")

manu: good point, the problem is, P2P / micro payments have a bad rap, interfaces were bothering the user, eg for 1c 2c, most people couldnt be bothered to reach for their wallets

<bblfish> ( mhh interesting: the identity problem resurges )

manu: interactions costs were too high
... ROI was not there
... systems not integrated into browser
... you had to join evercoin etc.
... wasnt a fundamental part of the web

<bblfish> makes sense :-)

<MacTed> more than anything else, too many micropayment providers makes it too hard on the purchaser

manu: requires too much work on the user's behalf, what you would ideally like you to do is say, 'would you like to set your daily/monthly spending limit', the browser would then operate within that limit

<hhalpin> +1 this browser idea, was thinking about this when NYTimes tried to charge me this morning :)

manu: browser prompts you to increase it

<MacTed> largely because each *seller* tended to have a single relationship with a micropayment provider

manu: visa transactions cost too much

<MacTed> transaction aggregation is obviously the way it has to be done

manu: payswarm addresses each of these issues
... you put in $10 or $20 at a time

<bblfish> (yes NYTimes and all the newspapers ask for $25 per year, and one never knows ahead of time if one is ever going to read that much from that site: hence the importance of micropayments. PaySwarm seems to solve this, by making it standard, and make it easy to set policies on payments for a site)

manu: creating a world standard for payments couples with browser integration, will reduce friction of transactions

bblfish: thanks, very helpful

<rreck> when its seamless there is less barrier to entry

bblfish: are you feeling browser vendors are helping?

<MacTed> does PaySwarm aim for exclusive arrangements with sellers, i.e., can a seller *only* accept PaySwarm, or can they accept any/all (micro)payment providers

<MacTed> ?

manu: we think the most important people to get on board is the large companies, newspapers, music industries ... going to meet one of the big 4 music labels today
... if they music industry gets behind it, the web browser can add a small fee
... dont expect that browsers will not want to refuse this market
... havent approached browser manufacturers yet, but will in the next few months, but mainly we're trying with the record labels

<Zakim> shepazu, you wanted to ask about karma

bblfish: thanks

<bblfish> ... dont expect that browsers manufatcturers will not be interested in a market where they can take 1% of every transaction"

manu: source code released for ref impl. hopefully api overview in the next month
... in the context of the social web
... and distributed management of a currency
... eg amazon lets me know how many people have had successful transactions with an entity
... part of identity management (SVA) can also manage reputation?
... we need an identity management nexus, dont want to bite off too much work
... the system is distributed
... financial payment system distributed
... rating system distributed
... 2nd aspect, what if you want to exchange karma
... an analogy is MMORPG
... world of warcraft millionaires
... get magic swords and sell them on ebay
... changing currencies
... karma and reputation as a currency, can we distribute that?

<bblfish> it's true it could help adoption to be able to work with game money

manu: game money, real money, reputation are mechanisms of distributing credit

<bblfish> because then one could start without getting through big government agencies

manu: might make it easier to do some social networking things
... might now be just about money, something built into the browser, that can be used as a part of exchange
... in music there's cash and reputation, you can trade one or the other
... could tell that to music companies, but it certainly has context in the social web
... how can people trade reputation among each other
... unlike money, it's not a scarce resource

bblfish: you can start growing without the overhead of banks etc. can get really big testing grounds

manu: the currency of exchange does not have to be USD EUR etc. can be something else

<bblfish> +1

hhalpin: should end the call soonish, may be some standardization, we did have micropayments in the initial charter
... what's the current state of play

manu: focussed on getting w3c interested, and getting people into the w3c, mobile carriers, app stores, standardized app stores
... buying and selling research data
... artists generating work for you
... primary focus is getting as many people as possible, then getting those people to go to the w3c

<hhalpin> member organizations in this xg could help if they want to.

manu: if swxg says payswarm should be standarized would be great, and helpful

<hhalpin> i.e. endorse a charter etc.

manu: w3c already tried micropayments in the 90s
... dont want to fail at it again
... may be some resistance to doing this
... w3c may be cautious, conservative on certain issues, due to reputation concerns
... best way to overcome objections, is to find major stakeholders
... wont come from browser vendors
... opera maybe, but browser vendors in general not, more newspapers, movie houses, record labels

<bblfish> games

<DKA> ...mobile operators who want to have interoperable app stores...

manu: would be good to get bankers interested, paypal, amazon

<hhalpin> :)

manu: after that see where we can go

<bblfish> though perhaps the W3C could do an XG on this

manu: urge w3c to take thison

bblfish: maybe an XG for this?

manu: probably the next step
... while we're marshalling stakeholders create an XG perhaps
... trying to bootstrap, xg would be appropriate, necessary but not sufficient

<rreck> thanks for presenting

bblfish: where do you put the money?

manu: the money is kept with the SVA
... we have digital money and digital certificates
... you're operating as a pseudo bank
... governments dont like it when you do that
... SVA handle the money
... so you dont have an issue in the browser of handling money
... there isnt even legislation for that
... you take a regular credit card
... add money to an SVA

<MacTed> so it's Paypal redux

manu: that is linked to the browser

<DKA> I have to drop off call - sorry! Very interesting presentation. Vodafone might be interested in participating in an XG on this topic, for the record...

bblfish: it's not anonymous

<DKA> ciao

manu: completely the other way, there needs to be strong identity
... anonymous payments is an interesting concept, but it starts raising red flags to regulatory agencies

<hhalpin> trackbot, end meetings

<trackbot> Sorry, hhalpin, I don't understand 'trackbot, end meetings'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

hhalpin: thanks, end of meeting

<rreck> thank you guys

<hhalpin> trackbot, end meeting

- DRAFT -

Social Web Incubator Group Teleconference

10 Feb 2010

Attendees

Contents

Convene SWXG WG meeting of 2010-02-10T16:00-17:00GMT

Action Reminders

Discussion of high-level discussions

PaySwarm Discussion

Manu Sporny and Doug Schepers on Payswarm

Summary of Action Items

Scribe.perl diagnostic output