[foaf-dev] beyond foaf:mbox_sha1sum

[Richard Cyganiak]

On 19 Dec 2009, at 14:42, Dan Brickley wrote:
> Time to gently retire it?
> http://ebiquity.umbc.edu/blogger/2009/12/17/foafmbox_sha1sum-considered-harmful/
> etc
>
> Thoughts on ways forward?
>
> 1. mark foaf:mbox_sha1sum as archaic

No. It's in wide use, and it has valid uses, althout it's perhaps  
overused ATM.

> 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

It's certainly good to emphasize the risks. There could be something  
like: “A service that promises to keep users' email addresses private,  
should not publish the sha1-obfuscated form either.”

I still think that the property is useful for translating mailing list  
archives to RDF, for example. The text should not be so alarmist that  
it discourages such uses.

> 3. perhaps remove the owl:InverseFunctionalProperty typing (this will
> help with OWL DL compatibility too)

+1. In practice, doing IFP smushing on this property according to the  
OWL spec is a recipe for disaster anyway [1].

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

+1. Remember that “blank node + foaf:mbox_sha1sum + smushing” was  
considered pretty much the canonical way of doing distributed  
identification in FOAF. The spec should clearly communicate that URIs  
are the way to go, and perhaps could mention the sha1sum smushing

Also: Remove the mbox_sha1sum from the prominent example at the  
beginning of the spec.

Tangent: I find mbox_sha1sum useful for adding former email addresses  
that I no longer use to my FOAF file. The hashes can still be used for  
smushing, but no one would mistake the old email addresses as being  
current. That's something I could not do with foaf:mbox alone. Is  
there a case for a new property or some sort of new idiom here?

Best,
Richard

[1] http://pedantic-web.org/fops.html#ifps


>
> cheers,
>
> Dan
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev