Title
FOAF implementation
Short, concise description of the idea
There is an XML/RDF standard in development called "FOAF", or friend of a friend. It's a machine-readable way of listing your own personal information and listing your friends in a standardized way. Since LJ already has both the personal info (whatever the user has entered in the "Personal Info" section) and the links (the friends list), it has everything it needs to build them in an automated fashion.
Full description of the idea
These urls link to documents which explain FOAF:
http://xmlns.com/foaf/0.1/
http://www-106.ibm.com/developerworks/xml/library/x-foaf.html
A sample foaf can be generated here:
http://www.ldodds.com/foaf/foaf-a-matic.html
Basically, FOAF lets you specify your identity and information, and link it to other people. They can do the same thing, and moreover theoretically FOAF-aware apps will be able to follow the links and fill in information - in other words, it's a way to have a decentralized database of personal information for people, linked from site to site. LJ could output FOAF files via an automated url, which would let FOAF-aware apps pull the data, which has a lot of possibilities. For instance, there could be a FOAF-enabled friends view, which would make it much easier to be linked to from other blogs and to link to other blogs in an automated fashion - like rss, it's a useful tool for extending the capabilities and reach of LJ without a lot of extra work.
An ordered list of benefits
FOAF has the same sorts of benefits that an RSS version of the user's journal has.It allows FOAF-aware apps to link to and pull information from the journal easily and in an automated fashion.(That's the only one I can think of, but if you think about it, that's a big one. Assuming it takes off like RSS has, soon most pages will have FOAF files with links to other peoples' FOAF files, creating a huge, interconnected, decentralized database of peoples' basic information. That's pretty nifty.)An ordered list of problems/issues involved
There are some potential privacy issues. However, FOAF has a way of encoding email addresses (it takes a checksum of it) and users could simply check off which information they'd want to be in their FOAF.It would take some time to code, and some thought should go into the implementation.Finally, the FOAF standard may potentially change. I don't see this as being a huge problem - it's versioned, and as new versions are released, and it has its own version number in a compliant FOAF file. If a new version is released, LJ could just update the output - and until then, nothing should break, as long as external apps still respect older revisions of the standard.An organized list, or a few short paragraphs detailing suggestions for implementation
Well, the way I see it, there's just be a new bml page that would output it. It could look something like http://www.livejournal.com/foaf.bml?user=suggestions or whatever, the url isn't that important. Basically, it would just output the same basic info that the userinfo page does, but it would do it in a machine-readable, standardized, xml/rdf-based format (similar to the way ~username/rss works).There may need to be a few options added to the editinfo page, such as "do you want to display a FOAF page?" (with a link to some docs, I assume), and a series of check-boxes (or a dropdown, like the current contact info) so users can choose what info to output in their FOAF. Otherwise, whatever info is displayed on their userinfo page publically could just be used.Implementation should be relatively easy; basically, the userinfo bml page could just be updated to output the data in the FOAF format, and that's about all that'd need to be done. Adding an optional link to the user's userinfo page to display it in FOAF format would be nice.