-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forwarding interesting article:
http://sify.com/news/quality-of-wikipedia-entries-depends-on-authors-collab…
Quality of Wikipedia entries depends on authors' collaboration
2010-03-12 15:20:00
Last Updated: 2010-03-12 15:38:12
A new research by an Arizona University Professor of Indian origin has
found that the quality of entries in Wikipedia depends on how authors
collaborate.
Sudha Ram, a UA's Eller College of Management professor, co-authored
the article with Jun Liu, a graduate student in the management
information systems department (MIS). Their report bagged the "Best
Paper Award" at the Workshop on Information Technology and Systems
held in conjunction with the International Conference on Information
Systems, or ICIS.
Ram, a McClelland Professor of MIS in the Eller College, said: Most of
the existing research on Wikipedia is at the aggregate level, looking
at total number of edits for an article, for example, or how many
unique contributors participated in its creation.
"What was missing was an explanation for why some articles are of high
quality and others are not.
"We investigated the relationship between collaboration and data quality."
Wikipedia, the world's largest open-access online encyclopaedia, has
an internal quality rating system for entries, with featured articles
at the top, followed by A, B, and C-level entries. Ram and Liu
randomly compiled 400 articles at each quality level and used a data
provenance model they developed in an earlier paper.
Ram explained: "We used data mining techniques and identified various
patterns of collaboration based on the provenance or, more
specifically, who does what to Wikipedia articles.
"These collaboration patterns either help increase quality or are
detrimental to data quality."
Ram and Liu identified seven specific roles that Wikipedia
contributors play.
Starters, for instance, create sentences but seldom engage in other
actions. Content justifiers create sentences and justify them with
resources and links. Copy editors contribute primarily though
modifying existing sentences. Some users - the all-round contributors
- - perform many different functions.
Ram said: "We then clustered the articles based on these roles and
examined the collaboration patterns within each cluster to see what
kind of quality resulted.
"We found that all-round contributors dominated the best-quality
entries. In the entries with the lowest quality, starters and casual
contributors dominated."
She pointed out that to generate the best-quality entries people in
many different roles must collaborate.
Ram said: "A software tool could prompt contributors to justify their
insertions by adding links...and down the line, other software tools
could encourage specific role setting and collaboration patterns to
improve overall quality."
The impetus behind the report came from Ram's involvement in UA's 50
million dollar iPlant Collaborative, which is funded by the National
Science Foundation and aims to unite the international scientific
community around solving plant biology's "grand challenge" questions.
Ram's role is a faculty advisor and has to develop a
cyberinfrastructure to facilitate collaboration.
She said: "We initially suggested wikis for this, but we faced a lot
of resistance." Scientists raised concerns ranging from lack of
experience using the wikis to lack of incentive.
"We wondered how we could make people collaborate.
"So we looked at the English version of Wikipedia. There are more than
three million entries, and thousands of people contribute voluntarily
on a daily basis."
She added: "If we want scientists to be collaborative...we need to
assign them to specific roles and motivate them to police themselves
and justify their contributions." (ANI)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuaaRIACgkQyQg4JSymDYmZAQCgzdJMtBE6C6A7AHFHnMg2lrI5
1S8AoKSozwCxslP97qyDhSGXkxBaZl6W
=t4rQ
-----END PGP SIGNATURE-----
Hoi,
We have MANY individual images that will benefit from the Djatoka, more
importantly particularly mobile users will benefit a lot.
Almost all our pictures where we look at the full pictures and that are
bigger then the screen *will *benefit. When the screen is the same size as
the picture, the loading will give you much sooner an impression of the
picture, allowing you to abort the rest of the download.
So really truly and honestly the Indonesian story cloth is an extreme
example why we will benefit from Djatoka, it is easy to grasp why you NEED
it for this picture, all the other pictures are as deserving and, the
Djatoka approach provides a much better user experience.
Thanks,
GerardM
On 11 March 2010 12:02, Andrew Gray <andrew.gray(a)dunelm.org.uk> wrote:
> On 11 March 2010 09:58, Michael Peel <email(a)mikepeel.net> wrote:
>
> > I would love to see something like Zoomify/SlippyMap for all image on
> > Commons (or even direct on Wikipedia) as a way of zooming in on
> > detail rather than needing to download the whole image - presumably
> > that's essentially what Djatoka does?
>
> There's a good article on the implementation of Djakota here:
>
> http://www.dlib.org/dlib/september08/chute/09chute.html
>
> (I was very taken by it when I looked into it for a project at work a
> year or so back, but that sadly never got off the ground...)
>
> It seems that the main benefit of Djakota is that it's an elegant and
> open-source front end built upon JPEG 2000; it's this, the actual
> image format, which allows things like progressive loading from set
> coordinates within the image rather than downloading the entire file.
> You need the software to handle them, but you're not tied to a
> specific implementation.
>
> If we can generate these source files (there are vague worries about
> licensing, but to my untrained eye it seems okay) and store them
> without size issues then we'd have two options:
>
> * run a seperate system for viewing very large files, which we hand
> the user off to, perhaps in a popup window; run this on Djakota or
> something very like it, hosted locally, and make it seem as seamless
> as possible
>
> * integrate the "image browser" into MediaWiki itself, like we
> integrate the existing media players.
>
> Technically, I have no idea which of those would be more desireable or
> less headachey - anyone?
>
> I do agree entirely that something like this is quite desirable; even
> if we don't have many individual items requiring this sort of
> capability now, build it and they will come...
>
> --
> - Andrew Gray
> andrew.gray(a)dunelm.org.uk
>
> _______________________________________________
> Commons-l mailing list
> Commons-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/commons-l
>
Hoi,
Last week Thursday there was no localisation for the Malayalam wikipedi, it
did not have a mobile main page.. Today it is the first language of India
that has the best support we can offer to mobile telephones. According to
many, the mobile phone will generate much of our future traffic..
I hope and expect that India will amaze us and grow a vibrant and rich
community for all its languages.
Thanks,
GerardM
http://ml.m.wikipedia.org
Folks,
Some tangible (for me) results from the offline taskforce discussions on
strategy at the end of last year.
Thanks especially to Emmanuel Engelhart of kiwix.
http://blog.wizzy.com/
Cheers, Andy!