[foaf-dev] beyond foaf:mbox_sha1sum
richard at cyganiak.de
Sat Dec 19 18:50:04 CET 2009
On 19 Dec 2009, at 14:42, Dan Brickley wrote:
> Time to gently retire it?
> 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
> 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 .
> 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?
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
More information about the foaf-dev