Property proposal:	Generic	Authority control	Person	Organization
	Creative work	Place	Sports	Sister projects
	Transportation	Natural science	Computing	Lexeme

Wikipedia

Wiktionary

Wikiquote

Wikisource

Wikivoyage

Wikinews

Wikiversity

Wikibooks

Wikispecies

See Wikidata:WikiProject Taxonomy; Wikidata:Wikispecies; wikispecies:Wikispecies:Project Wikidata

Wikimedia Incubator

Wikimedia Commons

‎audio version of text

Under discussion

Description	The audio version of a text (e.g. book). Not the audio version of the Wikipedia article about the text (e.g. book).
Data type	Commons media file
Example 1	A Calendar of Wisdom (Q2894412)audio version of textc:File:Leo Tolstoy reads from Calendar of Wisdom (1908).mp3 (all with language qualifier)
Example 2	A Midsummer Night's Dream (Q55873489)audio version of textc:File:Tales from Shakespeare 02 lamb.ogg
Example 3	A Reminiscence of Dr. Samuel Johnson (Q4177057)audio version of textc:File:LibriVox - reminiscence of dr samuel johnson lovecraft ch.ogg

Motivation

Currently, both audio versions of Wikipedia articles as well as of other kinds of texts like books, short stories, legal texts, poems, etc are being added to spoken text audio (P989). If a Wikipedia article is about for example a book, there's no way to know whether the audio file is of the book's text or of the Wikipedia article's text.

For example, because of this problem Wikidata:List of audio podcasts of Wikipedia articles in English shows a mix of mostly Wikipedia audios and audios of short stories etc such as the three above. One can't distinguish them in queries.

There you can easily see more cases of non-Wikipedia text audios by coincidence because I recently added the recording date (P10135) qualifier to all the spoken text audios of Wikipedia articles that were placed in the Commons categories for these but not to the audio versions of any other works.

Previously asked about this here where it looks like both @Immanuelle, Trade: – all thread participants – found the solution-option of a new property most suitable and I now also think this would be the best or only proper way to solve this.

In the spoken text audio proposal Filceolaire foresaw this problem, saying We need to distinguish between a recording of the item (for a poem this would be a spoken word audio) and a recording of the wikipedia article in a particular language, but it wasn't addressed.

--Prototyperspective (talk) 21:07, 26 November 2025 (UTC)[reply]

Are we planning on any kind of mass deprecation or something of the older property? I am not sure the magnitude that it is polluted. Immanuelle (talk) 05:38, 28 November 2025 (UTC)[reply]

Discussion

Support --Trade (talk) 02:40, 27 November 2025 (UTC)[reply]
Support -wd-Ryan (Talk/Edits) 23:21, 27 November 2025 (UTC)[reply]
Support Immanuelle (talk) 05:27, 28 November 2025 (UTC)[reply]
Oppose in this way. Indeed we need to distinguish audio files that are audio versions of Wikipedia articles from other uses, but there are other use cases that need to be accurately modeled. For that, we'll need two properties:
audio version of Wikimedia sitelink
to link items with spoken versions of any Wikimedia page: mainly Wikimedia and Wikisource, but could function for any project. This could be a new property (and in this case, P989 should be deprecated), or we just could broad the scope of P989, in order to link to any Wikimedia project. This should have a qualifier "applies to Wikimedia project".
audio of the item
to link an audio item that can represent the item. It would be like the audio version of P18. In my opinion, P51 fits well for that, no need for a new property.
Some of the use cases could be the following:
Audio files corresponding to Wikisource texts
if the audio file is just a voiced recording of a text on Wikisource. We can have two subcases:
an item that describes the work and the edition
in this case we could just use the "audio version of wikimedia sitelink" property in that item. Example: A Reminiscence of Dr. Samuel Johnson (Q4177057)P<audio-wikimedia>File:LibriVox - reminiscence of dr samuel johnson lovecraft ch.oggP<project>English Wikisource (Q15156406)
an item that describes an specific edition of a written work in another item
the case in many translations on many Wikisources. On these cases, the link to the audio file should be made on the edition item, not on the work item, since they will be linked with P629 or another property. Example: Manifesto of the Communist Party/1 (Q16749688)P<audio-wikimedia>File:Manifesto comunista capitulo I.oggP<project>Portuguese Wikisource (Q19826831).
Audio files not corresponding to Wikisource texts
in my opinion, they should be linked with P<audio-of-the-item>. It's the same model like this statement found in the examples for P51 about a symphony: Symphony No. 7 (Q260957)audio (P51)File:JOHN MICHEL CELLO-BEETHOVEN SYMPHONY 7 Allegretto.ogg. I don't know if there's a case like this, but it's perfectly possible.
--Tinker Bell ★ ♥ 05:55, 28 November 2025 (UTC)[reply]
- audio version of Wikimedia sitelink for this Wikimedia page-version URL (P7569) can be used in (in practice it's not set but I have added recording date (P10135) to items which approximates it). This could become a qualifier here for texts that have a Wikisource text but is no reason to object as far as I can see. Whether or not a new property is needed for that can be discussed elsewhere or in a new property proposal for it.
- audio of the item this is just audio (P51) and no reason to object as far as I can see.
- Audio files corresponding to Wikisource texts This would be a use of the property proposed here. If you're saying there is a need for yet another property then that's no reason to object the creation of this one but a reason to create a proposal for that other property. However, I don't see why this would be needed: this can be set on the property proposed here either on the work item or the specific edition item.
- Audio files not corresponding to Wikisource texts Audio files of music or sounds are different from audio versions of texts so they should be set on this proposed property rather than the very ambiguous P51.
Prototyperspective (talk) 13:13, 28 November 2025 (UTC)[reply]

image revision-id

On hold

Description	Qualifier to inidicate the particular revision of an image that a statement refers to
Data type	String
Domain	statements with value: media
Example 1	File:Pigot and Co (1842) p2.138 - Map of Lancashire.jpg (revision-sensitive statement) → 279847594
Example 2	File:Larousse,_Plan_de_Paris,_1900_-_David_Rumsey.jpg (revision-sensitive statement) → 180884966
Example 3	File:1768_Jeffreys_Wall_Map_of_India_and_Ceylon_-_Geographicus_-_India-jeffreys-1768.jpg (revision-sensitive statement) → 345654849
Allowed values	\d+
Planned use	To indicate which revision of a map image has been georeferenced on Commons MapWarper. But further use-cases are likely to emerge.
See also	Wikimedia import URL (P4656)

Motivation

Sometimes it is important to be able to indicate which particular revision of a Commons image a Wikidata or SDC statement refers to. For example, georeferencing information will fail to be correct if an image has been cropped. A mechanism is therefore necessary to be able to specify a particular version of a Commons file. Jheald (talk) 13:16, 14 August 2019 (UTC)[reply]

Discussion

Proposed. Jheald (talk) 13:16, 14 August 2019 (UTC)[reply]
Comment This is not going to work properly, because, when someone will upload a new version, the file will change its version number, but the value in the property may stay the old one. Moreover, there was a discussion with WMF team, that it's not possible to track different versions so they cannot be stored in Wikidata. --Juandev (talk) 20:21, 29 September 2019 (UTC)[reply]
- @Juandev: The whole point is that we want the property to point to the old version of the image, because that is the one that the georeferencing was done against, not any later reupload that may potentially have been cropped. Jheald (talk) 22:15, 13 October 2019 (UTC)[reply]
I think the (current) samples give the revision of the file description page, not the image version. --- Jura 09:35, 13 October 2019 (UTC)[reply]
- Good spot. @Juandev, Jura1: It ought to be possible somehow to identify an particular upload version. Worst case, one could make the value URL-valued, and eg specify https://upload.wikimedia.org/wikipedia/commons/archive/9/93/20120327114216%21LeKeux_-_Cambridge%2C_c1840_-_Corpus_01_-_memorialsofcambr01wriguoft_0238.jpg for the first version of File:LeKeux_-_Cambridge,_c1840_-_Corpus_01_-_memorialsofcambr01wriguoft_0238.jpg (not that that is a map, but it is a file with several revisions). Jheald (talk) 22:15, 13 October 2019 (UTC)[reply]
  - Does that work for the current version as well? I think the upload date is probably the only element available in the GUI. Isn't there some hash stored as well? --- Jura 08:03, 14 October 2019 (UTC)[reply]
    There is no public id for image version. In theory timestamp could be on if we use string as datatype (date doesnt work as its accuracy is YYYYMMDD only) or the log_id of the upload. --Zache (talk) 11:38, 18 March 2024 (UTC)[reply]
Slight Support. I understand the argumentation, but during my 15 year old presence I havent encountered such situation.--Juandev (talk) 12:47, 15 November 2019 (UTC)[reply]
Slight Oppose. I do not see the need, and it might not be technically freezable. I am open to change my vote if there is a clear need. --Jarekt (talk) 01:54, 15 May 2020 (UTC)[reply]

I marked this proposal as on hold. Currently we have two solutions:

Wait phab:T28741 to be fixed so file versions have unique identifiers
Create a property "image timestamp", but 1. we still does not have the datatype unless we store timestamp as string and 2. timestamp may still be not unique.

--GZWDer (talk) 23:20, 28 May 2020 (UTC)[reply]

depicts lexeme form

On hold

Description	lexeme form depicted in the media file
Data type	Form
Domain	Commons images
Example 1	File:Bandera_de_los_Treinta_y_Tres_Orientales.JPG → L562031#F1 The ID "L562031#F1" is unknown to the system. Please use a valid entity ID.
Example 2	File:Protests_in_Puerta_del_Sol,_Madrid_-_Ahora_o_Nunca.jpg → L56980#F1 The ID "L56980#F1" is unknown to the system. Please use a valid entity ID.
Example 3	File:BULLSHIT_rubber_stamp_(mirrored)_on_the_desk_of_a_street_photographer.jpg → L299205#F1 The ID "L299205#F1" is unknown to the system. Please use a valid entity ID.
Example 4	File:Mrs._Susanna_Morin_Swing_160028v.jpg → L9656#F1 The ID "L9656#F1" is unknown to the system. Please use a valid entity ID.
Example 5	File:Vignet_Ende.jpg → L29356#F1 The ID "L29356#F1" is unknown to the system. Please use a valid entity ID.
See also	depicts (P180)

Motivación

In Wikimedia Commons there are thousands of images depicting lexemes (a few of them: c:Category:Images by text, not categorised by language yet). Creating a property to indicate the lexemes depicted in a file would be great (IMHO) with regard to structuring linguistic data in media files. This was posted here. Apparently this was also proposed here a few months ago. strakhov (talk) 16:06, 16 July 2022 (UTC)[reply]

Discussion

Comment To make this really useful, wouldn't it be better if it was "depicts lexeme form"? That way, we would capture more specifically what is on the image. Ainali (talk) 17:31, 16 July 2022 (UTC)[reply]

Comment I don't know. That way it would be captured more specifically what is on the image, for sure, but in the other hand it may make more difficult/complex introducing data. Are there already in Wikidata other properties with the lexeme datatype using forms? strakhov (talk) 10:03, 17 July 2022 (UTC)[reply]
Comment Ah, I see there are a few, indeed. Category:Properties with wikibase-form-datatype. strakhov (talk) 10:22, 17 July 2022 (UTC)[reply]
Comment After a few checks, I can say it's OK for me changing datatype to "form". strakhov (talk) 10:24, 17 July 2022 (UTC)[reply]
Support since the proposal has been change to form. Cheers, VIGNERON (talk) 13:28, 17 July 2022 (UTC)[reply]

Is it only for qualifiers? What if we want to add it as a statement to 🆓 (Q87576444), for example? AntisocialRyan (Talk) 18:14, 17 July 2022 (UTC)[reply]

- @AntisocialRyan: It's for lexemes. 🆓 (Q87576444) is a normal item. Lexemes are not qualifiers but their own data type. ChristianKl ❪✉❫ 13:42, 18 July 2022 (UTC)[reply]
  I'm aware of that, I meant can we add depicts lexeme form: free (L4087) to the item 🆓 (Q87576444)? As a main statement and not a qualifier. AntisocialRyan (Talk) 15:26, 18 July 2022 (UTC)[reply]

@AntisocialRyan: In fact this property is not intended to be used as a qualifier, but as a main statement. But not (at least not mostly) here, but in Wikimedia Commons, with media files. strakhov (talk) 16:10, 18 July 2022 (UTC)[reply]

Oh, I see, I misunderstood the examples.

Support. AntisocialRyan (Talk) 17:00, 18 July 2022 (UTC)[reply]

I would like the description to be more explicit about what depicts means. What's valid and what's not valid as an image for depicts? ChristianKl ❪✉❫ 13:55, 18 July 2022 (UTC)[reply]

@ChristianKl: with regard to the description, mirroring P180's English description, "word visually depicted in an image, see also P180 for entities depicted" may work (?). But please feel free to propose a better one.

With regard to what's valid and what not... I guess it's valid when the lexeme form is depicted in the file. Since depicts (P180) has no indication for what's not valid and what is valid, I do not know why this one would need such prescription. Use of P180 is at the discretion of the user and common sense. Anyway, if you believe there are situations when a form is depicted in a file but using this property would not be valid, please indicate them here. strakhov (talk) 15:59, 18 July 2022 (UTC)[reply]

@Strakhov: How is a person supposed to decide whether to use items or lexemes to tackle descriptions? ChristianKl ❪✉❫ 10:23, 19 July 2022 (UTC)[reply]

@ChristianKl: When depicts (P180) should be used and when not IMO falls under the scope of that property (not this one's), and IMO we cannot decide that here (it's a bit tricky and there are still discussions in Commons about when it's appropiate and when not). Anyway, for example, IMHO in the file c:File:Spain Poznan Spain could by You.jpg it would ok using "depicts lexeme form" = L254265#F1, but it would not be ok using depicts (P180) -> Spain (Q29) (the image is not even taken in Spain, but in Poland). On the contrary, in the file c:File:A.L. Hickmann's geographisch-statistischer universel-Taschen-Atlas. 1900 (80112515).jpg IMHO would be "OK enough" using "depicts lexeme form" = L36513#F1 and depicts (P180) -> Spain (Q29) (both properties). strakhov (talk) 15:20, 19 July 2022 (UTC)[reply]

Comment We should principally be using inscription (P1684) for text on depicted items. Not sure how the present proposal relates to that. And wary that this property might lead to a *lot* of statements per image. Jheald (talk) 15:35, 18 July 2022 (UTC)[reply]

@Jheald: inscription (P1684) is for entities, concepts, etc, not text: it's language independent, it does not capture different languages being used nor synonyms in the same language (but it captures senses). I guess the problem with someone adding a lot of "depicts lexeme form" statements is not different to someone adding too many P180/~~P1684~~P6568 statements (that properties could also be abused). Anyway, if someone believes a big "please, do not try to transcribe full book/newspaper pages such as this one while using this property, try to use common sense" is needed... Cheers. strakhov (talk) 15:59, 18 July 2022 (UTC)[reply]

Comment Sorry, I confused inscription (P1684) with inscription mentions (P6568). strakhov (talk) 14:51, 19 July 2022 (UTC)[reply]

You are absolutely right about this proposal not relating to that property. My bad, I did not consider that one. Well, I guess inscription (P1684) is good for transcribing full sentences (they can be added in the file description, file caption, as free text,... too). But it's pretty bad when it comes to crosslinking Wikidata Lexicographical data and Wikimedia Commons. I am interested in the latest. strakhov (talk) 15:20, 19 July 2022 (UTC)[reply]

Support with the change to lexeme form, great! Ainali (talk) 08:32, 31 August 2022 (UTC)[reply]
Support in thinking about this, this would open up some interesting possibilities. If we want to document information about what a word looks like written by hand, which can often differ from the digital representation, this would be useful for linking photos showing this to lexeme forms. I uploaded an example of سلسہ just now which I would add this property to if available.

– The preceding unsigned comment was added by Middle river exports (talk • contribs).

I've marked this as on hold, because it's not possible to link to lexemes, senses or forms on Commons. - Nikki (talk) 10:49, 11 September 2022 (UTC)[reply]
T304392 on phabricator. strakhov (talk) 15:16, 13 September 2022 (UTC)[reply]
Question What about homonyms? Those might be forms of distinct lexemes or even of the same lexeme, e.g., in the case of inflection. Are editors adding statements with this proposed property to images supposed to work out which of potentially several possible lexemes (and therefore senses) might apply? Which grammatical features apply? What if the inscription is intentionally ambiguous? Or if the image is taken too far out of context? ―BlaueBlüte (talk) 04:38, 1 February 2023 (UTC)[reply]
Comment So far I have just been using subject lexeme form (P5830) and subject sense (P6072), see, e.g., https://www.wikidata.org/wiki/Lexeme:L43527 — Finn Årup Nielsen (fnielsen) (talk) 10:52, 25 April 2023 (UTC)[reply]
Adding all images containing a word to the lexeme for the word would be a terrible idea. - Nikki (talk) 13:25, 29 April 2023 (UTC)[reply]
Support, an important property for the connectivity of Wikidata.--Arbnos (talk) 21:04, 17 January 2024 (UTC)[reply]

trailer of

Under discussion

Description	works that this trailer video represents
Represents	trailer (Q111903295)
Data type	Item
Domain	Commons media files
Example 1	File:0 A D Alpha 17 Trailer - YouTube.webm → 0 A.D. (Q161234)
Example 2	File:Steam Announcement Trailer - Detroit Become Human, Beyond Two Souls, Heavy Rain - Quantic Dream.webm → Detroit: Become Human (Q21246348), Beyond: Two Souls (Q166226) and Heavy Rain (Q647855)
Example 3	File:Dustborn (by Red Thread Games) – Teaser Trailer.webm → Dustborn (Q122962928)
Example 4	File:【本予告】劇場版アニメ「i☆Ris the Movie - Full Energy!! -」5月17日(金) 全国劇場公開.webm →Iris the Movie: Full Energy!! (Q125955160)
Example 5	File:2023.11.23 RELEASE NEW ALBUM「NEW ERA -the beginning-」Trailer.webm → NEW ERA -the beginning- (Q134942541)

Motivation

Could not find any existing properties that fitted

@Wd-Ryan:--Trade (talk) 21:03, 15 June 2025 (UTC)[reply]

Discussion

I'm not that familiar with Commons structured data - would something like this work? File:0_A_D_Alpha_17_Trailer_-_YouTube.webmdepicts (P180)0 A.D. (Q161234)subject has role (P2868)video game trailer (Q65972034) -wd-Ryan (Talk/Edits) 23:10, 15 June 2025 (UTC)[reply]
I dont even know if P2868 is allowed to be used on Commons structured data Trade (talk) 00:35, 16 June 2025 (UTC)[reply]
According to the property constraints, it is allowed on the Wikibase MediaInfo (Q59712033) datatype. But I'd rather wait for someone with Commons experience before making a decisive vote. -wd-Ryan (Talk/Edits) 14:34, 16 June 2025 (UTC)[reply]
Assuming that is technically possible, I think it would work (though I can't say it's a pinnacle of clarity). @Trade: do you want to try that out on one of your examples and see if there is any technical difficulty in using it? - Jmabel (talk) 18:53, 17 June 2025 (UTC)[reply]
It technically works but it doesnt feel right. I think depicts should be limited to where a work is being depicted (an photo of someone playing an video game, etc), not when the work itself is the whole file (the trailer) Trade (talk) 19:53, 17 June 2025 (UTC)[reply]

@PMG @Sannita maybe you have something to say, about structured data on commons. (IMHO a new property can be avoided if the P180 is enough) GiovanniPen (talk) 08:08, 16 August 2025 (UTC)[reply]
@Trade: I'm totally confused how cosplay (Q142554) fits into this. (Please ping if replying.) - Jmabel (talk) 03:57, 17 June 2025 (UTC)[reply]
@Jmabel:--Trade (talk) 17:58, 17 June 2025 (UTC)[reply]
- So it was just a typo? - Jmabel (talk) 18:50, 17 June 2025 (UTC)[reply]
  yeah Trade (talk) 18:58, 17 June 2025 (UTC)[reply]
Are we even supposed to use audiovisual works as an value for depicts (P180)? It is not exactly clear when this would and would not apply @Jmabel:--Trade (talk) 12:12, 20 June 2025 (UTC)[reply]
- @Trade: Seems to me like it at least sometimes works. Certainly
  ⟨ Empire (Q177519)    ⟩ depicts (P180) ⟨ Empire State Building (Q9188)    ⟩
  is correct. The question would be how broadly it would apply, not whether it would apply. - Jmabel (talk) 17:25, 20 June 2025 (UTC)[reply]
  Your example is using an building as an value, not an audiovisual work.. You are also using the property on a item, not a media file. Trade (talk) 22:09, 20 June 2025 (UTC)[reply]
Support --Tinker Bell ★ ♥ 00:02, 3 September 2025 (UTC)[reply]

Panoramax picture ID

Under discussion

Description	Persistent identifier for images on Panoramax (Q120971923)
Data type	External identifier
Domain	media info, image (Q478798)
Example 1	File:Sughera monumentale (Isola Bella).jpg → 6f92f088-afd0-4471-af2c-d675bb852254
Example 2	File:Autoroute_A623.jpg → e7b30691-8dc8-40f3-a9e2-f8c711542803
Example 3	File:Poudrière de Roc'h-Ru, Saint-Riom (île de Bréhat).jpg → 9545ac97-fba6-4e6d-986b-77688ebf0850
Example 4	File:CAU_Pathway_Mural_01.jpg → cbd4ab61-6775-4c5e-b824-cadb6e3c72f6
Allowed values	[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12} ^[1]
Source	https://api.panoramax.xyz
External links	Use in sister projects: [ar] • [az] • [bn] • [de] • [en] • [es] • [fa] • [fr] • [he] • [hi] • [it] • [ja] • [ka] • [kn] • [ko] • [ml] • [mr] • [nl] • [pl] • [pt] • [ro] • [ru] • [sv] • [te] • [tr] • [ur] • [vi] • [zh] • [commons] • [species] • [wd] • [en.wikt] • [fr.wikt].
Planned use	Link commons images that were imported from Panoramax to their source
Number of IDs in source	more than 80 million ^[2]
Expected completeness	always incomplete (Q21873886)
Implied notability	Wikidata property for an identifier that does not imply notability (Q62589320)
Formatter URL	https://api.panoramax.xyz/?focus=pic&pic=$1
URL match pattern	^https?:\/\/[^\/]panoramax[^\/]\/?[?#].focus=pic.pic=([0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12})
Single-value constraint	yes
Distinct-values constraint	yes

Motivation

Even though it is currently possible to extract the ID from file summaries, doing so involves quite some effort due to the quite differing formats of the URLs provided. File:Sughera monumentale (Isola Bella).jpg for example links to https://panoramax.mapcomplete.org/?s=fp;s2;p6f92f088-afd0-4471-af2c-d675bb852254;c296.32/-23.44/36;m17/45.894133/8.527781 which appears to be an older format that gets redirected. I was able to extracted 150 picture ids and visually ensured the images on commons and panoramax match but having these in a more machine readable format and being able to query them would be amazing. – The preceding unsigned comment was added by GinnyTheCar (talk • contribs) at 13:17, December 27, 2025 (UTC).

Discussion

General

[1] ttps://gitlab.com/panoramax/server/api/-/blob/develop/migrations/20221201_01_wpCGc-initial-schema.sql?ref_type=heads#L23

[2] ttps://api.panoramax.xyz/api/stats

[1]

[2]

See also

Wikipedia

Wiktionary

Wikiquote

Wikisource

Wikivoyage

Wikinews

Wikiversity

Wikibooks

Wikispecies

Wikimedia Incubator

Wikimedia Commons

‎audio version of text

Motivation

Discussion

image revision-id

Motivation

Discussion

depicts lexeme form

Motivación

Discussion

trailer of

Motivation

Discussion

Panoramax picture ID

Motivation

Discussion

General