Why foaf? http://www.ideaspace.net/users/wkearney/archives/entries/000274.html One value behind foaf is it's ability to present multiple URI as references to the 'same' person. That is, my... wkearney 2003-04-19T13:02:55-05:00 http://www.ideaspace.net/users/wkearney/archives/entries/000274.html en-us One value behind foaf is it's ability to present multiple URI as references to the 'same' person. That is, my... 2003-04-19T13:02:55-05:00 One value behind foaf is it's ability to present multiple URI as references to the 'same' person. That is, my own foaf at http://www.ideaspace.net/users/wkearney/foaf.xrdf (yeah I could shorten the URL) contains URI that other systems can use as references 'to me'. One nice advantage to foaf (and it's basis in RDF w/dublin core) is the ability of this file to stand up as a kitchen junk drawer sort of repository for anything that *I* want to say about things related to me.

]]> One value behind foaf is it's ability to present multiple URI as references to the 'same' person. That is, my... At the same time another person could be using the mbox hashes to indicate they "know me" or that I participate in some tangentally related effort. Given the URI, in this global form as an Identifier, it becomes possible for software, should it care, to 'walk the links' and spider to wherever those common URI appear.

As for REST/RPC, please, let's not get bogged down into /that/ argument. Suffice to say that ONCE the data becomes accessible, grafting either RPC or REST style interfaces onto it is often a trivial matter of some clever web server Rewrite rules. /How/ you chose to get to the information is perhaps of significantly less importance that being /able/ to get to it at all.

To that end, this spidering of triplespace lends the opportunity for software to do much more sophisticated referencing of the relevant bits. Having my foaf say where PKI participating services can 'find out more' would be tremendously helpful. Not from the perspective that /only/ one location contained it all. But that one could be maintained as a reasonably authoritative statement about where the /others/ are known to exist.

As in, I have control over MY foaf document. It lives at a given URL. I can add to that foaf document URLs that point to other sources of authoritative information. Those can likewise point back to mine. This way if my foaf contained a Liberty URL that same service could reference my Foaf. Should it care the possiblity exists for one to challenge the other possibly using the ideas of PKI signatures. The expectation is that if something "wasn't right" those same documents could contain URLs that pointed to how to reach my cell phone via SMS for confirmation (like MS already does with Passport). Thus I'm not beholden to any one service save for my willingness to stand up a document that gives indication as to how the others can or can't interact with it.

At the core of all this NEEDS to be better auditing. At the very least I want these autonomous uses to send or make available to me auditing logs. I don't have a problem if one service verifies that "something" exists. We have a parallel for this in the real world; credit reports. There's no reason (not CPU, diskspace or bandwidth) that the very same thing should be DEMANDED from expanding systems such as this. This would go a long way to assuage worries about "who's been using or asking about my data". I notice this is conspicuously absent from the p3p systems I've seen to date. Yes, it's a lot of data. No, we're not going to let you play with it without being accountable.

Anyway, the idea of "trust but verify" can be aided by extensible mechanisms like XML, RDF and FoaF.

]]> 274 273 275