[foaf-dev] Fwd: [DP.AG.Policy] Tribe drop FOAF

Kingsley Idehen kidehen at openlinksw.com
Tue Mar 25 18:35:47 GMT 2008


crispy wrote:
> Danny et. al.
>
> The only problem with this analysis is that the foaf generator for
> tribe did in fact respect the wishes of the user with respect to what
> data to expose. The basic drive here was from a user who didn't
> understand what it means to publish data and a current operator who
> didn't understand the feature at all. Tribe is not a good example of
> what a social network can and should do as there are no longer any
> employees who know anything about social networking as a product or
> the software tribe runs. It's a sad state to see the product i helped
> build to fall into disrepair due to neglect and incompetence.
>
> chris vale
>   
Chris,

Unfortunately, we have a new trend taking shape:

1. Use the Semantic Web banner to promote and effort
2. Do it incorrectly
3. Blame the Semantic Web

I cannot understand why any of these services wouldn't do the utmost to 
let their users control issues relating to privacy such as personal 
profile attributes. Ironically, users respond so strongly because they 
assumed these fundamental principals were in place during the sign-up 
process.

Unfortunately in today's "Attention and Popularity" driven economy, 
"FOAF is bad" and "FOAF is part of the Semantic Web" are the only things 
people will remember from this episode :-(

Kingsley
> On Mon, Mar 24, 2008 at 1:32 PM, Danny Ayers <danny.ayers at gmail.com> wrote:
>   
>> [fwd to foaf-dev]
>>
>>
>> ---------- Forwarded message ----------
>> From: Julian Bond <julian_bond at voidstar.com>
>>  Date: 24 Mar 2008 10:15
>> Subject: [DP.AG.Policy] Tribe drop FOAF
>> To: dataportabilityactionpolicy at googlegroups.com
>>
>>
>>  See here
>>  http://brainstorm.tribe.net/thread/34fb1a79-351d-4251-8318-829623c1c9cb
>>
>> [
>>  here's the other thread.
>>  http://brainstorm.tribe.net/thread/b21159ad-f181-4e34-852f-10c46fe3cc1d
>>
>>  http://people.tribe.net/tjcrowley says
>>  FOAF is gone. I removed it entirely. as a result, though, I am
>>  investigating implementing iCal or vCal for events, and vCard for
>>  people.
>>  ]
>>
>>  Tribe was one of the early SNs to support and produce FOAF. The founders
>>  left. An aggregator appeared that read that data and republished it.
>>  Tribe members got upset about their data appearing elsewhere on the web.
>>  The Tribe developers decided to deal with the storm by simply removing
>>  the code.
>>
>>  There are similarities here with Facebook. FB introduce the Activity
>>  Feed. They put in RSS. The RSS gets read, aggregated and republished. FB
>>  members kick up a storm about the perceived loss of privacy. FB kill the
>>  RSS.
>>
>>  My view on all this.
>>  - It's hard to explain to members what exactly is happening. They're
>>  just beginning to understand RSS, but FOAF is confusing.
>>
>>  - If it's visible publicly in HTML, then it ought to be visible publicly
>>  in a more structured form.
>>
>>  - If it's not visible publicly in HTML you have to be very careful about
>>  what is exposed in structured form.
>>
>>  - You need to give members an opt out, some times at field level from
>>  having their data visible.
>>
>>  - Private data used by the individual concerned can leak out and become
>>  public. See here Private RSS feeds ending up being globally searchable
>>  in public readers.
>>
>>  - Getting the licenses right and enforcing them is hard. What does
>>  "re-publish" mean? We're happy with Google to index our pages and show
>>  abstracts and cached versions. But apparently we're not happy for an
>>  unknown site to index our contacts and profiles and show abstracts.
>>
>>  There's a polarisation here between Privacy denyers and Privacy
>>  Fanatics. One group relishes the exposure and actively uses the lack of
>>  privacy for personal branding and reputation development. The other
>>  wants to be able to participate in internet based services but remain
>>  effectively anonymous. Obviously there's shades of grey in the middle.
>>  But it's sad to see the second group forcing decisions that ultimately
>>  reduce the value of those services largely because they don't understand
>>  what's happening and had a mistaken view of how much privacy they had in
>>  the first place.
>>
>>  --
>>  Julian Bond  E&MSN: julian_bond at voidstar.com  M: +44 (0)77 5907 2173
>>  Webmaster:          http://www.ecademy.com/      T: +44 (0)192 0412 433
>>  Personal WebLog:    http://www.voidstar.com/     skype:julian.bond?chat
>>                          Your Mileage May Vary
>>
>>  --~--~---------~--~----~------------~-------~--~----~
>>  You received this message because you are subscribed to the Google Groups
>> "DataPortability.Action.Policy" group.
>>  To post to this group, send email to
>> dataportabilityactionpolicy at googlegroups.com
>>  To unsubscribe from this group, send email to
>> dataportabilityactionpolicy-unsubscribe at googlegroups.com
>>  For more options, visit this group at
>> http://groups.google.com/group/dataportabilityactionpolicy?hl=en
>>  -~----------~----~----~----~------~----~------~--~---
>>
>>
>>
>> --
>> http://dannyayers.com
>> ~
>> http://blogs.talis.com/nodalities/this_weeks_semantic_web/
>> _______________________________________________
>>  foaf-dev mailing list
>>  foaf-dev at lists.foaf-project.org
>>  http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>>
>>     
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>
>   


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com






More information about the foaf-dev mailing list