How to be a cooperative social network?
Dale Newfield
provide the data that would be useful to the google aggregator. I have
a guess, and was hoping that someone could confirm/correct me.
Two steps:
1) Provide a mechanism for users to add links to their profile page on
other social networking sites, and display those on the user's public
profile page with rel="me".
2) On that same user profile page, where links to friends are listed,
include rel="friend" on those links. Very few well designed sites will
list an unlimited number of friends on a single page, though, so how
should we state links between a user and subsequent pages of friends?
Then, in order to take advantage of the data that has been collected:
Implement a "check for additional friends" capability that queries the
SGapi to see if any additional links within your own social network can
be determined.
Seems simple enough, but then we can get no benefit until users
volunteer their other SN profile pages, and likewise reciprocate from
those profile pages back to this one.
This all ignores the (seemingly most useful) primary key, the
sgn://mboxsha1/. I have no wish to divulge a user's email address, but
I could possibly be convinced to reveal this sha1 encrypted piece of
information. Shouldn't there be a way to tell google the mboxsha1 for a
user so that some connectivity may be determined even before the user
tells us about any profile pages on other sites? Is generating a foaf
file for each user/group the only way to do this? Is that also the only
way to provide details for anything that isn't normally displayed as
part of the user's profile page? (met relationships, for example)
-Dale Newfield
Da...@Newfield.org
Martin Atkins
> What I don't see is a simple "howto" for how to make a social network
> provide the data that would be useful to the google aggregator. I have
> a guess, and was hoping that someone could confirm/correct me.
>
> Two steps:
>
> 1) Provide a mechanism for users to add links to their profile page on
> other social networking sites, and display those on the user's public
> profile page with rel="me".
Indeed.
> 2) On that same user profile page, where links to friends are listed,
> include rel="friend" on those links. Very few well designed sites will
> list an unlimited number of friends on a single page, though, so how
> should we state links between a user and subsequent pages of friends?
You can make the other pages be linked with rel="me" as well, presumably.
Bear in mind that there are other relationships beyond "friend";
"aquaintance" or "contact" might be more appropriate for some sites,
depending on what that site's "friend" relationship indicates.
> Then, in order to take advantage of the data that has been collected:
>
> Implement a "check for additional friends" capability that queries the
> SGapi to see if any additional links within your own social network can
> be determined.
>
>
> Seems simple enough, but then we can get no benefit until users
> volunteer their other SN profile pages, and likewise reciprocate from
> those profile pages back to this one.
>
> This all ignores the (seemingly most useful) primary key, the
> sgn://mboxsha1/. I have no wish to divulge a user's email address, but
> I could possibly be convinced to reveal this sha1 encrypted piece of
> information. Shouldn't there be a way to tell google the mboxsha1 for a
> user so that some connectivity may be determined even before the user
> tells us about any profile pages on other sites? Is generating a foaf
> file for each user/group the only way to do this? Is that also the only
> way to provide details for anything that isn't normally displayed as
> part of the user's profile page? (met relationships, for example)
>
One annoyance with things like XFN is that it's impossible to make a
link to something that isn't a HTTP URL reciprocal. You can't make your
mboxsha1 "link to" your main page.
Since reciprocal links are important for some use cases, this makes XFN
of limited utility with things that aren't web pages. However, I think
this is by design: XFN is a microformat, after all.
Dale Newfield
> Very few well designed sites will list an unlimited number of friends on a single page
> generating a foaf file for each user/group
As far as I can tell, if I were to generate foaf files containing all
the useful public data in my site, they could be huge, and potentially
slow to generate. Lots of the data is already available, scattered
about on various pages on my site, so I would rather present that data
on those separat pages that can be gathered a bit at a time as google's
'bot crawls my site on those various pages instead of in single
expensive data compilations (generating responses to foaf requests).
For example, lots of sites that have photos allow users to tag
themselves, and so the photo page itself can present a collection of
people that we know met one another at least once (posed for the same
photo). Is there any way to expose this data on this other page
(separate from the profile pages of the involved parties)?
-Dale
Dale Newfield
>> 2) On that same user profile page, where links to friends are listed,
>> include rel="friend" on those links. Very few well designed sites will
>> list an unlimited number of friends on a single page, though, so how
>> should we state links between a user and subsequent pages of friends?
>
> You can make the other pages be linked with rel="me" as well, presumably.
But then each user may have a huge number of "profile" pages on my site
(even though only one of those is really the profile), and while it
makes sense for each subsequent page to link back to the first, it
doesn't make sense to include links from the first to every other one...
...would just forward/back rel="me" links on each of those accomplish
the same thing? Would this not be confusing to have multiple profile
pages for each person?
> Bear in mind that there are other relationships beyond "friend";
> "aquaintance" or "contact" might be more appropriate for some sites,
> depending on what that site's "friend" relationship indicates.
Agreed. I'm glossing over that part for this discussion as it seems an
orthogonal topic.
> Since reciprocal links are important for some use cases, this makes XFN
> of limited utility with things that aren't web pages. However, I think
> this is by design: XFN is a microformat, after all.
So since the only things this aggregator understands are XFN and FOAF
the only alternative is FOAF?
-Dale
Brad Fitzpatrick
What I don't see is a simple "howto" for how to make a social network
provide the data that would be useful to the google aggregator. I have
a guess, and was hoping that someone could confirm/correct me.
You're right... a HOWTO would be useful.
Two steps:
1) Provide a mechanism for users to add links to their profile page on
other social networking sites, and display those on the user's public
profile page with rel="me".
Yes, acknowledging that your users use more than one website and letting them provide rel="me" links to their other sites is good. This is the easiest and probably most important first thing you can do.
2) On that same user profile page, where links to friends are listed,
include rel="friend" on those links. Very few well designed sites will
list an unlimited number of friends on a single page, though, so how
should we state links between a user and subsequent pages of friends?
rel="friend" (or whatever rel make sense) is great, yeah. As for pagination of results, there are two options that seem to be in use.
Twitter does this:
<a href="/bradfitz/friends?page=2" rel="me next">Next »</a>
You can also do this:
<head>
<LINK rel="Next" href="/bradfitz/friends?page=2">
</head>
Either works, really.
Then, in order to take advantage of the data that has been collected:
Implement a "check for additional friends" capability that queries the
SGapi to see if any additional links within your own social network can
be determined.
Seems simple enough, but then we can get no benefit until users
volunteer their other SN profile pages, and likewise reciprocate from
those profile pages back to this one.
This all ignores the (seemingly most useful) primary key, the
sgn://mboxsha1/.
I want to be very clear: email address (or mboxsha1 thereof) is _not_ the primary key in any of this. It's just another node in the graph that may or may not be rel="me"'d to the rest of the clusterl. So don't feel compelled to publish this information, _especially_ if you don't already allow discoverability of your users by email. If, however, you let people find users on your service by searching by email, then FOAF's mbox_sha1sum makes sense. Or, the lighter version without doing all of FOAF:
<head>
<meta name="foaf:maker" content="foaf:mbox_sha1sum '4caa1d6f6203d21705a00a7aca86203e82a9cf7a'" />
</head>
Martin Atkins
> Martin Atkins wrote:
>>> 2) On that same user profile page, where links to friends are listed,
>>> include rel="friend" on those links. Very few well designed sites will
>>> list an unlimited number of friends on a single page, though, so how
>>> should we state links between a user and subsequent pages of friends?
>> You can make the other pages be linked with rel="me" as well, presumably.
>
> But then each user may have a huge number of "profile" pages on my site
> (even though only one of those is really the profile), and while it
> makes sense for each subsequent page to link back to the first, it
> doesn't make sense to include links from the first to every other one...
> ...would just forward/back rel="me" links on each of those accomplish
> the same thing? Would this not be confusing to have multiple profile
> pages for each person?
>
Multiple profile pages is what rel="me" is for!
Another option might be to publish FOAF and make use of the RDFs
"seeAlso" element to build it out of several separate "pages" of FOAF. I
don't know if the Social Graph API would understand that, though.
Dale Newfield
> 2) On that same user profile page, where links to friends are listed,
> include rel="friend" on those links. Very few well designed sites will
> list an unlimited number of friends on a single page, though, so how
> should we state links between a user and subsequent pages of friends?
>
>
> rel="friend" (or whatever rel make sense) is great, yeah. As for
> pagination of results, there are two options that seem to be in use.
>
> Twitter does this:
>
> <a href="/bradfitz/friends?page=2" rel="me next">Next »</a>
>
>
> You can also do this:
>
> <head>
>
> </head>
>
> Either works, really.
Does that need to be reciprocal? I.E.: on /bradfitz/friends?page=2 if
there's a link to /bradfitz/friends, does it need to be "me prev" or "me
next" or even "me"? Presumably I'd at least need the link from page 2
to page 3 to also be "me next"?
> I want to be very clear: email address (or mboxsha1 thereof) is _not_
> the primary key in any of this.
It is not, but it is a link to a common node that every social network
already knows, so it would seem the best place to start bootstrapping to
tie various nodes together...
...for example, if there's a way in a given social network to say "these
are my profile pages on these other social networks", it would be a much
nicer interface if we instead were able to ask "We think these are you,
too, can you confirm?"
> So don't
> feel compelled to publish this information, _especially_ if you don't
> already allow discoverability of your users by email. If, however, you
> let people find users on your service by searching by email, then FOAF's
> mbox_sha1sum makes sense. Or, the lighter version without doing all of
> FOAF:
>
> <head>
> <meta name="foaf:maker" content="foaf:mbox_sha1sum
> '4caa1d6f6203d21705a00a7aca86203e82a9cf7a'" />
> </head>
Nice! Is this solution for embedding foaf elements within html headers
documented somewhere?
-Dale
Dan Brickley
>
> One annoyance with things like XFN is that it's impossible to make a
> link to something that isn't a HTTP URL reciprocal. You can't make your
> mboxsha1 "link to" your main page.
>
> Since reciprocal links are important for some use cases, this makes XFN
> of limited utility with things that aren't web pages. However, I think
> this is by design: XFN is a microformat, after all.
Actually I think we can tease apart the different aspects of XFN. The
relationship types ie. the list of defined kinds of relationship that
can exist between people (or agents) have utility outside of the
specific HTML idioms promoted by microformats.org. In other words,
there's XFN as a 'vocabulary' versus XFN as a 'notation'. I find value
in the former mostly for non-public data, and in the latter as a quick
authoring format for stuff I can import into RDF for SPARQL query and
data merging. The applicability of the vocabulary shouldn't be limited
by the scope of the notation; specifically we should be able to mix it
with any other vocabulary for making claims, without needing the
blessing of the notation-designers.
For eg., I've met some interesting people this week. I might only have
their email address; but this ought to be enough to write down in an
RDF/FOAF environment the claim that "danbri met the person whose
mailto: email address hashes to
3a65827317f1469bf71365d5b49ef7a5894cb7ae" ... and using XFN as the
relationship type there makes perfect sense. There are some details to
work out, since XFN is structured as officially being relationships
amongst documents that are about (or owned by) people, yet in the RDF
representation I've glossed over that and I treat XFN as being
relationships amongst agents. This lets me ask queries in the SPARQL
language such as "give me photos of people who I have xfn:met who are
in xyz group".
I'm handwaving a bit, will try to get some demo / writeup online for
this, after http://sgfoocamp08.pbwiki.com/FrontPage finishes...
cheers,
Dan
Dan Brickley
> > This all ignores the (seemingly most useful) primary key, the
> > sgn://mboxsha1/.
>
> I want to be very clear: email address (or mboxsha1 thereof) is _not_ the
> primary key in any of this.
The way we tend to talk about it in the FOAF scene is as an
"identifying property"; something for which, when you have some
specific (and accurate!) value, there is at most one entity in the
universe that has that property-value pair. If btw you see the word
"smushing" floating around, this is an informal term for doing
identity reasoning based on this.
There is some discussion of the FOAF person-centric identity reasoning
versus account-based models here,
http://danbri.org/words/2007/09/23/209 (re Flock). The two are pretty
close conceptually, its just a matter of writing code I think.
> It's just another node in the graph that may or
> may not be rel="me"'d to the rest of the clusterl. So don't feel compelled
> to publish this information, _especially_ if you don't already allow
> discoverability of your users by email. If, however, you let people find
> users on your service by searching by email, then FOAF's mbox_sha1sum makes
> sense. Or, the lighter version without doing all of FOAF:
>
> <head>
> <meta name="foaf:maker" content="foaf:mbox_sha1sum
> '4caa1d6f6203d21705a00a7aca86203e82a9cf7a'" />
> </head>
Yup. The other thing to mention here (cc:'ing Dirk and Libby, as we
discussed details recently) is the idea of extending FOAF's definition
for foaf:mbox_sha1sum to define a second variant type of value the
property might take, which (a) includes a nonce, to increase cost of
dictionary etc attack (b) defines a more careful canonicalisation of
email (I18N concerns + case normalisation of domains). This should
make foaf:mbox_sha1sum a bit more robust and privacy-friendly,
although still the guidelines you offer make sense.
Julian Bond
>As far as I can tell, if I were to generate foaf files containing all
>the useful public data in my site, they could be huge, and potentially
>slow to generate.
You really don't want to have just a few FOAF files with all the data
from the site. That way lies madness!
Take a look at Livejournal's FOAF[1] (or Ecademy.com's[2]) The most
common model is like this.
- One FOAF file per person
- All the data about that person at the top
- A long list of people that person "knows" each of which has
- An identifier mbox_sha1sum and/or OpenID
- a seeAlso link to their FOAF file.
Now if you have a profile page and a page with lists of contacts, both
of which are created on the fly from database queries, generating the
FOAF file on the fly to express that in RFD-XML should be no more
difficult or time-consuming than creating the HTML. Since the FOAF is
relatively static, you should be able to use a cacheing scheme (squid,
etag, etc) to reduce the queries.
[1]http://voidstar.livejournal.com/data/foaf
[2]http://www.ecademy.com/module.php?mod=network&op=foafrdf&uid=1
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Peel Off Freshness Seal
Martin Atkins
>
> Actually I think we can tease apart the different aspects of XFN. The
> relationship types ie. the list of defined kinds of relationship that
> can exist between people (or agents) have utility outside of the
> specific HTML idioms promoted by microformats.org. In other words,
> there's XFN as a 'vocabulary' versus XFN as a 'notation'. I find value
> in the former mostly for non-public data, and in the latter as a quick
> authoring format for stuff I can import into RDF for SPARQL query and
> data merging. The applicability of the vocabulary shouldn't be limited
> by the scope of the notation; specifically we should be able to mix it
> with any other vocabulary for making claims, without needing the
> blessing of the notation-designers.
>
Certainly. It was the notation to which I was referring. This makes the
assumption that a document will be self-describing; there's no allowance
for storing this metadata in a separate document, and therefore you
can't use it for metadata on things that are not documents.
RDF was of course design with this (storing the metadata in a
decentralized fashion) in mind. However, having the metadata *in* the
resource that they are describing is useful in that this data can be
"trusted" to a certain extent. If I publish an edge from your mbox_sha1
to mine (as opposed to the other way around), it's probably better if
that doesn't get returned from the Social Graph API!
John Breslin
As I understand it, sources of me links from FOAF (those included on
http://code.google.com/apis/socialgraph/docs/edges.html) are things
like weblogs, homepages, mboxen and openids. Is this list indicative
(representing popular IFPs) or just some suggested sources of me
edges?
Can foaf:holdsAccount also be used to create "me" edges? I would hope
so because if you point to other accounts that you hold elsewhere via
your profile (e.g., foaf:onlineAccount(s) or sioc:User(s)), they too
can be sources of more "me" personal profile data and "knows" links.
Also, since FOAF can be used describe people in the social graph and
SIOC can be used to represent social objects, we can then show the
social objects that someone has created via the various user accounts
they hold (see http://www.johnbreslin.com/blog/wp-content/uploads/2008/01/20080104b.png
for an illustration or http://kidehen.typepad.com/kingsley_idehens_typepad/2008/01/foaf-ing-linked.html
for a demonstration).
(While I have you, don't forget our http://webcamp.org/SocialNetworkPortability
workshop in four weeks!)
Thanks,
John.
--
http://www.johnbreslin.com/
Brad Fitzpatrick
foaf:holdsAccount and foaf:OnlineAccount are not creating 'me' edges yet, but should. I'll admit that the FOAF support is currently very weak compared to what it could and should do. Basically, I looked at the largest few social networking sites that publish FOAF and wrote a quick & dirty parser for the information contained in those. I don't even respect, say, foaf:aimChatID or other obvious things I could be using from FOAF. There was a trade-off between releasing early with less data, or releasing later with more complete data. The Social Graph Foo Camp conference kinda answered the question: it'd be more fun to be able to talk about this at the conference and start getting feedback, even with some known possible data lacking. I'd say we made the right choice because both Tantek Çelik and Dan Brickley were able to answer a ton of questions I had about XFN and FOAF, respectively.
Starting Wednesday or Thursday I'm going to be working on improving both the XFN and FOAF parsers. I'd also like to get an interface up sometime where people could live-test the parser and see what edges it emits for a given document, which I think would help eliminate some of the mystery of what's going on.
Keep the feedback coming!
- Brad
Dale Newfield
> by email, then FOAF's mbox_sha1sum makes sense. Or, the lighter
> version without doing all of FOAF:
>
> <head>
> <meta name="foaf:maker" content="foaf:mbox_sha1sum
> '4caa1d6f6203d21705a00a7aca86203e82a9cf7a'" />
> </head>
The only place I can find documentation of this (please tell me if I'm
looking in the wrong place) is <http://usefulinc.com/foaf/iMadeThis>,
which appears to be indicating that this should be placed on a page to
specify the author of said page. Are you saying that your system
interprets the author (node) of any given node to have a "me"
relationship with that node?
-Dale