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.

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.

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!

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.

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.