I’ve been doing quite a bit of thinking about how to represent relationships in portable contact lists. Many of my concerns stem from two basic problems:
- Relationships in one context don’t necessarily translate directly into new contexts. When we talk about making relationships “portable”, we can’t forget that a friend on one system isn’t necessarily the same kind of friend on another system (if at all) even if the other context uses the same label.
- The semantics of a relationship should not form the basis for globally setting permissions. That is, just because someone is marked (perhaps accurately) as a family member does not always mean that that individual should be granted elevated permissions just because they’re “family”. While this approach works for Flickr, where how you classify a relationship (Contact, Friend, Family) determines what that contact can (or can’t) see, semantics alone shouldn’t determine how permissions are assigned.
Now, stepping back, it’s worth pointing out that I’m going on a basic presumption here that moving relationships from one site to another is valuable and beneficial. I also presume that the more convenient it is to find or connect with people who I already know (or have established acquaintance with) on a site will lead me to explore and discover that site’s actual features faster, rather than getting bogged down in finding, inviting and adding friends, which in and of itself has no marginal utility.
Beyond just bringing my friends with me is the opportunity to leverage the categorization I’ve done elsewhere, but that’s where existing formats like XFN and FOAF appear to fall short. On the one hand, we have overlapping terms for relationships that might not mean the same thing in different places, and on the other, we have unique relationship descriptions that might not apply elsewhere (e.g. fellow travelers on Dopplr). This was one of the reasons why I proposed focusing on the “contact” and “me” relationships in XFN (I mean really, what can you actually do if you know that a particular contact is a “muse” or “kin”?). Still, if metadata about a relationship exists, we shouldn’t just discard it, so how then might we express it?
Well, to keep the solution as simple and generalizable as possible, we’d see that the kinds of relationships and the semantics which we use to describe relationships can be reduced to tags. Given a context, it’s fair to infer that other relationships of the same class in the same context are equivalent. So, if I mark two people as “friends” on Flickr, they are equally “Flickr friends”. Likewise on Twitter, all people who I follow are equally “followed”. Now, take the link-rel approach from HTML, and we have a shorthand attribute (“rel”) that we can use to create a machine tag that follows the standard namespace:predicate=value format, like so:
flickr:rel=friend
flickr:rel=family
twitter:rel=followed
dopplr:rel=fellow-traveler
xfn:rel=friend
foaf:rel=knows
Imagine being able to pass your relationships between sites as a series of machine tagged URLs, where you can now say “I want to share this content with all my [contacts|friends|family members] from [Flickr]” or “Share all my restaurant reviews from this trip with my [fellow travelers] from [Dopplr|TripIt].” By machine tagging relationships, not only do we maintain the fidelity of the relationship with context, but we inherit a means of querying against this dataset in a way that maps to the origin of the relationship.
Furthermore, this would enable sites to use relationship classification models from other sites. For example, a site like Pownce could use the “Twitter model” of followers and followed; SmugMug could use Flickr’s model of contacts, friends and family; Basecamp could use Plaxo’s model of business, friend and family.
Dumping this data into a JSON-based format like jCard would also be straight-forward:
{
"uid": "plaxo-12345",
"fn": "Joseph Smarr",
"url": [
{ "value": "http://josephsmarr.com", "type": "home" },
{ "value": "http://josephsmarr.com", "type": "blog" },
],
"category": [
{ "value": "favorite" },
{ "value": "plaxo employee" },
{ "value": "xfn:rel=met" },
{ "value": "xfn:rel=friend" },
{ "value": "xfn:rel=colleague" },
{ "value": "flickr:rel=friend" },
{ "value": "dopplr:rel=fellow-traveler" },
{ "value": "twitter:rel=follower" }
],
"created": "2008-05-24T12:00:00Z",
"modified": "2008-05-25T12:34:56Z"
}
I’m curious to know whether this approach would be useful, or what other possibilities might result from having this kind of data. I like it because it’s simple, it uses a prior convention (most widely supported on Flickr and Upcoming), it maintains original context and semantics. It also means that, rather than having to list every account for a contact as a serialized list with associated rel-values, we’re only dealing in highly portable tags.
I’m thinking that this would be very useful for DiSo, and when importing friends from remote sites, we’ll be sure to index this kind of information.
Factory Joe 
Is you are tagging the relationship, can’t we drop the ‘rel’ part? For example, just tag a relationship twitter:follower.
Eran – it’s true that you can, but machine tags follow the
namespace:predicate=valuepattern, so that it can be parsed out easily. In the future, for some sites, a different predicate might make sense, even in the context of arelattribute.Why not use a real URI? “foaf:rel=knows” is http://xmlns.com/foaf/0.1/knows and “xfn:rel=friend” is http://www.gmpg.org/xfn/11#friend – both themselves possible tag URIs, but also having the neat ability in that you can dereference them and get out interesting information.
For use in HTML, individual services can just use some other rel value, like rel=”fellow-traveller”, and you can glean the meaning of it from the domain.
I like the approach but it arise on me a doubt about its ps implications.
Due to the extremely fluid character of web relationships, the representation/tagging of them, seem to me like a way to fix them into a certain level. With ‘permanent’ bounds like family, the system you propose seem very appropriate and necessary! But with web-based relations this could be inconvenient.
In my experience, best relationships made in social networks tend towards the blurry and, ideally erasure of the medium they arouse from. And, as you do suggest, a successful contact for me is the one who can translate directly and fluid from flickr to mail and SMS… so I think using a tagging r. machine could make translations harder.
Ex: best poke buddy is not just a ‘facebook friend’ -as he’d be tagged in portable list- but a friend. So what I mean is that, in some cases adding the context will also re-affirm and fix the virtuality and the ‘hierarchy’ of a relationship, which is, luckly, not a desired thing.
…still I’d like a lot to see your developement on this machine. Cheers
@Eran, the other aspect is that machine tags can be useful for other pairings, such as twitter:user=factoryjoe or twitter:status=123456. Given that Flickr already uses this convention, as Steve described, means that we’re not doing simple name:value pairs, but using something that has already gained some traction…
my first impression is that the origin of the service is already encoded in the href URL. dopplr.com/me already says the service is dopplr, but there isn’t a standard way to extract that information since formats like me.jaiku.com or last.fm/users/me are also popular.
using ‘machine tags’ in XFN seems to have lots of potential. the data providers can maintain backwards compatibility since rel=”friend” can co-exist with twitter:rel=”friend”.
will a service name come to mean a style of friendship? like xerox has come to mean photocopying, will a competing microblogging platform add xfn tags of twitter:rel=”friend” because its a twitter-style relationship rather than an actual twitter friend.
@Don Perhaps it’s just a temporary-adaptation process but I think that, more than the plataform /brand is the game language used in each software what do shape -until certain (perhaps light but real) degree- the relationships sustained there.
Feel the mixing of languages expand the richness of contacts in a fast increasing way. So as languages, relationships are changing in a very high speed, so it can become tedious to re-tag and re set the access permissions under regular basis.
Very interesting idea, Chris. The real benefit I see is the ability to port and re-use an existing model from a third-party site. In the same way Ma.gnolia now effectively out-sources its identity verification to third-party sites, a site could out-source its entire relationship structure.
It’s not that my site might not want to create our own relationship model, but being able to use one from somewhere else that stays current would sure cut out a lot of friction!
And what does a flickr.org or twitter.net do? How can we justify not using fully qualified domain names?
@Lachlan: exactly. Especially if you’re just a service built on top of, say, a collection of photo-sharing services, having a uniform relationship model might greatly reduce your overhead and having to reinvent established protocols.
It’s also a way of dumping one file with ALL my relationships from EVERY social network between services and allowing for my relationships (to identities that have been consolidated) to move in one fell swoop. Rather than having to ask each individual service what the relationship is, I can be authoritative about the relationship I have to my contacts.
@Terrell: Good question. I’ll have to circle back to the machine tag originators, but I think it just becomes a competition for the authoritative namespace. Of course using the fully-specified domain might prevent some confusion, ultimately it’s just like using tags on social networking sites (i.e. ‘development’ has many different verticals). I don’t see much value in trying to co-opt a given namespace… I mean, so what if it’s a flickr.org namespace? Comparing a “flickr.org friend” to a “flickr.com fiend” seems like a losing proposition. Still, I’ll ask around and see what the CW is.
We chose not to use fully qualified URLs for namespaces because they are, at worst, weird and scary and confusing and, at best, hard to type.
The goal with machine tags was to offer just enough syntax to let people better structure — and search — their tags without sacrificing the ease of plain-old tagging itself.
Our experience has been that if people really need to disambiguate their namespaces they add an extra “xmlns:$NS=$URL” machine tag to their photos. This has been the case so far with institutions participating in the Commons, anyway.
(Tangentially related is Eliot Kimbel’s wonderful, albeit nerd-irific, post titled “I was wrong (sort of) about namespaces“.)
Finally, to answer the question about service:* or *:service I will only say that I use the former since the search API allows me to query for “*:event=” or “*:user=” which returns results across multiple services, say upcoming and lastfm, in one go.
Likewise, “aero:*” allows me to investigate only those properties belonging to a single namespace (planespotters in this case).
But there are no rules. Like tagging, the hope is that the various communities will arrive at and adapt a consensus according to their needs.