[foaf-dev] beyond foaf:mbox_sha1sum
richard at cyganiak.de
Sat Dec 19 20:14:59 CET 2009
On 19 Dec 2009, at 18:05, Gregory Williams wrote:
>>> 3. perhaps remove the owl:InverseFunctionalProperty typing (this
>>> 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 .
> I'm not convinced about this "recipe for disaster" stuff. The
> pedantic web page you link to suggests to me that people should just
> be careful when using this term, not that they shouldn't use it.
I didn't say that people shouldn't use the term. I said that you
shouldn't do IFP smushing according to the OWL spec on the term.
Because if you do, you will get horrible results. Several of my
colleagues in DERI have tried it and can tell entertaining war
stories. You need a blacklist of known-bad values, plus a bunch of
additional heuristics, if you want to do smushing on this property.
> The fact that some sites don't properly protect against exporting
> the hash of an empty string (where an email address should have
> been) doesn't strike me as a reason that the sites that do use it
> properly shouldn't benefit from its current use.
Removing the IFP flag from the FOAF spec doesn't stop anyone from
benefitting from the current use of the property. It just means that
an off-the-shelf OWL reasoner won't attempt to do the smushing.
> As for the issue of it not being a true IFP since SHA1 can collide,
> I'm not terribly convinced by this either (modulo the issue of sites
> improperly exporting email fields as hashes). Has anyone ever
> bothered to analyze the potential for collision on mailto: IRIs?
> It's got to be much smaller than the general collision probability
> since email addresses have syntax restrictions, and I wouldn't think
> this is a case where we're worried about the ease of generating
> collisions (since I could simply bypass the generation stage and
> just assert bad data by claiming to have the same sha1_sum as
> somebody else).
>>> 4. encourage data publishers to assign URIs to account holders
>>> directly, to indicate openID URIs and other identifying properties
>>> users permit
>> 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
>> 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?
> Yeah, this is how I use it as well.
More information about the foaf-dev