[foaf-dev] beyond foaf:mbox_sha1sum
danbri at danbri.org
Sat Dec 19 22:05:09 CET 2009
On Sat, Dec 19, 2009 at 9:21 PM, Damian Steer <pldms at mac.com> wrote:
> On 19 Dec 2009, at 14:42, Dan Brickley wrote:
>> 1. mark foaf:mbox_sha1sum as archaic
> As others have said, premature.
Just testing the waters :) I retract the 'archaic' proposal; however
this is something of a plan to make it more archaic in practice...
>> 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
> Sound reasonable to me. The main lesson to be drawn has little to do with foaf and hashing, though: merely making you name public may provide sufficient information to guess your email address.
Yes, and lots of other information (in aggregate, eg. movie
preferences or fairly bland-seeming demographics) can also often
identify you too. It might be that we ought to be working on more end
user -facing docs, perhaps in collab with dataportability.org and via
the W3C SocialWeb XG.
>> 3. perhaps remove the owl:InverseFunctionalProperty typing (this will
>> help with OWL DL compatibility too)
> Not sure what this is supposed to achieve in this context?
i) Gently nudging developers towards using other identification constructs
ii) Improving likelyhood of FOAF data and its extensions / companion
vocabs being usable within DL-based systems
> You might want to add a literal range to the mbox_sha1sum to make it immediately DL incompatible.
> Additionally we know have the shiny new hasKey. Would adding Agent hasKey ( mbox_sha1sum ) make DL happier, or compound the existing insult?
Last I heard, that only worked when the resource bearing the key'd
property wasn't a bnode. Which is pretty much not fitting with most
mbox_sha1sum data out there. Still, it's a nice addition to the
Also from Greg:
> But the current use of the property involves the fact that it's an IFP. Removing the IFP flag might stop people from
> benefitting from smushing unless they know specifically to add it
back in. I'm open to the idea that smushing can lead to
> unwanted results, but removing the IFP flag will clearly change the semantics involved and could dramatically affect the > functioning of existing systems.
I'm aware it might have some such affects. I would like to know what
exactly would break, in real systems. If it is going to crash
helicopters, set hospitals on fire, or lose people friends on social
networking sites, better we find out sooner rather than later. Nobody
should be basing mission-critical app functionality on the presence of
a single triple in http://xmlns.com/foaf/0.1/index.rdf - e.g. what if
the site gets hacked or DDOS'd off the 'net?
That said, I don't want to cause problems on idle whim, of course. So
I would suggest we prepare a package of changes designed for
publishers and consumers to understand, and include recommendations
for more future-proof identification strategies. And when the change
is made, we should be on careful standby to see if anything major
breaks. I don't think that's likely but you never know...
More information about the foaf-dev