Improve file description

[SJu-w]

Summary:

Files uploaded to Commons by the app have a name of the photographed subject just in the filename, but not in the file description ("description" field of the "Information" template). The description field contains just the label of the value of the P31 (instance of) property, which is usually a vague general term. The description also does not contain the wikidata identifier of the item which the photo should belong to.

Example:

See https://commons.wikimedia.org/w/index.php?title=File:Souso%C5%A1%C3%AD_svat%C3%BDch_j%C3%A1hn%C5%AF_Ji%C5%99%C3%ADho_a_Agapita_u_cesty_ke_kostelu_sv._Petra_a_Pavla_v_Mimoni.jpg&oldid=521598789 file title and original file description. The description should be {{cs|1=Sousoší svatých jáhnů Jiřího a Agapita u cesty ke kostelu sv. Petra a Pavla v Mimoni}} but it is {{cs|1=socha}} (= statue) instead. The Q code of the Wikidata item is quite missing.

Steps to reproduce:

This pattern can be reproduced by uploading whatever new image based on certain Wikidata item found in the map. The problem is probably not depending on the used device or system.

Commons app version: 2.13.2~757c7b008 in the example output.

Solutions:

Edit the template which generates the description of photos saved to Commons by the application:

• "description" field of the "Information" template should be filled with the label of the photographed subject, not with the label of the value of its P31 (instance of) property
• a link to the Wikidata item (including its ID) should be added to the file description (ideally using any template which is able to internationalize the description)
• (btw., "cosmetical" correction - parameters of the {{Information}} template should be ordered in the standard and logical way (description, date, source, author, permission). Currently, the date is located as the last parameter.)

I suppose, the correction should be simple and banal and does not require much programming knowledge, only access to the template that generates the file description output. I wonder why such an unnecessary mistake occurred at all.

[misaochan]

Pinging @nicolas-raoul @VojtechDostal for input.

[nicolas-raoul]

Thanks for the feedback!

I am open to any description template that makes the picture more useful :-) I think that duplicating information should generally be avoided (in order to not waste contributors' time), but if there is a Commons policy that recommends duplication then I am happy to conform to it.

I agree with you that the QID being only in the File usage on other wikis is not enough. And here is some good news: recent versions of the app (for instance the alpha) add the QID to "depicts" in the Structured Data tab (example). Now the question is: should we duplicate the information from Structured Data into the description? At first sight it does not sound to me like a great idea: someone who edits Structured Data would have to then also edit the description to avoid discrepancies. I would not be against adding to the description something like {{include depicted QIDs labels}} if there is such a template.

I agree that P31 labels are not always super useful, but it can be helpful for people using text-based search (as opposed to structured search) on Commons. Ideally we should use not P31 (example: "statue) but rather the Wikidata item's description (example: "baroque statue in Mimoň, Czech Republic") when there is one.

Many items do not yet have a description, but the smart people at Wikidata are doing their best to fill great descriptions in as many languages as possible. For the items that still do not have a description, we can fall back to using the item's P31(s) and possibly P131/P17.

Thanks for pointing out the parameters order problem! Would you mind creating a different issue for it? Please include an example of what the app currently generates, and what it should generate instead (same content with the right order). Thanks!

[SJu-w]

Hi, thanks for your reaction.

• Description is the main and basic way of description files at Commons. If there something is "duplicating", then the "structured data", rather than the standard description. In any case, the absence and loss of information is undoubtedly a much bigger mistake than possible duplication. I assume that when the name / description of the object is automatically copied (by the app) to the description file page, then no work will be added to the contributor, and on the contrary we will save the work of those who would have to look for what is shown in the picture. I was very surprised that for several months the application worked with such a fatal and obvious shortcoming and flooded the Commons with many photographs with unusable insufficient descriptions. It was often necessary to stalk the uploader and his edit history in order to deduce what is in the picture. Other people have to work hard to do what the application neglected. (Btw., more sophisticated algorithms could be used for categorization.)
• As we can see on the example photo linked above, the subject (Wikidata item) was not linked from the Structured Data either. If the new version fixed this shortcoming, it is a small step forward. Late but still. Thank you.
• "File usage on other wikis" is usable only when the photo is used in other wikis. As soon as the photo is replaced by another photo in another project (or before it is used), this information becomes lost from the original photo (and isn't traced in the page history, as well as the "structured data"). Mistaken or unfitting usage on other wikis is undetectable and unverifiable if the description is quite missing on the image page. "File usage list" can be easily misinterpreted, if we do not check in what context and with what comment the file is used. It is true that this information often helps with investigation, but the standard workflow is the opposite - first to determine and describe what is in the photo, and then to consider whether and where to use the photo.
• Structured data can be a good idea if it is finalized and could fully replace the previous method of description and the whole file pages with all their features. In their current form, however, they only bring more chaos and duplication to the Commons. In fact, the description is often scattered into up to five or six different locations (the file name, the description field of the information template, description at the file page outside the information template, structured data label, structured data P180 property, labels/descriptions in other projects etc.). Instead of simplification and unification, there is more and more chaos.
• One of the main problem with structured data is that they are completely unmaintainable. The P180 property (depicts) in structured data of files is massively misused for unstructured tagging with general "keywords" or "hashtags" (as it is common in non-wiki photo webs and social networks). Also general categories are abused in this way, but this can be solved by permanent sorting or removing content from that categories. However, "structured data" are unstructured and cannot be effectively maintained. This problem is not the subject of this issue, but we must take this situation as a fact.
• Each Wikidata item should always have a corresponding label in at least one language (accompanied, when necessary, by an additional description). If there is any Wikidata item with no label, then it is a fatal Wikidata bug. Of course, an additional description is not necessary where the label itself is already fully exact and concise. It is true that especially automatically imported items often have descriptions illogical and inaccurate, untouched by intelligence. However, the standard is that the label, together with the additional description, should represent an unambiguous, concise identification of the subject, which selects the essential from all possible properties. That is exactly what must not be missing in the description of the picture.
• The Commons description should be more complex than only a link to the item of the depicted subject, but the identification of the item needs to be the core of the description. Verbal expression of the context or view of the subject is usually more effective than if we tried to code all these aspects in a completely structured way (which is not developed yet).
• It is true that it is not prudent to replicate unreliable information from Wikidata too much, because once the data is corrected in Wikidata, it would be difficult to find and fix all its replications. This applies, for example, to the coordinates of the object. On the other hand, it is advisable to catch some data at the time the photo was taken, so that additional changes do not lead to anarchronisms in the description (for example, if the building or place become later renamed or its properties changed). Also some interwiki conflicts and their solutions can confuse all pages and "structured data" where the item has been linked in the past.
• as regards parameters of the {{Information}} template, the standard and logical order is "description, date, source, author, permission". In the current app output, the date is located as the last parameter. It's clear enough. The date belongs closely to the description of the photo, while source, author and permission are usually rather legal and technical "meta-infos" only. No need to speculate and discuss again, just follow the standard order from the template output and documentation. It's a very simple correction.

I thought it would be a perfectly simple fix for the obvious error. I would not have imagined how much text we will have to write because of this. :-)

[VojtechDostal]

I am not sure that this long explanation was needed. It sort of diverges into discussions which should be held on Wikimedia Commons and not here.

I am in favor of using the item description as the default description for the image. If this is not available, we can always fall back to P31. (Alternatively, we can fall back to a more clever data-based description formed using a more complex algorithm using several properties. Eg. "city in Portugal". This would require more programming but tools such as Mix'n'Match and Duplicity are able to do that quite well already.)

I wouldn't include information about depicted items into the description - it's already in the structured data, which is the preferred way of doing this on Wikimedia Commons. If the community decides they want to include this information in {{information}} too, they can do it for all the hosted images in bulk, with a bot.

As for categories, I think #3595 would be very helpful.

[SJu-w]

The commonly established standard of Commons is that the description provides "brief (if possible) but complete information about the image", including indentification of notable subjects or objects, location, relevant circumstances and all information to support all item categories of the file. Normally, the description contains more complex and complete information than the file name itself. Now, the application violates this principle flagrantly, and needlessly.

No need to open or question these proven and consensual principles of Commons here. Here we solve a problem with an application that violates these principles and floods Commons with lot of photos with insufficient, nonsense and worthless descriptions. If someone at Commons makes attempts to partially duplicate information by the "structured data", there is no reason to break and ignore the current basic system, which is far from being and cannot be fully replaced by that structured data. So far, structured data (similarly as so-called "annotations") can only encode and highlight part of the information from the description in a very partial and imperfect way, and currently they are also contamined with a lot of ballast and are not effectively maintainable nor usable, and even not directly visible from the main page of files, and not integrated to it, and not really structured. For now, the P180 (depicts) values of Structured Data are some hashtags, some quasi-categories which don't really work like categories (we put the content somewhere, but we don't easily see what's put there) and are not really structured and maintainable like categories. For our issue, however, it is essential that so-called "structured data" does not replace and will not be able to replace a proper description of the file for a long time. Robotic bulk re-import of P180 values from structured data into a description carries the risk that the description will be devalued by a lot of ballast, because structured data are massively misused for purposes for which they were probably not intended.

The property P31 cannot have a greater informational value than the actual and specific description of what is in the picture and cannot to substitute it. In addition, we already have experience that P31 value often links to locally and culturally conditioned general terms, which are very prone to inaccuracy, unsharpness and interwiki conflicts and fundamentally complicate their resolution. Generally, the case that the item has absolutely no label should be inadmissible in Wikidata. If such a completely extraordinary and undesirable case occurs, then perhaps it is better to use only the Q code as a title and description than to try to compile an alternative description from P31 and other properties. In general, suppose that a Wikidata label, along with the appropriate description, should unequivocally define the topic, including its most essential attributes. When it's not so, it is a problem of Wikidata content and filters, not defect of the app.

It is true that a link to a specific Wikidata item or items (in whatever form) should also be part of the description, and for the future, it can be used by an intelligent template to mediate and internationalize the description. The {{Q}} template exists already, and for the future it can be improved, e.g. gramatized. Template {{Wikidata Infobox}} generates a more complex output. For the file description, there would fit something between the two mentioned, for the dominant item of the image. Improving and creating such templates is a task for the Commons.

The application that creates the file page should ensure that the link to the Wikidata item is in a usable form, taking into account possible future uses, the possible context (more items affected etc.) and possibility to extend and modify the description.

[nicolas-raoul]

Here is the algorithm I would recommend for pictures that represent a Wikidata item:

• If the Wikidata item has a description in my language → Pre-fill the picture's description using the Wikidata item's description (example: チェコ・ミモンにあるバロック像 or baroque statue in Mimoň, Czech Republic)
• If the Wikidata item does not have a description in my language → Pre-fill the picture's description using the P31 (instance of) of the Wikidata item in my language (example: 像 or statue)

If anyone does not agree, please post your exact recommended algorithm, including at least these two cases. Thanks!

[SJu-w]

• When the application is now able to select a somehow meaningful file name, then I do not understand why it is such a problem to insert at least an equally meaningful and valuable description into the description field. This is the basis and the minimum - of course, provided that the description can and should be further improved and enhanced, while the file name usually remains unchanged.
• Label + description are pairs of data that belong together and together should define the subject of the item. If the label is concise and specific enough, then the "description" field may be blank (or is redundant and can be blanked). The Wikidata "description" field alone without the "label" does not make sense. When we talk about "description" in Commons, we have to mean the whole pair "label+description" from Wikidata. If only a description field without a label is given in any language, it is usually a generic statement which should be ignored because it is often misleading and never sufficient.
• The language of the uploader should be irrelevant. Suppose that geographically localizable objects usually have a description primarily in the local language(s). The local language(s) should be preferred. English language and the language of the uploader (if he is a foreigner) can be considered as other languages. If the algorithm does not find a label in the preferred language, then it should use the label in any other language, or in all languages in which it exists. However, if we use any template like {{Q}} for the description, then the application output is language neutral (universal) and the language selection is handled by that Commons template (but such a description is then problematic for fulltext search).
• If the Wikidata item has no label+description in all languages, then it can be rather suspected that it is a defective / empty / abandoned / invalid Wikidata item. Then there is a question of why the photographer assigned the photograph to such an item, if he did not know what to photograph and what is the subject of the item. If such a non-standard case nevertheless occurred, then the subject would still have to be identified by its Q code, not by any properties like the P31.
• P31 is usually worthless for object identification. Item description (=label+description) should concisely and unambiguously identify the object including its nature/type. As a rule, P31 does not add any information that would not be obvious from the description. However, P31 can be useful for finding suitable categories if the Wikidata item does not have its own Commons category.
• Rather, it might make sense to add data on the geographical / administrative affiliation of a place (locality, municipality, region, country) as an appendix attached after the description itself, similar to how the Commons template {{Wikidata Infobox}} generates (displays) it. However, it would be better for the Commons template to look for this data rather than the uploading application. The app should employ localization properties P131, P276, P706 etc. also for finding suitable localizing categories. For the future, the categorization algorithm should be able to combine P31 values with localization properties, but this is already a sophisticated task that must be supported by Wikidata as well (probably various categorization scripts already exist and work there). (Another problem is that some of Wikidata fans tend to ignore or sabotage the categorization system and consider it obsolete, although Wikidata do not yet have tools to fully replace it. But in a conceptual view of the distant future, their view may be relevant.)

If someone still does not understand that "label + description" identify the subject of an item, while P31 cannot in principle identify the subject of an item and of its photo, then I am afraid that no other "exact recommended algorithm" or examples can help with it. I pointed out an obvious mistake that lasted here for several months, and instead of someone fixing it immediately in two minutes, we will get bogged down in endless useless discussions here. There is no need to invent anything. If the application can now usually create a meaningful file name, it can create the basis of the description in exactly the same way.

[SJu-w]

Btw, I think it's obvious that "baroque statue in Mimoň, Czech Republic" doesn't identify the subject of the photo, while "Sousoší svatých jáhnů Jiřího a Agapita u cesty ke kostelu sv. Petra a Pavla v Mimoni" is quite specific aned even is there no need to add anything to it.

[VojtechDostal]

Too long - didn't read, but I think @SJu-w might be proposing to use Wikidata item's label in the description field of the {{information}} template. I didn't think about that before and it might be nice to include it in the description too... However, sometimes the Wikidata label isn't very informative for discerning several unnamed objects - eg. https://www.wikidata.org/wiki/Q103822064 - label is literally just "bridge". That's why I rather support @nicolas-raoul's suggestion to use the Wikidata item's description for description of the image. Anyways, the Wikidata item's label is already in the filename.

[SJu-w]

Didn't read this text, didn't read also the file pages from the last months? Try to read at least the first two paragraphs so that we don't spin in a circle. You are trying unnecessarily to invent for what is already described above, and obvious even before this discussion.

Is it really so hard to understand that the "description" on a file page has to identify what's in the image? It's really so hard to understand that on Wikidata, "label + description" together identify the subject of an item, while P31 alone or the second part of the pair cannot identify the item? Didn't nobody of you find it faulty in the past few months, what meaningless descriptions did the application generate?

Have you been confused by the fact that on Wikidata the name "description" bears a field which is in fact only a supplement to the real description core, which is named "label"? And are you unable to recognize and correct this mistake with common sense?

Of course - if in some cases there is a wrong or meaningless label + description in Wikidata, this application cannot solve it (poor labels on Wikidata are mainly a problem with incorrectly set up bulk imports, or their sources). The point is that this application does not produce meaningles descriptions needlessly.

[nicolas-raoul]

I am sure Vojtěch was joking, I for one read all of your comments with attention, even if some parts (like the part about "hashtags" which is not on topic here) might sound more like a rant. Please be assured that your point of view is considered and respected. You have already convinced us that using only P31 (which is what the app currently does) is not good enough.

Yesterday I asked you to post your exact recommended algorithm, but it seems that you did not post it. So here I will try to sum up your algorithm:

• If the Wikidata item has a description in my language → Pre-fill the picture's description using the Wikidata item's label+description (example: sculpture of the Holy Deacons of George and Agapit on the way to the Church of St. Peter and Paul in Mimoň (baroque statue in Mimoň, Czech Republic))
• If the Wikidata item does not have a description in my language → Pre-fill the picture's description using the label+description in another language (example: ミモンのペターとポール教会の道の途中のジョージとアガピットの像 (チェコ・ミモンにあるバロック像))

Does it sum up your algorithm correctly? If not, please correct it, thanks!

Here are my thoughts about that algorithm:

1. I am not a fan of duplicating information from filename to description, but if that's what the community strongly want, then I am OK with it.
2. The user most likely does not understand this other language, so they can not judge whether it really applies or whether it is actually erroneous, or should be edited. Subsequent readers of the description will think that the person who took thee photograph actually wrote this, giving to the text undue credibility. I am sure that if we implement that, many Commons users will come here to complain that it is the worst bug ever.

[SJu-w]

Hi nicolas-raoul. This time, perhaps we understood each other in the basics. This step can be solved almost immediately so that the file description has at least as informative value as the file name. So I will add just a few clarifications or improvements:

• if the label is empty in a given language, consider this language as if there is no description in it, even if the additional "description" is filled. If there is a label and there is no additional description, then assume that the label itself is sufficient.
• if the fist letter of the label is lower-case, it should be converted to upper-case for this output
• The description of the object should also be equipped with a link to the Wikidata item, because the description itself is often ambiguous, and because there may be also other objects, events etc. in the image. (example: Sculpture of saint deacons George and Agapitus on the way to the Church of St. Peter and Paul in Mimoň (baroque statue in Mimoň, Czech Republic, [[Wikidata:Q80438306|]]).)
• The question is whether to choose another language at random or according to some order of preference. But I assume that the vast majority of bulk imports in Wikidata are based on only one language, the language of the source database, which is usually the official language of the affected country (or English in case of international sources). In Commons, however, I would consider at least bilingual descriptions as standard (local language + English).

There is also the possibility that the verbal description (label+description+P131 administrative division chain) would only be displayed through a template containing Q code, similarly as in {{Wikidata Infobox}}. However, such an internationalization template can IMHO cause problems for full-text searching, and the text cannot be simply adapted and enhanced by the uploader. I would rather leave this solution for the further development of structured data interface, and I would not bring it into the classic old form of description.

And what about file names? The relationship between the file name and the description presupposes a certain degree of duplication, because both have to express what is in the picture. But usually the file name is required to be as short as possible, while the description should be as accurate and unambiguous and complex as possible. It is true that automatic pre-filling cannot take advantage of this difference as sensitively as an experienced contributor. In general, we can solve this by inserting only the label into the file name by default, while the label + description into the description. But from automatic imports, we have many cases where the label is not specific enough, e.g. "wayside cross" for any specific wayside cross. This problem can not be solved by the application, Wikidata maintainers must solve the problem primarily. But the application can alleviate the problem in some cases.

As an example, for Q80456207, the file name consisting from the pure label Pamětní kříž is obviously too unspecific. There are several options that can be considered:

1. to use the same pattern as for the description, ie label + description (example for Q80456207: Pamětní kříž (pamětní kříž v obci Budeč, okres Jindřichův Hradec).jpg)
2. to add a Q code to the end of the file name, e.g. label + Q (example for Q80456207: Pamětní kříž (Q80456207).jpg)
3. to add P131 at the top of the file name, e.g. P131 + label (example for Q80456207: Budeč, Pamětní kříž.jpg)
4. some combination of the previous forms. (1+2+3-combination example for Q80456207: Budeč, Pamětní kříž (pamětní kříž v obci Budeč, okres Jindřichův Hradec, Q80456207).jpg)

However, in a combination of text fields there is always a risk of duplication or multiplication of the same name and disproportionately long file name (1+2+3-combination example for Q72850340: Morávka, Kříž v údolí potoka Mražok v Morávce (pamětní kříž v obci Morávka, okres Frýdek-Místek, Q72850340).jpg; deterrent example for Q2242554: Mělník, Mělník (zámek v Mělníku, Q2242554).jpg).

Unfortunately, the way Wikidata items are described is very varied, so a different combination may be fitting for each item. Option 2 would probably seem least problematic to me in this situation. But the Q code is intended to be hidden - it is not intended to be visible and to be read and remembered by people. So it may be best to leave the status quo for now. Wikidata maintainers face the great task of unifying and establishing standards for the use of labels and descriptions.

[misaochan]

If the Wikidata item has a description in my language → Pre-fill the picture's description using the Wikidata item's label+description (example: sculpture of the Holy Deacons of George and Agapit on the way to the Church of St. Peter and Paul in Mimoň (baroque statue in Mimoň, Czech Republic))

This description makes sense to me personally. I am also OK with switching to this if the community supports it.

If the Wikidata item does not have a description in my language → Pre-fill the picture's description using the label+description in another language (example: ミモンのペターとポール教会の道の途中のジョージとアガピットの像 (チェコ・ミモンにあるバロック像)) The user most likely does not understand this other language, so they can not judge whether it really applies or whether it is actually erroneous, or should be edited. Subsequent readers of the description will think that the person who took thee photograph actually wrote this, giving to the text undue credibility. I am sure that if we implement that, many Commons users will come here to complain that it is the worst bug ever.

I agree with this, the description should not be pre-filled with something that the user cannot understand. If pre-filling with instanceOf is not an acceptable way of handling it, then perhaps we can just not pre-fill at all, and the user can insert their own description, same as they would with most other methods of uploading to Commons?

[SJu-w]

@misaochan: The main and basic purpose of image description is to identify what is in the image. This is what some people did not understand, and that is why this issue arose at all. If there is a tool designed to upload a photo of a particular subject, then by default such a tool pre-fills a unique identification of that subject. This practice has been widely applied and has proved its worth, especially for uploading hundreds of thousands of images within the Wiki Loves Monuments project, and for other campaings based on that technologies. It is highly desirable in all similar cases when the upload is based on a placeholder or upload link of a specific article, list item or map object of a specific subject.

• The first reason is that many users of such applications or participants of various contests and campaings are not experienced Commons users and many do not know how Commons works and do not understand that if an unambiguous object specification is missing in the description, it is often very difficult to subsequently determine what is in the picture. Unfortunately, tools designed to facilitate contributions often also separate contributors from the actual structure and maintenance of the project and make it difficult for them to penetrate its community and workflow.
• The second reason is that the application should make the user's work as easy as possible. If he had to manually rewrite what he photographed in the description for each photo, his work on the upload process would become several times more laborious, completely unnecessarily if he had already selected the object with one click on the map. Therefore, it is advisable for the script to do the main and basic work for him. In the case of a representative overall photograph of a simple subject, such an automatic description is usually fully sufficient. It is just for such photographs that such upload links are primarily intended.

However, what is still causing us problems is how to clearly and instructively indicate to uploaders that it is very desirable to expand and supplement this default automatic description as needed. So that the uploader is not afraid to edit or modify the pre-filled text. That's why it is advisable that the pre-filled text is editable, not only automatically displayed from Wikidata. Another problem is that the disorganized development of the user interface (UploadWizard, Structured Data etc.) causes the description to be scattered chaotically to several different places. Some also do not understand that the "description" field at the file page should not be just a secondary addition to the file name, but on the contrary, the file name and the structured data label should be a short summary of the most essential from the description, and the description should be as complex and exhaustive as possible. However, if I contributed to the project using an application, it would be practical for me to quickly upload the file with only a simple automatic description, and later create a more precise description comfortably from the desktop, if needed.

It should also be noted that at least bilingual descriptions are a desirable standard at Commons, although contributors who speak only one language are also welcome. Here wee need to find a compromise so that the application supports the possibility of multilingual descriptions, but so that the user is not forced to edit or approve a description that he does not understand. However, we should assume that if the contributor correctly selected which object he photographed, then the labels+descriptions automatically taken from Wikidata should be correct even in languages that the uploader does not understand. We only have to reckon with the fact that in these languages he will not be able to specify or extend the description beyond this basic description. The description in the main (local) language should never be omitted altogether, even if the photo is uploaded by a foreigner who does not speak the local language. Further work on sorting the file and refiniement of the description will usually be done mainly by local editors. And English is desirable as the main international language of the whole community. The uploader must provide in at least one language mainly such information that someone else would not be able to easily find out afterwards.

[misaochan]

As we all appear to agree on how to handle the "If the Wikidata item has a description in my language" scenario, I will create a separate issue for it that can be worked on ASAP.

Re: the "If the Wikidata item does not have a description in my language" scenario, I don't think WLM has a model that we can follow in this case. AFAIK the WLM monument lists for every country is carefully curated by national organizers from that country, so "does not have a description in my language" is very unlikely to happen in WLM or other national-based campaigns.

Multilingual descriptions are already possible in the app. However, pre-filling a description with a language that the user does not understand would feel very strange and wrong to the user IMO. Perhaps there is another way that we can approach this.

[SJu-w]

It's been a few months, and the app still produces those nonsensical, meaningless descriptions!