[foaf-dev] Anatomy of a FOAF File

Melvin Carvalho melvincarvalho at gmail.com
Thu Oct 22 16:50:23 CEST 2009

Hi All

I've been thinking a bit about a good way to structure a FOAF file,
and here are my thoughts.  Much of this is inspired by tabulator, and
presents an MVC model of the read/write web.

I think of your FOAF file as the "head of an octopus" with each of the
"tentacles" holding your online "assets".

Basically the head the smart part of the system and acts as a semantic
entry point, but is strongly linked to many other areas, which may be
on the same server, across domains, or even on a local device.  I'll
try and describe the minimum functions I think each of the components
ought to have.


This is FOAF/RDF based and will contain the following:


1. Profile data
2. Contacts data
3. ACL - this is complex and involves groups too

It's necessary that the ACL is closely coupled with model, as this is
necessary for it to be displayed correctly.  I think there is an
advantage to putting all of this in a single file, as it allows the
user to download their whole profile.


4. External accounts - this increases your web footprint
5. Web of Trust - trust and reputation data (I thought about this as
core originally, but changed my mind)
6. Assets - virtual and real
7. Other - as RDF is schemaless, this is infinitely extensible



1. At a minimum, your controller should be able to use the ACL to work
out which field to display


2. Should be able to handle conneg
3. Should be able to authenticate a request from query string / cookie
/ client data
4. Should be read/write and therefore be able to handle SPARUL


5. Should have a request approval system (approve/decline)
6. Should have a queuing mechanism to handle user being offline
7. Should have modluar "handlers" which will interpret (rich) requests
and route them to intelligent handling functions
8. Should be able to interact with a user client in realtime, or near real time

(7) should of course be able to interact with linked data as part of
the logical stream.  One example would be to add a handler for a
SPARQL request, thereby making you a SPARQL endpoint.


1. Display the RDF (format optional)
2. Would recommend RDFa support, with perhaps lenses
3. Would recommend editable fields over RDFa / (X)HTML
4. Would recommend lenses to pull in linked data and display summaries
of your other assets.

So that's my skeleton framework.  In this way the user can have an
intelligent controller sitting behind their FOAF / WebID and leverage
lots of other services and assets that can build up in your web
footprint, over time.

That's all I can think of at the moment, and lots needs to be fleshed
out more concretely, but please let me know if there's anything I may
have left out.

More information about the foaf-dev mailing list