[foaf-dev] beyond foaf:mbox_sha1sum

Dan Brickley danbri at danbri.org
Sat Dec 19 17:51:20 CET 2009

On Sat, Dec 19, 2009 at 5:26 PM, Story Henry <henry.story at bblfish.net> wrote:
> I agree. If one is to publish an email address, it may be better to have servers that can content negotiate so as to make that information visible only to trusted agents. And it is not clear at that point what the advantages of sha1sumed mboxes are.

If my mailbox wasn't really secret as-such, I just didn't want to
splash it around everywhere in public, mbox_sha1sum was an OK fit;
this allowed us to bootstrap RDFWeb/FOAF with self published FOAF
files and no server-side infrastructure.

This describes the habits of many of the 'internet culture' folk using
RDF in late 90s, and those who were in the early RDFWeb and FOAF scene
2000-2003. It doesn't describe well the 'born digital' youngsters who
use IM and social networks more than email; nor the more cautious
older generation who make tentative use of email, facebook etc but
aren't particularly comfortable with technical detail nor able to
evaluate questions of online risk and probability.

>> Thoughts on ways forward?
>> 1. mark foaf:mbox_sha1sum as archaic
> yes

If anyone objects, please speak up loudly...

>> 2. rewrite http://xmlns.com/foaf/spec/#term_mbox_sha1sum to more
>> clearly emphasise the risks, and that decision to publish shouldn't be
>> made for others
> yes

In particular, the spec's language is generally couched on the
assumption of self-publication. It isn't clear how we should reflect
the growing practice of publishing information on behalf of others.

>> 3. perhaps remove the owl:InverseFunctionalProperty typing (this will
>> help with OWL DL compatibility too)
> not sure. It is true that it cannot be a purely inverse functional property, since sha1sums have collisions

Yes. I always thought we could add a footnote to wiggle out of that,
eg. by picking the alphanumerically-first value as the 'real' value,
but there's no merit for that.

Removing the IFP flag will probably affect the functioning of systems
like Sindice; I'd like at least to give them some warning of the

>> 4. encourage data publishers to assign URIs to account holders
>> directly, to indicate openID URIs and other identifying properties as
>> users permit
> yes. And WebIds.

That's what I meant by 'assign URIs to account holders' :)



More information about the foaf-dev mailing list