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.

This entry was posted in General, Semantic Web. Bookmark the permalink.

4 Responses to Getting FOAF files from the desktop to the Web

  1. Danny says:

    I’m not so sure how much ftp is king any more, with the number of people publishing/blogging through hosted CMSs. Where client posting is available it’s more likely to be the (pretty nasty) XML-RPC-based Blogger and/or Metaweblog APIs. The Atom Protocol looks set to provide a web-friendly alternative, and as you say there is WebDAV. Hmm, APP not yet adopted, XML-RPC is horrid, er…I guess that still means ftp is probably the best bet.

    foaf.rdf#me – can I put my hcard version there too?

  2. Dan Connolly says:

    “HTTP PUT has already failed in the marketplace”. baloney. How do you think WebDAV works?

  3. Dan Connolly says:

    “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 …” Amen to that.

  4. Dan, good point about WebDAV using HTTP PUT. I should have written, “HTTP PUT in its original simple non-WebDAV form has failed.”