Suw
Charman just wrapped up a talk at Google (Scary Monsters: Does
Social Software Have Fangs?) around the adoption and use of social
software such as wikis and blogs within businesses. It was a good talk
and the on-the-ground experience around corporate adoption was
particularly valuable for me.
Suw reported that corporate users tend to impose their existing
corporate hierarchy on the flat namespace of their Wikis, which is fine
but may not be exploiting the medium to its full potential. And Wiki
search tends to be at best mediocre. Has anyone looked at leveraging
user edit histories to infer page clusters? I could imagine an
autogenerated Wiki page which represented a suggested cluster, with a
way for people to edit the page and add meaningful titles and
annotations to help with search, which could serve as an alternative
index to at least part of a site.
Thursday, June 28, 2007
Friday, June 22, 2007
Identity Panel at Supernova, or How I Learned to Stop Worrying and Love User Centric Identity
The Identity Panel just wrapped up:
(John Clippinger, Kaliya Hamlin, Reid Hoffman, Marcien Jenckes, Jyri Engestrom)
As our lives increasingly straddle the physical and the virtual worlds, the management of identity becomes increasingly crucial from both a business and a social standpoint. The future of e-commerce and digital life will require identity mechanisms that are scalable, secure, widely-adopted, user-empowering, and at least as richly textured as their offline equivalents. This session will examine how online identity can foster relationships and deeper value creation.
It was interesting to see the reactions from the crowd and on the #supernova backchannel. There's a lot of reactions of the form "but I want to be anonymous" though what they really mean is psuedoanonymous. It's not really made clear that OpenID enables all those scenarios. There were objections to calling things like OpenID "identity" and maybe some people think that's something of a meme grab.
OpenID is definitely very simple, very focused on doing just one part of identity. It enables the unbundling of identity, authentication, and services. It lets you say "this X is the same as this other X from last week, or from this other site" in a verifiable way that's under the control of X. Is there a better word for this than "identity"?
Also, every discussion of OpenID should start out with a simple demo: I type =john.panzer at any web site, and it lets me in. Then talk about the underpinnings and the complications after the demo.
Tags: supernova2007, identity, OpenID
OpenID is definitely very simple, very focused on doing just one part of identity. It enables the unbundling of identity, authentication, and services. It lets you say "this X is the same as this other X from last week, or from this other site" in a verifiable way that's under the control of X. Is there a better word for this than "identity"?
Also, every discussion of OpenID should start out with a simple demo: I type =john.panzer at any web site, and it lets me in. Then talk about the underpinnings and the complications after the demo.
Tags: supernova2007, identity, OpenID
Wednesday, June 20, 2007
Will Copyright Kill Social Media? (Supernova)
Everyone agreed that copyright won't kill social media, though it will shape it (that which does not kill you makes you stronger?) Unfortunately we ran out of time before I was able to ask the following, so I'll just blog them instead.
(Moderator Denise Howell, Ron Dreben, Fred von Lohmann, Mary Hodder, Mark Morril, Zahavah Levine)
The promise of social networks, video sharing, and online communities goes hand-in-hand with the challenge of unauthorized use. Is social media thriving through misappropriation of the creativity of others? Or are the responses to that concern actually the greater problem?
-- Will Copyright Kill Social Media?
Mark Morrill was very reasonable for the most part, but made two outrageous claims: That DRM is pro-consumer, and that we should be able to filter on upload for copyright violations. The first claim is I think simply ridiculous, especially when the architect of the DMCA says that the DRM provisions have failed to achieve their effect and consumers are rejecting DRM wherever they have a choice. You can say it's needed for some business model, or required to make profit, but I don't see how you can say it's pro-consumer with a straight face.
On filtering, Zahavah Levine pointed out that copyright isn't like porn; there's nothing in the content itself that lets you know who the uploader really is and whether they own any necessary rights. But even if you had this, it seems to me that you'd need an artificial lawyer to have a scalable solution. (GLawyer?)
On the technical side, I heard one thing that isn't surprising: That it would be very helpful to have a way for rights holders to be able to assert their rights in a verifiable way. An opt-in copyright registration scheme that provided verifiability might be a step forward here. Alternatively, perhaps a distributed scheme based on verifiable identities and compulsory licenses might be worth looking at.
Tuesday, June 19, 2007
Going Supernova
I'll be at the Supernova conference on Wednesday (at Wharton West) and Friday. Unfortunately I couldn't make the Open Space even today. Ping me if you're there too and want to sync up.
Monday, June 18, 2007
In Which I Refute Web3S's Critiques Thusly
So the other shoe has dropped, and Yaron Goland has just given some background on Microsoft's draft Web3S protocol, while Dare comments. Which seems at first glance kind of interesting and certainly could expand the field of REST based services in a big way. At the same time, I'm confused by some of the stated rationales for not extending APP the way GData does. I think there are some straightforward answers to each of the gaps he identifies:
Hierarchy
Turtles all the way down:
<entry>
...
<content type="application/atom+xml">
<feed> ... it's turtles all the way down! ... </feed>
</content>
</entry>
Merging
I think this is orthogonal, but there's already a proposed extension to APP: Partial Updates. Which uses (revives?) PATCH rather than inventing a new verb or overloading PUT on the same resource. I'm neutral on the PATCH vs. POST or PUT thing, except to note that it's useful to be able to 'reset' a resource's state, so having the ability to allow this via either two verbs or two URIs is useful too. I'm a little confused though since Yaron says that they're using PUT for merging but they're also defining UPDATE as a general purpose atomic delta -- so why do you need to overload PUT?
I need to think about the implications of extending the semantics of ETags to cover children of containers as well as the container.
I do like Web3S's ability to address sub-elements individually via URIs; APP provides this out of the box for feeds and entries, but not for fields within an entry. It's not difficult to imagine an extension for doing so that would fit seamlessly within APP though.
I think it'd be interesting to look at an APP+3S (APP plus 2-3 extensions) to see how it would compare against Web3S, and whether the advantages of a stable, standard base do or do not outweigh the disadvantages of starting from something not tailored for your solution. Certainly the issues raised by Yaron are fairly generic and do need solutions; they're not new; and the thinking of the APP WG has pretty much been that these sorts of things are best dealt with via extensions.
Hierarchy
Turtles all the way down:
<entry>
...
<content type="application/atom+xml">
<feed> ... it's turtles all the way down! ... </feed>
</content>
</entry>
Merging
I think this is orthogonal, but there's already a proposed extension to APP: Partial Updates. Which uses (revives?) PATCH rather than inventing a new verb or overloading PUT on the same resource. I'm neutral on the PATCH vs. POST or PUT thing, except to note that it's useful to be able to 'reset' a resource's state, so having the ability to allow this via either two verbs or two URIs is useful too. I'm a little confused though since Yaron says that they're using PUT for merging but they're also defining UPDATE as a general purpose atomic delta -- so why do you need to overload PUT?
I need to think about the implications of extending the semantics of ETags to cover children of containers as well as the container.
I do like Web3S's ability to address sub-elements individually via URIs; APP provides this out of the box for feeds and entries, but not for fields within an entry. It's not difficult to imagine an extension for doing so that would fit seamlessly within APP though.
I think it'd be interesting to look at an APP+3S (APP plus 2-3 extensions) to see how it would compare against Web3S, and whether the advantages of a stable, standard base do or do not outweigh the disadvantages of starting from something not tailored for your solution. Certainly the issues raised by Yaron are fairly generic and do need solutions; they're not new; and the thinking of the APP WG has pretty much been that these sorts of things are best dealt with via extensions.
Saturday, June 16, 2007
Social Network Partition
At work we're experimenting with social networks. It's amusing to note the non-overlap between the Orkut people and the LinkedIn people -- different purposes and different goals. And the standard wisdom is that Myspace users graduate to Facebook as their social identity evolves. Is this a function primarily of age? Once the generation growing up with social networking hits their mid-20s, will they continue to network-hop or will they settle on one? Or will they, like my office mates, sign up for all the networks any of their friends or colleagues are with?
Tags: social networks, partition, lions
Tags: social networks, partition, lions
Thursday, June 14, 2007
Is the Atom Publishing Protocol the Answer?
Are Atom and APP the answer to everything? Easy one: No.
Dare Obasanjo raised a few hackles with a provocative post (Why GData/APP Fails as a General Purpose Editing Protocol for the Web). In a followup (GData isn't a Best Practice Implementation of the Atom Publishing Protocol) he notes that GData != APP. DeWitt Clinton of Google follows up with a refinement of this equation to GData > APP_t where t < now in On APP and GData.
I hope this clarifies things for everybody.
There seems to be a complaint that outside of the tiny corner of the Web comprised of web pages, news stories, articles, blog posts, comments, lists of links, podcasts, online photo albums, video albums, directory listings, search results, ... Atom doesn't match some data models. This boils down to two issues, the need to include things you don't need, and the inability of the Atom format to allow physical embedding of hierarchical data.
An atom:entry minimally needs an atom:id, either an atom:link or atom:content, atom:title, and atom:updated. Also, if it's standalone, it needs an atom:author. Let's say we did in fact want to embed hierarchical content and we don't really care about title or author as the data is automatically generated. I might then propose this:
<entry>
<id>tag:a unique key</id>
<title/>
<author><name>MegaCorp LLC</name></author>
<updated>timestamp of last DB change</updated>
<content type="application/atom+xml">
<feed> ... it's turtles all the way down! ... </feed>
</content>
</entry>
Requestors could specify the desired inline hierarchy depth desired. Subtrees below that node can still be linked to via content@src. And when you get to your leaf nodes, just use whatever content type you desire.
Alternatively, if you need a completely general graph structure, there's always RDF. Which can also be enclosed inside atom:content.
The above is about as minimal as I can think of. It does require a unique ID, so if you can't generate that you're out of luck. I think unique IDs are kind of general. It also requires an author, which can be awfully useful in tracking down copyright and provenance issues. So that's pretty generic too, and small in any case.
Of course this type of content would be fairly useless in a feed reader, but it would get carried through things like proxies, aggregators, libraries, etc. And if you also wanted to be feedreader friendly for some reason, the marginal cost of annotating with title and summary is minimal.
Dare Obasanjo raised a few hackles with a provocative post (Why GData/APP Fails as a General Purpose Editing Protocol for the Web). In a followup (GData isn't a Best Practice Implementation of the Atom Publishing Protocol) he notes that GData != APP. DeWitt Clinton of Google follows up with a refinement of this equation to GData > APP_t where t < now in On APP and GData.
I hope this clarifies things for everybody.
There seems to be a complaint that outside of the tiny corner of the Web comprised of web pages, news stories, articles, blog posts, comments, lists of links, podcasts, online photo albums, video albums, directory listings, search results, ... Atom doesn't match some data models. This boils down to two issues, the need to include things you don't need, and the inability of the Atom format to allow physical embedding of hierarchical data.
An atom:entry minimally needs an atom:id, either an atom:link or atom:content, atom:title, and atom:updated. Also, if it's standalone, it needs an atom:author. Let's say we did in fact want to embed hierarchical content and we don't really care about title or author as the data is automatically generated. I might then propose this:
<entry>
<id>tag:a unique key</id>
<title/>
<author><name>MegaCorp LLC</name></author>
<updated>timestamp of last DB change</updated>
<content type="application/atom+xml">
<feed> ... it's turtles all the way down! ... </feed>
</content>
</entry>
Requestors could specify the desired inline hierarchy depth desired. Subtrees below that node can still be linked to via content@src. And when you get to your leaf nodes, just use whatever content type you desire.
Alternatively, if you need a completely general graph structure, there's always RDF. Which can also be enclosed inside atom:content.
The above is about as minimal as I can think of. It does require a unique ID, so if you can't generate that you're out of luck. I think unique IDs are kind of general. It also requires an author, which can be awfully useful in tracking down copyright and provenance issues. So that's pretty generic too, and small in any case.
Of course this type of content would be fairly useless in a feed reader, but it would get carried through things like proxies, aggregators, libraries, etc. And if you also wanted to be feedreader friendly for some reason, the marginal cost of annotating with title and summary is minimal.
Friday, June 1, 2007
Google += Feedburner
This is a validation of how important feeds are to the Web ecosystem. And of course I'm personally happy they're going to Google. I think they're pretty happy too:
The local weather forecast calls for general euphoria with intermittent periods of off-the-rails delight.
Subscribe to:
Posts (Atom)