[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Quran certification: community project
- To: Arabeyes developer mailing list <developer at arabeyes dot org>
- Subject: Quran certification: community project
- From: Riyad Preukschas <rpreukschas at web dot de>
- Date: Wed, 25 Feb 2004 17:44:23 +0100
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Assalamu Alaikum,
This is my idea for a quran certification community project. I chose the
idea of an community project in order to be independent from
institutions and organisations and also give them a chance to participate.
So here is my idea:
0. Word explanations:
Project: this means a project for providing the quran (not the quran
certification community project itself)
data: this means any piece of information that can be included in the
Quran (e.g. meta data, ayats, sura names/translations, etc.)
1. Project creation
1.1. Everybody on this globe (having an internet connection, and being
registered in this project) should be able to create a new Quran project
on the project's website or with an application supporting the not yet
specified "Quran-editor" protocol.
1.2. On project creation there has to be given initial information on
the source you want to provide (e.g. Quran style/translator, language,
book/CD cover image, detailed information about the source book or the
already digitalized source (copyrights, original publisher's
permissions, etc.):
1.2.1. to prevent two projects trying to provide the same source and
make the people join the already created project to speed up implementation
1.2.2. to be able to check correctness of permissions and copyrights
etc. at the beginning of the project.
2. Committing data
After creating a project it can be worked on by an infinite number of
people (at most 1 editor per data + people to prove
correctness(validators)). Anyone registered to this project can commit
data.
2.1. All data that has not been included at the point of commitment is
accepted.
2.2. Committing already existing data
2.2.1. Update commit
This updates the previous data. This can only be done by the original
committer.
2.2.2. Replacement commit
This replaces the previous data. This can be done by anyone registered
to the project with a "replacement request" to the committer of the
original data or the project admins.
2.2.3. Prallel commit
A parallel commit gives the possibillity to the community or the project
admins to choose/vote which of the commits to include in the final release.
3. Validation:
3.1. Incomplete information cannot be validated. You can only send a bug
report to the committer (this can include reports of spelling mistakes,
mix-up mistakes, etc.)
3.2. As soon as a piece of data is complete it can be validated by
community members (which do not have to be registered to that project)
by sending a "validation request" (VR) (hash of the ayat text to be
validated + community member identifier (e.g. pgp-key, private hash, etc.).
3.2.1. Data validation
Data is considered valid when there are at least 15 positive (and
no negative) VR on this data.
3.2.2. Negative validation requests (-VR)
3.2.2.1. Informing people about a -VR
As soon a -VR arrives the author of the data and all people that have
declared the data valid are informed.
3.2.2.2. Withdraw VRs
You can withdraw VRs within 24h after sending it to make it possible to
correct a mistake, maybe if you mixed up ayat numbers or selected the
wrong button or things like that.
3.2.2.3. Revalidating data
If at least 5 people that have not validated this data yet send +VRs the
-VR is nullified.
3.2.2.4. Validation nullification
Validation is nullified immediately after a second -VR arrives. If the
file has already been released the hash (of the file) is removed from
the white list.
3.3. White list
All files that have been validated completely are added to a white list
which applications based on that data can use to check whether they are
operation on valid sources.
4. Validation statistics
To prevent bogus validations there should be statistics on everyone who
has ever validated a Quran file.
4.1. Mistake rate
<the total number of VR of a person>/(<withdrawn VRs> + <deleted or
revalidated -VRs>)
4.2. Correctness rate
<the total number of VR of a person>/<all VRs where there has not yet
been send a -VR>
4.3. Accuracy
<correctness rate>/<mistake rate>
These are a few ideas I collected over the last few days.
Please, comment on them. Tell your idea of what to add or change to
improve this idea or give proposals how Quran validation should work.
Salam,
Riyad Preukschas