W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

Re: Question: User Story -- Bootstrapping Facebook

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 10 Feb 2011 15:39:49 +0100
Cc: nathan@webr3.org, Melvin Carvalho <melvincarvalho@gmail.com>, WebID XG <public-xg-webid@w3.org>
Message-Id: <851754C2-A5AA-44E0-BE22-5D57509165C6@bblfish.net>
To: Stéphane Corlosquet <scorlosquet@gmail.com>

On 10 Feb 2011, at 15:11, Stéphane Corlosquet wrote:

> On Thu, Feb 10, 2011 at 8:51 AM, Nathan <nathan@webr3.org> wrote:
> Stéphane Corlosquet wrote:
> On Thu, Feb 10, 2011 at 4:58 AM, Nathan <nathan@webr3.org> wrote:
> Profile pages are not necessarily static HTML document which only the user has access too. In systems like FB, Twitter, or CMS in general, data is pulled from different places and you have to make sure you know who authored each snippet of it. That was one of the main concerns David Recordon and his team raised when I visited them in Palo Alto last year. The use case we were discussing was about the Web in general wrt harvesting data for OGP, and the reason why OGP/FB will only consider the RDFa located in the <head> tag is that it's the only data they can trust to be authored by the author of the page (or the app), anything else on the page cannot be trusted and could be a comment left by some random person who would change the title of the page for example with some well crafted RDFa. It was not about WebID or how they put their pages together, but I bet they would raise the same points re. their profile pages.
> 
> I'm to what you're referring when you say "one of the main concerns of David Recordon and his team" - can you confirm?
> 
> The fact that on the Web, you do not know who authored each bit of a page. With static pages this used to be very easy since the webmaster is authoring the whole page in their text editor, but with rich web apps (typically any sites accepting input from other users), you cannot ensure that all the information on the page can be trusted as being authored by one single person. This is not a WebID specific issue, but one issue that needs to be taken into account when talking about dynamic WebID profile document which might contain data which has been authored by random users. Is this more clear?
> 
> Steph.

(This thread is a bit skizzo. Here we are in the part of this thread giving advice to FB)

It seems simple then. They could have a webId that points to pages that cannot be edited by anyone but their rightful owner. 

It is clear that <http://facebook.com/bblfish> would not be such a page.

But it would not be difficult to create a URL for the profile page, where they could put the WebID. Perhaps:

- http://facebook.com/bblfish/p/
- http://facebook.com/p/bblfish

or whatever. It just matters that if the owner GET that web page he ends up on a page he can see all the info and edit it, and if someone else GETs it they see whatever they are allowed to see - and probably not be allowed to edit that info.

The fact that the page people remember is not the profile page does not matter. People are more interested in their activity feed. Since the WebID is locked in the certificate, there is no need to remember the URL. What is useful is to help people associate the certificate selection box with their profile, so that they can see how edits in the profile change their experience on other sites. 

But I think here I am repeating what I said initially.

Henry


Social Web Architect
http://bblfish.net/
Received on Thursday, 10 February 2011 14:40:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC