Re: [foaf-dev] announce: F2F MediaWiki extension - pre-alpha OpenID trust group RDFa exporter

Hi Dan,

Thanks for progressing this! Having previously run a small wiki which was
spammed to death - and eventually having to shut it down I know from
personal experience the need is there!

A few random thoughts when I thought about similar things.

I naively think about http://wiki.foaf-project.org as being an agent of
sorts and the list of account on the wiki as a list of agents it "knows".
These agents in turn can say they "know" http://wiki.foaf-project.org . I
think the sematics of the above are not allowed in the current ontology this
directly but I would be tempted to add an rdf:about to each agent in
http://wiki.foaf-project.org/w/Special:F2F to the account page that each
user has on the wiki. In my case
http://wiki.foaf-project.org/w/User:Akbarhossain.com . I could then add an
entry into my foaf file to my account on the wiki. So
http://wiki.foaf-project.org say is "knows" my openid http:\\
akbarhossain.com and i say i know http://wiki.foaf-project.org in my foaf
file via my account http://wiki.foaf-project.org/w/User:Akbarhossain.com

I think ideally http://wiki.foaf-project.org/w/User:Akbarhossain.com would
have an entry saying it is a member of this group
http://wiki.foaf-project.org/w/Special:F2F#!aActiveOpenIDTrustGroup.

I would also be tempted to add some entries into  the
http://wiki.foaf-project.org/w/Special:F2F to express the ACL of the wiki.

I guess eventually I could see a scenario where perhaps openids you accept
for comments on  your blog http://danbri.org/words/2009/12/29/523 are
members of the ACL with editing rights automatically for example.

Thanks



On Wed, Oct 20, 2010 at 10:54 AM, Dan Brickley <[email protected]> wrote:

> ==Background==
>
>  * public facing, open Wikis are being spammed heavily. Information
> in the wiki is either damaged by spam/malware attacks, or locked away
> in read-only mode, making community contributions needlessly
> difficult. Many such wikis exist and have overlapping communities of
> contributors and potential contributors. Spam techniques are
> increasingly subtle, and machine filtering is proving inadequate. It
> is difficult for admins of a wiki to know who they can trust with
> write access, if they want to maximise contributions to their content
> and at the same time, take care to protect those contributions from
> vandalism. If a wiki is left open to the public, it will be
> vandalised. If it is made editable only by a small group, it will
> often fail to reach its full potential. This is unfortunate.
>
>  * This situation causes a trend towards centralisation - both in
> terms of culture/content (people simply use Wikipedia and other large
> sites), but also in terms of identity technology ('comment with your
> twitter / facebook id', etc.) which can exclude users who choose not
> to use the market-leader sites. Both aspects threaten the diversity
> and pluralism that make the Web interesting.
>
>  * Many users increasingly have access to openids (and via eg.
> openid4.me, from webid too).
>
>  * Recent MediaWiki releases makes it easier for wiki pages to be
> automatically generated with machine-readable markup RDFa).
>
> ==Overview==
>
>  * This is an experiment in sharing trust-related metadata about
> people's login-capable Web identifiers - homepages, blogs etc that are
> wired up to OpenID.
>  * Wikis and blogs can both produce and consume this kind of data.
> Every time you accept a comment into your blog or wiki, and that
> comment was made by OpenID, you are accumulating evidence that people
> can use when deciding whether to trust that OpenID elsewhere.
>  * F2F exporters are simple addons for blogs and wikis that (with some
> tweaking/customisation) can publish descriptions of the groups of
> openids known to some software installation
>
> ==Status==
>
> Previously...
>
> * from 2009 http://danbri.org/words/2009/10/25/504 'Syndicating trust?
> Mediawiki, Wordpress and OpenID' initial writeup
> * http://danbri.org/words/2009/12/29/523 'WordPress trust syndication
> revisited: F2F plugin'
> * Mediawiki notes http://wiki.foaf-project.org/w/DanBri/MediawikiOpenid
>
> There is already a basic exporter for Wordpress. Today I got same
> working for MediaWiki (thanks to mhausenblas, presbrey in irc for
> help!)
>
> This is pretty rough still, but I hope it gives others some basic
> pieces to build upon.
>
> Sample installation: http://wiki.foaf-project.org/w/Special:F2F (gives
> an RDFa page describing some trusted openids)
>
> Source code: check out F2F/ from
> http://svn.foaf-project.org/foaftown/2010/mediawiki/extensions/F2F/
> subversion into your MediaWiki extensions/ dir.
>
> See
> http://svn.foaf-project.org/foaftown/2010/mediawiki/extensions/F2F/F2F_body.php
> for the SQL, which needs tweaking/customising. Please read the
> code before installing this in a live site, it is very much
> experimental work in progress. I won't list all limitations here; you
> can see from the code link that there is not a lot to this yet, beyond
> the raw idea. In particular it doesn't distinguish between the groups
> some account/openid is in, nor provide any information for consuming
> data.
>
> So anyway - the idea is that if we can get a few such installations
> running, they can syndicate useful/trusted openid lists back into the
> wider community.
>
> For example, the FOAF wiki already takes a feed of openids from my
> blog, so that commenters accepted as non-spammers in the blog are put
> into a group in the mediawiki. Since the FOAF wiki edit list is now
> locked down to known/trusted openids only, I am interested in finding
> ways of broadening that list without too much manual effort. I am sure
> other Wiki admins are in a similar situation.
>
> Research topic: how to avoid loops in the trust graph :) If
> wiki.foaf-project.org and (say) a Dublin Core wiki both produce and
> consume these lists, how to distinguish in the data which groups are
> populated based on external evidence, and which from first-hand
> knowledge?
>
> thanks for any thoughts,
>
> Dan
> _______________________________________________
> foaf-dev mailing list
> foaf-dev-RyYwo1q5J+qsOXdr9/[email protected]
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>

_______________________________________________
foaf-dev mailing list
foaf-dev-RyYwo1q5J+qsOXdr9/[email protected]
http://lists.foaf-project.org/mailman/listinfo/foaf-dev