Wikidata:Property proposal/Sister projects

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

See also edit

This page is for the proposal of new properties.

Before proposing a property

  1. Search if the property already exists.
  2. Search if the property has already been proposed.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Read Wikidata:Creating a property proposal for guidelines you should follow when proposing new property.
  6. Start writing the documentation based on the preload form below by editing the two templates at the top of the page to add proposal details.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the creation of the proposal, by a property creator or an administrator.
  3. See property creation policy.

On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/02.

Wikipedia edit

Wiktionary edit

thesaurus' properties edit

thesaurus's main topic edit

Descriptionprimary topic of the subject Wikimedia thesaurus
RepresentsWiktionary thesaurus page (Q31209114)
Data typeItem
Example 1Thesaurus:snake (Q82477488)snake (Q2102)
Example 2Thesaurus:cat (Q101128192)house cat (Q146)
Expected completenesseventually complete (Q21873974)
See alsothesaurus's main topic
Single-value constraintyes
Distinct-values constraintyes

thesaurus combines topics edit

Descriptionthis theasurus combines (intersects) these two or more topics
RepresentsWiktionary thesaurus page (Q31209114)
Data typeItem
Example 1Thesaurus:fruit (Lakota language) (Q73120032)fruit (Q3314483), Lakota (Q33537)
Example 2Thesaurus:fr:chat (Q30699903)house cat (Q146), French (Q150)
Expected completenesseventually complete (Q21873974)
See alsothesaurus combines topics
Single-value constraintno
Distinct-values constraintno

topic's main thesaurus edit

Descriptionmain Wikimedia theasurus
RepresentsWiktionary thesaurus page (Q31209114)
Data typeItem
Example 1fruit (Q3314483)Thesaurus:fruit (Lakota language) (Q73120032) ?
Example 2snake (Q2102)Thesaurus:snake (Q82477488)
Expected completenesseventually complete (Q21873974)
See alsothesaurus' main topic
Single-value constraintyes
Distinct-values constraintyes

Motivation edit

Some Wiktionary projects use thesauri to organise information in the same way as categories. We (as a Wiktionary contributors) think it is better to have specific properties for these "objects" (as is done for other "objects" in the Wikimedia ecosystem: categories, lists, templates, etc.). I therefore propose the creation of these 3 properties by mimicking the properties for categories. Pamputt (talk) 17:57, 7 February 2023 (UTC)Reply[reply]

Discussion edit

  1.   Support As proposer. Pamputt (talk) 18:34, 7 February 2023 (UTC)Reply[reply]
  •   Comment @Pamputt: Proposers shouldn't comment to support their own proposals, it's assumed, and this can confuse later viewers of the proposal. Secondly - can you explain wiktionary thesaurus pages a bit more for those of us not familiar with them? The way they are handled in French and English wiktionaries seems to be different, and I'm not convinced the links you propose are actually the right way to do this. It seems like main subject (P921) would handle your first proposal adequately but I'm not quite sure on that given the way these are structured. As to the second proposal, I see category combines topics (P971) is specific to categories so it would make sense to have something separate here, though perhaps there are alternatives. On the third one - this is just an inverse of the first proposed property? I don't think we want to do that. ArthurPSmith (talk) 20:42, 7 February 2023 (UTC)Reply[reply]
    These three properties correspond with category's main topic (P301), topic's main category (P910) and category combines topics (P971).
    To explain what is a Wiktionary thesaurus, I can copy the introductory sentence of en:Wiktionary:Thesaurus, i.e. a thesaurus [is] a dictionary of synonyms, antonyms, and further semantically related terms such as hyponyms, hypernyms, meronyms, and holonyms. The informations is not presented exactly the same way between enwiktionary and frwiktionary, but thesauri on both Wiktionary projects are supposed to have the same words ultimately.
    About the first proposal, yes, main subject (P921) may fit for thesaurus but I think a separate property will be useful to optimize SPARQL queries (actually it is the same for the categories; we may use {[P|921}} for them but category's main topic (P301) is preferred.
    About the third proposal, yes this is the inverse of the first one. I am confused with the Wikidata policy about inverse properties. We have category's main topic (P301) that is the inversed of topic's main category (P910) and we have many other couple of properties that are the inverse of each other. But I read time to time that it is not a "good practice". So, I do not strongly support the third proposal. Pamputt (talk) 22:07, 7 February 2023 (UTC)Reply[reply]
    Regarding the differences between en and fr wiktionaries, it looks like the en pages are always a list of (English) synonyms or maybe slightly related "-nyms" but not much more. On the other hand the fr pages seem to be a mix of multi-language pages about the same topic, with each language page being somewhat variable but in particular the French ones have a huge amount of information on words relating to the topic - not just synonyms but words from all kinds of contexts. These seem like different things so I'm wondering if this sort of property is really the best way to express what's going on here. But I really don't know much about how this has been done in general in the wiktionaries, or even if this holds beyond these few examples in en and fr. ArthurPSmith (talk) 20:51, 8 February 2023 (UTC)Reply[reply]
    On inverse properties - there are a number from the early days of Wikidata (property #'s below 1000) but it has been discouraged in recent years as inverses are redundant data with an additional maintenance burden (if a relation is there in one direction but not the other, which side of the relation is correct?). In general for one-to-many relations it's best if the property is on the "many" side to keep the size of Wikidata items manageable. But I'm not clear here given the above issues with the structure of these thesaurus items whether it is actually a one-to-many or closer to a one-to-one relation? ArthurPSmith (talk) 20:56, 8 February 2023 (UTC)Reply[reply]
    Category:Thesauri (Q9140405) lists all Wiktionary projects that have thesauri. En and fr wiktionary are not alone. Chinese wiktionary, Spanish Wiktionary, Portugese Wiktionary and so on have many thesauri, so such properties would apply to several Wiktionary projects. Most of the Wiktionary projects do the same as enwiktionary, but it does not change the fact that they are all (incomplete) thesauri.
    As inverse properties are discouraged, proposal number 3 should not be created but for the two others, I do not see any better solution. Pamputt (talk) 15:10, 24 January 2024 (UTC)Reply[reply]
  1.   Support (French wiktionary user here.) The third one is the one I had thought of initially, before seeing the two others, and remains the one that makes most sense to me. (ie. if we had to keep only one, I'd favour number 3 over number 1) Exilexi (talk) 12:02, 8 February 2023 (UTC)Reply[reply]

Wikiquote edit

Wikisource edit

Wikivoyage edit

Wikinews edit

Wikiversity edit

Wikibooks edit

Wikispecies edit

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

Wikimedia Incubator edit

Wikimedia Commons edit

image revision-id edit

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

Motivation edit

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[reply]

Discussion edit

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[reply]

depicts lexeme form edit

Motivación edit

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[reply]

Discussion edit

  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[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[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[reply]
Oh, I see, I misunderstood the examples.   Support. AntisocialRyan (Talk) 17:00, 18 July 2022 (UTC)Reply[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[reply]
@Strakhov: How is a person supposed to decide whether to use items or lexemes to tackle descriptions? ChristianKl10:23, 19 July 2022 (UTC)Reply[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[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[reply]
  Comment Sorry, I confused inscription (P1684) with inscription mentions (P6568). strakhov (talk) 14:51, 19 July 2022 (UTC)Reply[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[reply]
  •   Support with the change to lexeme form, great! Ainali (talk) 08:32, 31 August 2022 (UTC)Reply[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).

General edit