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

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
Allowed values	\d+
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
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 invalid ID (L562031#F1)
Example 2	File:Protests_in_Puerta_del_Sol,_Madrid_-_Ahora_o_Nunca.jpg → L56980#F1 invalid ID (L56980#F1)
Example 3	File:BULLSHIT_rubber_stamp_(mirrored)_on_the_desk_of_a_street_photographer.jpg → L299205#F1 invalid ID (L299205#F1)
Example 4	File:Mrs._Susanna_Morin_Swing_160028v.jpg → L9656#F1 invalid ID (L9656#F1)
Example 5	File:Vignet_Ende.jpg → L29356#F1 invalid ID (L29356#F1)
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 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]

‎ISCC

Under discussion

Description	International Standard Content Code. Hash code that identifies a media object based on fuzzy hashing.
Represents	International Standard Content Code (Q129857134)
Data type	String
Allowed values	ISCC:[A-Z2-7]{10,73}
Example 1	Zaadpeulen van goudenregen (Laburnum anagyroides), 31-08-2024. (d.j.b) → ISCC:KECV7KS6BOJ35WEUX7SMMG3BY4LGBACQ2PJPVVGGHVEZ4DZISC7CXLI
Example 2	Rooster crowing small → ISCC:KMCU72IF2EHZH5PKFS2UODT2EGOTGY5CIBRMRYSQR6HGLFBHAAUANVY
Example 3	Aristotle latin manuscript → ISCC:KECV7NLW5ME7CEN2XZHDHAODEGDT66ZOQVNDPKM4AKWU6L32BHKVXMQ

Motivation

As of May 2024, the International Standard Content Code (Q129857134) has been an ISO standard (ISO 24138:2024) to identify digital assets in a robust way by applying fuzzy hashing technology to objects. Awinkler3 (talk) 14:50, 1 November 2024 (UTC)[reply]

Discussion

Notified participants of WikiProject Commons

Comment This would be more useful if the Commons servers could automatically generate the hash on file upload, see phab:T121797. Dexxor (talk) 18:42, 1 November 2024 (UTC)[reply]
definitely. I'd also love to see automatic embeddings on Commons to make (third-party?) similiarity/semantic search easier ... that's another topic, though. Awinkler3 (talk) 13:30, 2 November 2024 (UTC)[reply]
Support I guess the scope is only Commons files, right? Multichill (talk) 13:09, 2 November 2024 (UTC)[reply]
mostly, I guess. I am thinking of structured data on Commons Awinkler3 (talk) 13:27, 2 November 2024 (UTC)[reply]
Comment The "ISCC" prefix should not be stored in the values. It's redundant information. Dexxor (talk) 19:11, 3 November 2024 (UTC)[reply]
not sure how to handle this. It's part of the ID (albeit redundant) Awinkler3 (talk) 18:40, 4 November 2024 (UTC)[reply]
Comment presumably ISRC (P1243) and ISWC (P1827) are related (those are for musical works)? Note also International Standard Text Code which briefly had a property here but was removed (deletion discussion). ArthurPSmith (talk) 21:23, 4 November 2024 (UTC)[reply]

General

Wikidata:Property proposal/Sister projects

See also

Contents

Wikipedia

Wiktionary

Wikiquote

Wikisource

Wikivoyage

Wikinews

Wikiversity

Wikibooks

Wikispecies

Wikimedia Incubator