Getting FOAF files from the desktop to the Web

Henry Story considers design alternatives for a FOAF-enabled personal address book that works as a desktop application. How will it publish the users’ FOAF profile to the Web?

The first scenario considered by Henry is an individual who wants to publish to her own webspace. Here, in my eyes, FTP is king. Henry is right when he says:

[FTP is] a little tricky for the end user as he would have to understand the relation between the directory structure of the ftp server and its mapping to the web server urls.

But FTP is everywhere, and Web geeks are able to figure it out. This 75% user experience will be much better than the current “write RDF/XML by hand or use FOAF-a-matic” approach. (Anyway, it’s what I use to publish my FOAF file.)

The next thing could be WebDAV because it is fairly common and could provide a 90% user experience. As for the other options: scp has not enough users, APP is still too obscure, and HTTP PUT has already failed in the marketplace.

Henry also wonders about server configuration. Servers have to be set up for the correct MIME type, 303 redirects and so on. This has to be done differently depending on the server.

Don’t bother. Put foaf.rdf on the server, take foaf.rdf#me as the person’s URI. When this works, then you can think about adding server type detection code and a “Use cool URIs” checkbox that drops the proper .htaccess file on the server. Keep in mind what’s possible.

The enterprise is Henry’s second scenario:

These companies already have a huge amount of information on their employees in their ldap directory. This is reliable and authoritative information, and should be used to generate foaf files for each employee. … Now the question is: should this foaf file be read only or read/write? If it is read/write then an agent … could overwrite the file with different information from that stored in ldap, which could cause confusion, and be frowned upon.

Both the user’s desktop application and the company’s LDAP server can contribute useful information. How to combine them? Henry suggests two solutions. The first one – the server could compare the client’s file to his own data, and reject any contradictory bits – doesn’t convince me, it puts too much complexity on the server.

The second one is an external link in the read-only company-generated RDF. It points to another RDF file that can be edited by the desktop application just as in the other scenario. I like it. And there’s already a perfect property for the link: the good old rdfs:seeAlso.

Multiple files with links between them are much simpler than files of mixed ownership. That’s why we call it Linked Data.