[foaf-dev] beyond foaf:mbox_sha1sum

Dan Brickley danbri at danbri.org
Sat Dec 19 21:54:37 CET 2009


On Sat, Dec 19, 2009 at 6:50 PM, Richard Cyganiak <richard at cyganiak.de> wrote:
>
> 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.

I agree with all that. We are still finding the limits of this new
term 'archaic', and it would be easy to over-use (and hence devalue)
it.

BTW http://www.w3.org/2003/06/sw-vocab-status/ns# is updated to
mention the new value 'archaic'; and I'm looking into getting a tiny
W3C SWIG Note drafted, since lots of namespaces use that vocab.

>> 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.”

Yes - I like that wording :)

> 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.

This is a good use case, at least for publically archived mailing
lists. Unlike the case of a social network where a user might have
registered using a secret and identifying email address, with a
mailing list they are using the address with a larger group. The
former rule (about privacy promises) should override though.

>> 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].

(Aside: the OWL2 stuff did take some steps to make literal-valued IFPs
usable btw, although I think they still require non-bnodes.)

>> 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.

That's a bit of an overstatement; but yes, it did become very popular,
I think mostly because of foaf-a-matic.

http://lists.foaf-project.org/pipermail/foaf-dev/2003-July/005463.html
is the canonical statement on 'identifying things in foaf' from 2003.

Extract,
"This is one of the design principles underlying FOAF (and for that
matter the entire Semantic Web effort): a pragmatic, pluralistic
approach to resource description and identification. Rather than
building big, centralised registries of people (or companies, or
physical things) we look for cheaper, more lightweight shared strategies
for identification. In FOAF, we do this by making sure there are
multiple ways we can identify things."

This was in large part a response to early year accusations against
RDF that it was hopelessly naive since it allegedly assumed that
everything will have a globally known URI. So we took care to show
that RDF can deal with heterogeneity and that multiple compatible
mechanisms can be plugged together.

> The spec should clearly communicate that URIs are the way to go, and perhaps
> could mention the sha1sum smushing

URIs in their various flavours; both indirect (homepage, openid) and
direct (#me / webID). In both cases the party controlling the URI is
in a position of some trust, since they'll see more than anyone when
the person is being "looked up".

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

Good point

> 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?

In http://danbri.org/foaf.rdf I use
    <mbox>
      <rdf:Description rdf:about="mailto:danbri at w3.org">
        <dct:isReplacedBy rdf:resource="mailto:danbri at danbri.org"/>
      </rdf:Description>
    </mbox>

This is a bit verbose (and it indirectly keeps the old form in
circulation). Wonder if it's nicer in RDFa.


cheers,

Dan

> 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
>
>


More information about the foaf-dev mailing list