[Commons-l] [Fwd: Pikiwiki - Israel free image collection project - Starting engines]

Tue Jan 13 19:08:54 UTC 2009

Sorry, I hit the wrong button at the wrong time. Here goes again:

> The basic idea (as
> described in details on the Meta) is to call upon the Israeli public to
> look in their family albums and private collections for pictures of
> Israeli-related pictures of special historical, anthropological,
> archeological, geographical, zoological and/or botanical value.
I am unsure whether it is a good idea to explicitly ask people to
upload stuff from their image collections. Those are often by several
different authors, which are now hard to identify. Thus we might get
licensing problems with these images, as people will upload images
from their collections they have, but don't know the author and will
give out a license anyway.

> We would like the localized site to serve not
> only as an upload site but also as an attraction to pupils, students,
> teacher and the general public, where they can look for images using
> Hebrew interface
Actually I don't understand why we need to have a Commons clone in
Hebrew. Wouldn't it be better if you contributed to the Hebrew
localisation of the MediaWiki interface and the templates on Commons?

> The localized site saves the images temporarily and eventually sends
> them to the Commons.
This actually sounds like a very bad idea. Transferring images should
IMHO not be done automatically without human control. After all, your
site is kind of like Flickr. We don't import from there automatically,
we wait for users to ask for the import of an image. That way we have
a sanity check which images are transferred and which are not. There
are cases, where the photographer has given out a free license, but
other people also hold rights to the image. Those cannot be used on
Commons. Also an automatic transfer would allow people to bring in
images without checking them. Your upload bot will surely get a bot
flag and will thus not be checked by RecentChanges people or bots.
This gives vandals a great way to upload images without having an
account on Commons or even being blocked there.

> 1. Users will name the images and describe them in Hebrew. We will add
> the prefix "Pikiwiki" to the name, and probably an ID which will enable
> us to locate the image in our own catalog. So a typical name might look
> something like "pikiwiki_123456_ציפורים_נודדות_מעל_מכתש_רמון.jpg". If
> friendlier names are required, we will have to think of a better idea.
Please remember, that Commons is a multi-lingual project. It would be
great if you could choose to upload the files with English file names.
Otherwise, I am afraid nobody will be able to make good use of them.
Only very few people actually speak Hebrew and those who don't find
themselves unable to even type the file name of the image. That is why
I'd really prefer to see file names with a latin charset. Adding
English descriptions also helps other people to understand what the
image actually shows and to sort the image into categories (I presume
the bot will be unable to do this, right?).

> 2. As mentioned above, we would like to present the images on the
> localized site too, according to localized categories. Therefore, we
> would like to attach an ID to each image, so we could trace it easily on
> the Commons. Currently, adding this ID to the image name seems the
> easiest option.
As stated above, I don't think we should have a Commons clone site. I
also don't understand why you need to put IDs in the image file names.
You store the file name in your database anyway, so why do you still
need the images to have an ID?

> 3. Updating images changed since last synchronization.
This sounds to me an at least as bad idea as the one that images are
automatically uploaded by bot. By automatically implementing changes
on your site to the Commons, you let people take control of your bot
and thus leave RecentChanges people on Commons unable to verify who
actually made the edit. Also, I don't think that this behaviour is
GFDL-compliant.

> 4. Removal of requests for removed images, which were uploaded to
> WikiMedia.
I don't understand. Does this feature remove images from your site
which were deleted on Commons? Or does it try to remove images from
Commons which were removed on your site?

> 1. Uploading - WikiMedia Commons does not have an API or other
> completely supported interface, to allow any operations in their system,
> without manual intervention.
Yes, it does. Check http://www.mediawiki.org/wiki/API for more info on
the MediaWiki API.

> 3. Removal of images - as WikiMedia Commons is a system designed for
> common information sharing, it does not support direct image removal,
> let alone image removal via external system. This synchronization
> component simulates fake JS requests and image information updates to
> notify WikiMedia Commons system regarding the fast image removal demand.
I don't understand what this actually does. Do you make the bot open
deletion requests? Do you make it tag the images for speedy deletion?

Regards,

ChrisiPK

2009/1/13 Cary Bass <cary at wikimedia.org>:
> Hi, Dror asked me to forward this message on.
>
> -------- Original Message --------
>
> Hi,
>
> I sent this message to commons-l, but it is being halted because I
> didn't subscribe. Could you please forward it, or release the original
> message?
>
> Thanks,
>
> Dror
>
>
> Pikiwiki - Israel free image collection project
>
> Starting engines
>
> Hello,
>
> The Israel free image collection project is about to take off
> (http://meta.wikimedia.org/wiki/Picwik). We are currently testing the
> system, a process which could take a while, because we've already found
> some bugs and unfriendly features, to be repaired as soon as possible.
> However, we started to upload images as part of the testing phase, so I
> think it is time to inform the Commons' community about the project.
>
> This is a joint project of Wikimedia Israel (wm-il,
> http://www.wikimedia.org.il) The Israel Internet Association (ISOC-IL)
> and the Center for Educational Technology (CET). The basic idea (as
> described in details on the Meta) is to call upon the Israeli public to
> look in their family albums and private collections for pictures of
> Israeli-related pictures of special historical, anthropological,
> archeological, geographical, zoological and/or botanical value. These
> pictures should be in good quality and depict historical events,
> landscapes, archeological findings, cultural events, animals and plants
> as long as they are related to the State of Israel or to the
> geographical region commonly known as Palestine or Eretz Yisrael (we are
> going to be flexible about these definitions). For this end, we created
> a localized site in Hebrew (*http://www.pikiwiki.org.il*
> <http://www.pikiwiki.org.il/>). Anyone who is willing to contribute his
> images can open an account there and declare that the pictures are his
> own and that he is willing to release them either to the public domain
> or under cc-by-2.5 license (i.e. with attribution). We also initiate
> calls to local archives and collectors. Some of them have already sent
> us interesting images, which we will upload to the Commons soon. Images
> donated through this localized site will be accessible through the site
> itself or the Commons. We would like the localized site to serve not
> only as an upload site but also as an attraction to pupils, students,
> teacher and the general public, where they can look for images using
> Hebrew interface. This means that the interfaces between the localized
> site and the Commons is quite complicated and delicate.
>
> The localized site saves the images temporarily and eventually sends
> them to the Commons. We have two main problems to overcome:
> 1. Users will name the images and describe them in Hebrew. We will add
> the prefix "Pikiwiki" to the name, and probably an ID which will enable
> us to locate the image in our own catalog. So a typical name might look
> something like "pikiwiki_123456_ציפורים_נודדות_מעל_מכתש_רמון.jpg". If
> friendlier names are required, we will have to think of a better idea.
> 2. As mentioned above, we would like to present the images on the
> localized site too, according to localized categories. Therefore, we
> would like to attach an ID to each image, so we could trace it easily on
> the Commons. Currently, adding this ID to the image name seems the
> easiest option.
>
> Here are some technical details about the way the upload process is
> handled as provided by our programmer:
>
> A synchronization component handles all data synchronization with
> WikiMedia Commons. It simulates user behavior and data posting via CURL.
> The component rechecks the data of the images needed to handle, to
> prevent un-needed execution
> This operation has several steps:
> 1. Login into WikiMedia Commons
> 2. Uploading new images - the data is processed and posted with
> appropriate tags and licensing.
> 3. Updating images changed since last synchronization.
> 4. Removal of requests for removed images, which were uploaded to
> WikiMedia. A removed image is flagged in a watch list to allow future
> tracking and verification of successful removal. Access to the component
> is secured via hard-coded token, to prevent unwanted execution.
> A Visual debugging function exists in the code, to allow fast problems
> tracing Each synchronization step is rechecked based on existing data,
> pulled from the output of WikiMedia, to attempt to verify successful
> operations and marking of un-successful operations
> 1. Uploading - WikiMedia Commons does not have an API or other
> completely supported interface, to allow any operations in their system,
> without manual intervention. (The perl script originally provided by one
> of their users also attempts to utilize existing forms on the site).
> This component simulates user behavior and heavily depends on existing
> WikiMedia state - once WikiMedia decide to change or block some of the
> current screens in their system, the code might need to be updated or
> modified accordingly.
> 2. Updating or editing existing user images on WikiMedia is not support
> or publicized on their site. The component uses user simulation and
> fetches WikiMedia security token to allow this behaviour. (The token is
> originally there to prevent such operations.) Once WikiMedia create
> other or additional security precautions, this operation will require
> code modification and might become impossible.
> 3. Removal of images - as WikiMedia Commons is a system designed for
> common information sharing, it does not support direct image removal,
> let alone image removal via external system. This synchronization
> component simulates fake JS requests and image information updates to
> notify WikiMedia Commons system regarding the fast image removal demand.
> Currently this allows quick (although not on the spot) removal. If
> WikiMedia change their system or implement further security precautions,
> this operation will require code modification and might become impossible.
> * The component uses hard-coded credentials for WikiMedia Commons,
> required to use their system and all the operations in their system are
> done in the name of the provided user
> * All the images are uploaded one by one to prevent the user from
> potentially getting blocked by WikiMedia Commons
>
> Thank you very much,
>
> Dror Kamir,
>
> Wikimedia Israel
>
>
> _______________________________________________
> Commons-l mailing list
> Commons-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/commons-l
>