See also: IRC log
<trackbot> Date: 10 February 2010
<tpa> ah. All alone again.
<manu> Zakim left the channel
<danbri> i can't call in right now, will lurk in irc ... try to get on later
ill try :)
any quick tips?
(not scribed before)
<manu> scribenick: melvster
<hhalpin> scribe: melvster
<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?
<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
hhalpin: action reminders, see
... first step high level principles
hhalpin: there've been some emails
<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
... christine did some good work putting this in a table
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> no-one I can find objected.
AnitaD: 2nd principle, no objections recorded
<rreck> taking me a while to catch up
hhalpin: just returning to the
... 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
DKA: social web seems to be
... 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: 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
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
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
<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
<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
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
... 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).
<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
<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: 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
<cperey> I would also like to build up or out
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
<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].
<DKA> Thanks Anita!
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
<bblfish> me too lost manu for a second
thx: it's more than high level, we have a lot of details worked out
<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
... buyers and sellers are almost interchangable
... a buyer can become a source, just like bittorrent
... thats how we add scalability
<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
... 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
<hhalpin> "network trails"
hhalpin: how about the idea of
... 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
... just throwing a thought out there
bblfish: does this fit in with goodrelations ontology?
AnitaD: talked to mfhepp about
payswarm, and am sure we will end up integrating GR with
... 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
... 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
... 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
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
... 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> ... 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
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
<DKA> ...mobile operators who want to have interoperable app stores...
manu: would be good to get bankers interested, paypal, amazon
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
... 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
... 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
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
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/speaker/speaks/ Succeeded: s/cant/can/ Succeeded: s/Doug: overall /Manu: overall / Succeeded: s/coudl/could/ Found ScribeNick: melvster Found Scribe: melvster Inferring ScribeNick: melvster Default Present: tpa, [IPcaller], Dsr, Doug_Schepers, hhalpin, +1.510.931.aaaa, manu, melvster1, bblfish, +0774811aabb, +049172247aacc, +1.617.838.aadd Present: tpa [IPcaller] Dsr Doug_Schepers hhalpin +1.510.931.aaaa manu melvster1 bblfish +0774811aabb +049172247aacc +1.617.838.aadd Found Date: 10 Feb 2010 Guessing minutes URL: http://www.w3.org/2010/02/10-swxg-minutes.html People with action items: hhalpin[End of scribe.perl diagnostic output]