Hello,

I like the idea but this sound very very bad:

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

How can we check if the images are really there own and license under de license as stated.

This is a great way to place copyvios on Commons.

And a other problem, the images are not uploaded under the license he says. The are placed under the gfdl and cc-by-3.0 license See ya,

Huib v Neerbos

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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l