Wikidata:Property proposal/Sister projects - Wikidata

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

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

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]

• 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]

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]

 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/P1684P6568 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]

 – 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]

Currently there is no way to indicate this so a new property is needed--Trade (talk) 00:59, 2 February 2025 (UTC)[reply]

• Couldn't the property be widened to any AI generated content, including text? Vicarage (talk) 19:31, 3 February 2025 (UTC)[reply]

  is there even a demand for that Trade (talk) 12:41, 5 February 2025 (UTC)[reply]

  I'm sure there will be, why not have this property ready, rather than have someone propose a new one, or worse, several.  Support if scope broadened to all creative works. Vicarage (talk) 20:00, 18 February 2025 (UTC)[reply]

•  Comment Wikidata string values have a very short length limit (1200 characters I think?) - I'm suspecting that won't be enough for many of these? ArthurPSmith (talk) 20:27, 3 February 2025 (UTC)[reply]

  this not the first time statements have broken the string limit

  Usually we just split up the statement Trade (talk) 00:39, 4 February 2025 (UTC)[reply]

• Are there any cons of using monolingual text? Or is the language considered unimportant in prompt engineering? --Matěj Suchánek (talk) 12:12, 5 February 2025 (UTC)[reply]

  depends on the Text-to-image software i guess Trade (talk) 12:21, 5 February 2025 (UTC)[reply]

  Language should probably be a mandatory qualifier. Maybe a possibility of allowing for multiple languages and possibly an explicit "no language" for quasi-nonsense. - Jmabel (talk) 16:32, 17 February 2025 (UTC)[reply]

  Except for allowing for multiple languages, monolingual text would work the same as mandatory qualifier, but "by design". --Matěj Suchánek (talk) 17:58, 17 February 2025 (UTC)[reply]

  Better now? Trade (talk) 16:24, 18 February 2025 (UTC)[reply]

•  Support They host AI-generated files on Commons, and there should be clean way to access the prompt. --Matěj Suchánek (talk) 16:43, 18 February 2025 (UTC)[reply]