See also

[edit]

• Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
• Wikidata:Properties for deletion – proposals for the deletion of properties
• Wikidata:External identifiers – statements to add when creating properties for external IDs
• Wikidata:Lexicographical data – information and discussion about lexicographic data on Wikidata

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/07.

I am one of the admins on Numista, we use wikidata a lot already for our databases, we are developing huge section for issuers and would like to bridge it with wikidata entries (like we already do with rulers and mints).  – The preceding unsigned comment was added by Compendium2 (talk • contribs) at 10:10, 10 June 2024‎ (UTC).[reply]

• Marsupium (talk) 03:58, 29 January 2019 (UTC) (observing member) FedericoMorando (User talk:FedericoMorando) Pmt (talk) 20:46, 17 October 2020 (UTC) Ahc84 (talk) 18:48, 19 October 2020 (UTC) Christelle Molinié (talk) 14:05, 20 March 2021 (UTC) Heberlei (talk) 16:38, 24 March 2021 (UTC) Stratocaster47 (talk) 15:22, 17 December 2021 (UTC) TiagoLubiana (talk) 20:42, 5 January 2022 (UTC)[reply]
  Notified participants of WikiProject Numismatics. Regards Kirilloparma (talk) 18:49, 26 June 2024 (UTC)[reply]

The metamath set.mm database is a catalogue of formalized definitions and theorems in mathematics. In contrast to other such libraries like the Lean mathlib, it's relatively monolithic, identifiers change very rarely and every identifier has a website attached. This would be a first step into integrating this formalized mathematical knowledge into Wikidata. --Uniwah (talk) 19:02, 21 June 2024 (UTC)[reply]

Notified participants of WikiProject Mathematics -- Uniwah (talk) 19:02, 21 June 2024 (UTC)[reply]

 Support This would be very useful for the mathematical community! Also the site says "over 23,000 proofs" (and I'm assuming each theorem has at least one proof), against Wikidata's hundreds of millions of items, so we could definitely add all the theorems. (We could also consider them notable, too, since I'm pretty sure the Metamath website is an excellent "serious and publicly available reference" for the purpose of WD:N#2). Duckmather (talk) 19:23, 21 June 2024 (UTC)[reply]

I don't really think all of these can be considered notable - for example, due to the low level nature of the software,

${\displaystyle \neg A=B\to A\neq B}$ and ${\displaystyle A\neq B\to \neg A=B}$ are considered distinct statements Uniwah (talk) 19:30, 21 June 2024 (UTC)[reply]

Well, mathematically speaking that's correct, and at the granularity level Wikidata should be working at, I think that's fine. The Anome (talk) 16:23, 24 June 2024 (UTC)[reply]

 Support Very relevant property. --Haansn08 (talk) 04:41, 22 June 2024 (UTC)[reply]

 Support An excellent idea. Linking into the formal proof world is an exciting development. 2A00:23C8:728A:2501:B814:9874:2D14:CB6F 09:45, 22 June 2024 (UTC)[reply]

• Comment I suggest we do this by first creating new items for every one of these definitions, and then using said to be the same as (P460) to link them to existing items where applicable. The metamath statements in each definition are concise enough that we could use defining formula (P2534) to actually add the metamath symbolic definition for that entity for each item with this property (see https://us.metamath.org/mpeuni/mmdefinitions.html). This could be done easily and automatically at the same time as adding these properties. We can also data-mine the description pages for the English-language names of each definition: for example, df-clim would have the description "limit relation for complex number sequences", and the defining formula " ⊢ ⇝ = {⟨𝑓, 𝑦⟩ ∣ (𝑦 ∈ ℂ ∧ ∀𝑥 ∈ ℝ+ ∃𝑗 ∈ ℤ ∀𝑘 ∈ (ℤ≥‘𝑗)((𝑓‘𝑘) ∈ ℂ ∧ (abs‘((𝑓‘𝑘) − 𝑦)) < 𝑥))}". I'm happy to do the bot work to make this happen.

  Regarding copyright: as far as I'm aware, all of Metamath's database is distrubuted under the CC0 Public Domain Dedication, except for the one file peano.mm, which is LGPL, about which we would need to devote some thought about how it should be handled. (See https://us.metamath.org/copyright.html). However, spot-checking some of the Peano arithmetic definitions on the website itself suggests that it's not based on peano.mm, so this might be a non-problem. The Anome (talk) 16:35, 24 June 2024 (UTC)[reply]

  This sounds great! I would be willing (and probably sufficiently knowledgeable) to contribute too, of course, feel free to reach out to me. There's a lot of conventions one would need to sort out though, for example, how should all the syntactic axioms be treated, and how would you turn the metamath terms into proper formulas for P2534?

  uses (P2283) could also be utilized to construct the metamath proof graph within wikidata.

  More generally speaking, some type for abstract syntact trees (or something similar) would be really helpful for math related content in the long run but that's obviously not realistic at the moment. Uniwah (talk) 19:30, 24 June 2024 (UTC)[reply]

  Mercifully Metamath does not use anything more complex than linear strings of symbols, so you don't need to worry about superscripts, subscripts, tables, boxes, or any of the other advanced LaTeX markup; it could all be converted from Unicode symbols to LaTeX entities by fairly simple lookup tables and pattern matching. Also, Metamath has its own ASCII-only low-level representation, which might be another way of achieving the same goal. The Anome (talk) 21:24, 24 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control highly authoritative source for the coverage of Colombian authors. --Epìdosis 18:05, 2 July 2023 (UTC)[reply]

•  Support --Kolja21 (talk) 19:09, 2 July 2023 (UTC)[reply]
•  Support - PKM (talk) 19:55, 2 July 2023 (UTC)[reply]
•  Support -- Bargioni 🗣 20:59, 2 July 2023 (UTC)[reply]
•  Support --Uomovariabile (talk) 09:16, 6 July 2023 (UTC)[reply]
•  Support -- Jason.nlw (talk) 12:47, 6 July 2023 (UTC)[reply]
•  Support -- Silva Selva (talk) 23:24, 9 July 2023 (UTC)[reply]
•  Support Atakhanli (talk) 20:47, 19 August 2023 (UTC)[reply]

 Comment I thank you @Kolja21, PKM, Uomovariabile, Jason.nlw, Silva Selva:. In these days, while revising the Mix'n'match catalog with @Bargioni:, we unfortunately discovered that this website seems to be somehow outdated: a new one exists and it has 253765 entries (more than double of the 124857 entries in this one), but unfortunately this new authority file doesn't offer good URIs for the authority records. The fact that is website is older is a just deduction, because we didn't find any explicit statement of its obsolescence; ideally, if someone is able to contact the National Library, having their confirmation about the relationship between these two websites would be the best way to have a clear picture of the situation. As of now, I put the property "on hold". --Epìdosis 07:28, 10 July 2023 (UTC)[reply]

I contacted the library. They will improve their authority records. So let's wait.  Bargioni 🗣 15:50, 23 July 2023 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Pocket Oxford American Thesaurus (Q126177898) (URL: https://www.oxfordreference.com/display/10.1093/acref/9780195301694.001.0001/acref-9780195301694). --Soufiyouns (talk) 07:42, 29 May 2024 (UTC)[reply]

•  Not done, no support for creation. Regards, ZI Jony ^(Talk) 03:34, 30 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Oxford Paperback Thesaurus (Q126178084) (URL: https://www.oxfordreference.com/view/10.1093/acref/9780199640959.001.0001/acref-9780199640959). --Soufiyouns (talk) 08:20, 29 May 2024 (UTC)[reply]

•  Not done, no support for creation. Regards, ZI Jony ^(Talk) 03:33, 30 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Pocket Oxford-Hachette French Dictionary: English-French (Q126323276) (URL: https://www.oxfordreference.com/display/10.1093/acref/9780191735134.001.0001/acref-9780191735134). --Soufiyouns (talk) 05:11, 3 June 2024 (UTC)[reply]

• That's enough with the English dictionaries, don't you think? (I'm pretty sure we also have enough French dictionary properties.) Mahir256 (talk) 01:27, 4 June 2024 (UTC)[reply]
•  Comment: @Mahir256: This is a complementary property to the reverse property proposal (Wikidata:Property proposal/Pocket Oxford-Hachette French Dictionary: French-English ID) for the French-English bilingual pocket dictionary, and I think this pair of reverse dictionaries would be useful in Wikidata. Regards. --Soufiyouns (talk) 14:52, 29 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Pocket Oxford-Hachette French Dictionary: French-English (Q126938206) (URL: https://www.oxfordreference.com/display/10.1093/acref/9780191739545.001.0001/acref-9780191739545). --Soufiyouns (talk) 14:31, 29 June 2024 (UTC)[reply]

•  Comment: This is a complementary property to the reverse property proposal (Wikidata:Property proposal/Pocket Oxford-Hachette French Dictionary: English-French ID) for the French-English bilingual pocket dictionary, and I think this pair of reverse dictionaries would be useful in Wikidata. Regards. --Soufiyouns (talk) 14:34, 29 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Pocket Oxford German Dictionary: English-German (Q126871196) (URL: https://www.oxfordreference.com/display/10.1093/acref/9780191735103.001.0001/acref-9780191735103). --Soufiyouns (talk) 12:43, 22 June 2024 (UTC)[reply]

• That's enough with the English dictionaries, don't you think? (I'm pretty sure we also have enough German dictionary properties.) Mahir256 (talk) 16:09, 26 June 2024 (UTC)[reply]
•  Comment: @Mahir256: This is a complementary property to the reverse property proposal (Wikidata:Property proposal/Pocket Oxford German Dictionary: German-English ID) for the German-English bilingual pocket dictionary, and I think this pair of reverse dictionaries would be useful in Wikidata. Regards. --Soufiyouns (talk) 14:16, 29 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Pocket Oxford German Dictionary: German-English (Q126938078) (URL: https://www.oxfordreference.com/display/10.1093/acref/9780191739521.001.0001/acref-9780191739521). --Soufiyouns (talk) 14:01, 29 June 2024 (UTC)[reply]

•  Comment: This is a complementary property to the reverse property proposal (Wikidata:Property proposal/Pocket Oxford German Dictionary: English-German ID) for the German-English bilingual pocket dictionary, and I think this pair of reverse dictionaries would be useful in Wikidata. Regards. --Soufiyouns (talk) 14:05, 29 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Pocket Oxford Italian Dictionary: English-Italian (Q126871296) (URL: https://www.oxfordreference.com/display/10.1093/acref/9780191739552.001.0001/acref-9780191739552). --Soufiyouns (talk) 13:05, 22 June 2024 (UTC)[reply]

•  Support Back ache (talk) 14:22, 22 June 2024 (UTC)[reply]
• That's enough with the English dictionaries, don't you think? (We could have more Italian dictionary properties, but Oxford may not be the best source for them.) Mahir256 (talk) 16:10, 26 June 2024 (UTC)[reply]
•  Comment: @Mahir256: This is a complementary property to the reverse property proposal (Wikidata:Property proposal/Pocket Oxford Italian Dictionary: Italian-English ID) for the Italian-English bilingual pocket dictionary, and I think this pair of reverse dictionaries would be useful in Wikidata. Regards. --Soufiyouns (talk) 13:34, 29 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control: Highly authoritative source in the Pocket Oxford Italian Dictionary: Italian-English (Q126937276) (URL: https://www.oxfordreference.com/display/10.1093/acref/9780191739569.001.0001/acref-9780191739569). --Soufiyouns (talk) 13:20, 29 June 2024 (UTC)[reply]

•  Comment: This is a complementary property to the reverse property proposal (Wikidata:Property proposal/Pocket Oxford Italian Dictionary: English-Italian ID) for the Italian-English bilingual pocket dictionary, and I think this pair of reverse dictionaries would be useful in Wikidata. Regards. --Soufiyouns (talk) 13:31, 29 June 2024 (UTC)[reply]

This is the most comprehensive list of Indian hamlets available, it will be very helpful in tracking all the rural habitations which are not full blown revenue/census villages. It also has a mapping to LGD local body code (P6425) making the whole Indian hamlet mapping tractable. RamSeraph (talk) 19:08, 19 May 2024 (UTC)[reply]

•  Oppose This is the same as MDWS place ID (P6335), as all three example values for that property are (up to the presence of leading zeros) also values for this one. Mahir256 (talk) 19:54, 19 May 2024 (UTC)[reply]

  @Mahir256 Can you give the source where these can be looked up.. I do suspect the JJM id is a successor to the MDWS place ID (P6335). I will retract this if this is actually the same RamSeraph (talk) 01:01, 20 May 2024 (UTC)[reply]

  • @RamSeraph: The third "source website for the property" link on P6335 (incidentally with the domain ejalshakti.gov.in) still resolves, if you want to browse that. Mahir256 (talk) 01:46, 20 May 2024 (UTC)[reply]

    @Mahir256 I did see the same domain, and that is the reason I added MDWS place ID (P6335) in the related property list and also the reason I think it is a successor id. The other clue was that the reports with MDWS place ID (P6335) stop at 2018 and the JJM ones start at 2019. 3 out of 1.6 million matching is not a confirmation that they are the same, but let's put this is on hold till we can actually confirm fully. One other reason I want to add JJM id is because they are mapped to LGD here - https://ejalshakti.gov.in/JJM/JJMReports/lgd_mapping/rpt_LGDMappedStatus.aspx RamSeraph (talk) 03:53, 20 May 2024 (UTC)[reply]

    One other thing.. can you confirm that the id in brackets next to the habitation name is the id to consider? RamSeraph (talk) 03:55, 20 May 2024 (UTC)[reply]

    Also, JJM data has been pulled and is available here(documentation) RamSeraph (talk) 04:33, 20 May 2024 (UTC)[reply]

    @Mahir256 The linked page for MDWS place ID (P6335) is broken for a lot of blocks, There are no ids even next to the habitation names for some states. I couldn't locate Cherukupalli (Q97489248) in the drop downs.. it would be helpful if you can show the source for the claim that the ids are the same. RamSeraph (talk) 07:08, 20 May 2024 (UTC)[reply]

    @RamSeraph: I'm not sure which bracketed numbers you are referring to, but the "S.No." that appears in the P6335 link is not the value of P6335; if you examine the HTML source for the drop-down boxes in that link (the <table class="SelectData"> element), each <option> element has a value attribute, which has been treated as the value for P6335 and which for Nangdala Tea Garden (Q60794317) and Uthukuli block (Q25553040)—to add two other random places to the three P6335 examples—match the values for this proposed property.

    Have you tried looking for some of the existing P6335 values in the link that you provided? There do seem to be issues now browsing the P6335 link (for whatever reason the list of administrative divisions in the drop-downs for the 2018 data doesn't actually correspond to what existed in that year)—in the case of Andhra Pradesh likely due to some reorganization of administrative divisions in the last six years—but while it may be disappointing that no P6335 values for within Andhra Pradesh was added to Wikidata, with respect to information from other states I also haven't seen yet any values where the value for P6335 is different from the value for this proposed property. Mahir256 (talk) 13:16, 20 May 2024 (UTC)[reply]

    I wasn't looking at the "S.No.", some of the habitations had a number in brackets - An example would be Appapuram village's listing of habitations. Can be reached via the following dropdown - "State: Andhra Pradesh -> District: Guntur -> Block: Kakumanu -> Panchayat: Appapuram -> Village: Appapuram". You will see two habitations listed there with names Appapuram(0709747009011500) and Chinakakumanu(0709747009021500). These are the numbers I was looking at. I highly suspect they were not the MDWS place ID (P6335)s of the habitations. I did look at the HTML source.. the ids in the <select> field don't extend till habitations, they stop at villages. So the MDWS place ID (P6335)s for habitations are no longer accesible.

    That brings us to what seems to be a major misunderstanding here, the current proposal is only for Habitation ids, not for census villages or any other administrative entities above them. In fact habitations are not administrative entities, they are just human settlements. The lowest administrative hierarchy is a Revenue village( which the British decided to use as census entities as well, you know, priorities :) ) or sometimes a Gram Panchayat( yes, a revenue village can have multiple gram panchayats ).

    Some of these habitation names are what people recognise as their village names. The 3 examples I gave are these kind of habitations, These couldn't be tracked down to revenue villages or gram panchayats. In the link added as source in this proposal going to the "B1: Basic Habitation Information" section you can locate these 3 entries by following the dropdowns as listed below.

    Cherukupalli (Q97489248) State: Andhra Pradesh, District: Bapatla, Block: Cherukupalli, Panchayat: ARUMBAKA, Village: ARUMBAKA

    Panatoor (Q19672794) State: Andhra Pradesh, District: Chittoor, Block: Gudipala, Panchayat: Gollamadugu Village:Bomma Samudram

    Kothaganesunipadu (Q6433970) State: Andhra Pradesh, District: Palnadu, Block: Machavaram, Panchayat: NAGESWARAPURAM THANDA, Village: Pillutla

    Now, coming to fact that the existing MDWS place ID (P6335)s are very similar to the newer JJM ids, these is more inline with what I was saying that the various JJM ids( for state, district, block, panchayat, village, habitations ) are successors of the original MDWS place ID (P6335).

    Are you suggesting that I add JJM habitation ids and call them MDWS place ID (P6335)? This is something I am ok with, We can add JJM id as an alternate name, but this might lose some of the subtlety that the id spaces have been separated in the newer identifiers and the source now calls them JJM ids, it might even lead to confusion, somebody needs to people to add additional zeros to avoid clashes across various entity types.

    Note: Looks like I got the id for Panatoor (Q19672794) wrong, I am going to correct the proposal, it is 31095 not 11912 RamSeraph (talk) 15:18, 20 May 2024 (UTC)[reply]

    @Mahir256 Forgot to ping. Also, adding one more thing. The newer JJM ids will definitely have ids which weren't in the original MDWS place ID (P6335). Digging these up would be easy. Look for any district formed after 2018. RamSeraph (talk) 15:30, 20 May 2024 (UTC)[reply]

    @Mahir256 What is the prescription here? Given that the MDWS place ID (P6335) values for habitations are no longer accesible at the source and the current proposal is only for habitations, I don't see how any of the arguments put forth in opposition still hold. Is this still an "oppose"? RamSeraph (talk) 19:16, 14 June 2024 (UTC)[reply]

•  Support, Considering that MDWS place ID (P6335) was also from the same department, JJM habitaion id is a successor. --Arjunaraoc (talk) 05:08, 30 May 2024 (UTC)[reply]

KANAL is a new museum dedicated to contemporary art currently under construction in Brussels. The museum's website already offers a wealth of information about the artists and artworks that will be showcased in its future exhibits. Including this external identifier could prove to be a valuable addition, providing further context and aiding in the dissemination of information about the museum's offerings.

See also wikidata:property proposal/Pending for approved items awaiting the deployment of currently unavailable datatypes

Already approved properties: list

Huge database of protected areas by the European Environmental Agency, with very complete pages about Natura 2000 sites. And it's in CC BY. --Yiyi .... (talk!) 07:26, 7 June 2024 (UTC)[reply]

• Daniel Mietchen Olea Haymillefolium TiagoLubiana
  Notified participants of WikiProject Ecology --Yiyi .... (talk!) 07:47, 7 June 2024 (UTC)[reply]
• The destination URL seems to offer the same information than Natura 2000 site ID (P3425) but more human friendly, which is great. Is this right? If so, I'm not sure to add an external reference which is conceptually identical to an existing property. I could think about changing the URL format at Natura 2000 site ID (P3425) instead but I'm not completely sure also. :-m I've just checked the Biodiversity entry links to the «official data» page generated by P3425 :-m —Ismael Olea (talk) 11:13, 7 June 2024 (UTC)[reply]
•  Comment Wow, beautiful website. I guess this is the case for at least third-party formatter URL (P3303) as identifiers are actually the same. I think there may be a case for a new property if (1) the database have IDs other than Natura 2000 or (2) the database selects only a subset of IDs or (3) the information recorded by both is actually different, no only shown differently. In the end, it is a more general problem of whether we want Wikidata to have links to good resources or host the different IDs. TiagoLubiana (talk) 13:04, 7 June 2024 (UTC)[reply]

  Yiyi, could you please clarify comments by Olea and TiagoLubiana Regards, ZI Jony ^(Talk) 07:41, 14 June 2024 (UTC)[reply]

•  Support Arpyia (talk) 10:26, 8 June 2024 (UTC)[reply]

Notified participants of WikiProject Authority control

Notified participants of WikiProject Biodiversity.

Widely used and well respected mycological resource. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:27, 18 June 2024 (UTC)[reply]

•  Support AdamSeattle (talk) 20:18, 18 June 2024 (UTC)[reply]

•  Support Ambrosia10 (talk) 20:26, 18 June 2024 (UTC)[reply]
• @Pigsonthewing, AdamSeattle, Ambrosia10:  Done as Index Fungorum person ID (P12856). Regards, ZI Jony ^(Talk) 06:07, 30 June 2024 (UTC)[reply]

There is currently a Plex media key (P11460) property that covers items in the Plex (Q7204887) media domain such as films and TV shows, however people are in a separate distinct key namespace. Another user on the Plex media key (P11460) property talk discussion suggested they would also be interested a property to cover people for completeness. Josh404 (talk) 21:30, 18 June 2024 (UTC)[reply]

 Support. Being the user mentioned by @Josh404, I can only be in favour of this request! --Wiccio (talk) 05:32, 19 June 2024 (UTC)[reply]

• @Josh404, Wiccio:  Done as Plex person key (P12854). Regards, ZI Jony ^(Talk) 05:52, 30 June 2024 (UTC)[reply]

This adds an external ID for podcast episode (Q61855877) shared by the Overcast (Q20707973) podcast app. Similar to Apple Podcasts episode ID (P10304) or Spotify show episode ID (P9882). Josh404 (talk) 21:32, 18 June 2024 (UTC)[reply]

Notified participants of WikiProject Italy highly authoritative source regarding the history of the University of Bologna. --Epìdosis 08:14, 23 June 2024 (UTC)[reply]

 Support -- Bargioni 🗣 08:16, 23 June 2024 (UTC)[reply]
 Support --Marcok (talk) 08:31, 23 June 2024 (UTC)[reply]
 Support. The oldest still active university, an immeasurable source of information. --Wiccio (talk) 08:51, 23 June 2024 (UTC)[reply]
 Support --Carlobia (talk) 09:20, 23 June 2024 (UTC)[reply]
 Support --Sentruper (talk) 10:35, 23 June 2024 (UTC)[reply]
 Support--Parma1983 (talk) 10:45, 23 June 2024 (UTC)[reply]
 Support--Patafisik (talk) 11:43, 23 June 2024 (UTC)[reply]
 Support--Camelia (talk) 12:21, 23 June 2024 (UTC)[reply]
 Support --FeltriaUrbsPicta (msg) 12:40, 23 June 2024 (UTC)[reply]
 Support --Fausta Samaritani (talk) 15:35, 27 June 2024 (UTC)[reply]

• @Epìdosis, Bargioni, Marcok, Wiccio, Carlobia, Sentruper: @Parma1983, Patafisik, Camelia.boban, FeltriaUrbsPicta, Fausta Samaritani:  Done as UNIBO professor ID (P12858). Regards, ZI Jony ^(Talk) 06:30, 30 June 2024 (UTC)[reply]

(Indiqueu aquí les vostres motivacions per a aquesta propietat, i signeu)

• At present, more than 700 Wikidata items use Mapes de patrimoni cultural (Q9028374) as reference or link to its records using described at URL (P973). Having a dedicated property would help to keep track of uploads and avoid duplicates.--Pere prlpz (talk) 10:22, 23 June 2024 (UTC)[reply]

•  Support--Medol (talk) 14:30, 23 June 2024 (UTC)[reply]
•  Support --KajenCAT (talk) 15:40, 23 June 2024 (UTC)[reply]
•  Support Herodotptlomeu (talk) 13:44, 24 June 2024 (UTC)[reply]
•  Support Interesting Id from a large and well documented database. --Amadalvarez (talk) 15:12, 24 June 2024 (UTC)[reply]
•  Support A dedicated property for «Mapes de patrimoni cultural» will streamline data management and prevent duplicates.--Castellbo (talk) 11:38, 29 June 2024 (UTC)[reply]
• @Pere prlpz, Medol, KajenCAT, Herodotptlomeu, Amadalvarez, Castellbo:  Done as Mapes de Patrimoni Cultural ID (P12860). Regards, ZI Jony ^(Talk) 06:49, 30 June 2024 (UTC)[reply]

Cet identifiant existe déjà pour les humains : FEI athlete ID (P3111), mais pas encore pour les chevaux. --Tsaag Valren (talk) 17:32, 23 June 2024 (UTC)[reply]

Notified participants of WikiProject Equines

Lojas com História ("Stores with History") is a program by the Municipal Counsel of Lisbon to document culturally important commercial buildings. This is a new project to use it as data for new entries.  – The preceding unsigned comment was added by JnpoJuwan (talk • contribs) at 07:51, June 25, 2024‎ (UTC).

• Vladimir Alexiev Jonathan Groß Andy Mabbett Jneubert Sic19 Wikidelo ArthurPSmith PKM Ettorerizza Fuzheado Daniel Mietchen Iwan.Aucamp Epìdosis Sotho Tal Ker Bargioni Carlobia Pablo Busatto Matlin Msuicat Uomovariabile Silva Selva 1-Byte Alessandra.Moi CamelCaseNick Songceci moz AhavaCohen Kolja21 RShigapov Jason.nlw MasterRus21thCentury Newt713 Pierre Tribhou Ahatd JordanTimothyJames Silviafanti Back ache AfricanLibrarian M.roszkowski Rhagfyr 沈澄心 MrBenjo S.v.Mering Hiperterminal (talk) מקף
  Notified participants of WikiProject Authority control. --JnpoJuwan (talk) 20:24, 26 June 2024 (UTC)[reply]
• Alexmar983 GoEThe Joao4669 Miguelmcorreia Waldir Ivanhercaz Sanjorgepinho CatarinaMReis DarwIn Cratophonos Mind Booster Noori MariaCurista JnpoJuwan
  Notified participants of WikiProject Portugal. --JnpoJuwan (talk) 20:24, 26 June 2024 (UTC)[reply]

One of the properties for RGALI ID (P6752) replacement. Old links with universal IDs are broken, and new links are separated by entity type. See also Wikidata:Property proposal/RGALI organization ID.  – The preceding unsigned comment was added by Putnik (talk • contribs) at 18:32, 25 June 2024‎ (UTC).[reply]

• Vladimir Alexiev Jonathan Groß Andy Mabbett Jneubert Sic19 Wikidelo ArthurPSmith PKM Ettorerizza Fuzheado Daniel Mietchen Iwan.Aucamp Epìdosis Sotho Tal Ker Bargioni Carlobia Pablo Busatto Matlin Msuicat Uomovariabile Silva Selva 1-Byte Alessandra.Moi CamelCaseNick Songceci moz AhavaCohen Kolja21 RShigapov Jason.nlw MasterRus21thCentury Newt713 Pierre Tribhou Ahatd JordanTimothyJames Silviafanti Back ache AfricanLibrarian M.roszkowski Rhagfyr 沈澄心 MrBenjo S.v.Mering Hiperterminal (talk) מקף
  Notified participants of WikiProject Authority control. —putnik 18:46, 25 June 2024 (UTC)[reply]
• MasterRus21thCentury (talk) Infovarius (talk) MaksOttoVonStirlitz (talk) evs (talk) putnik (talk) Niklitov (talk) Redboston (talk) Arbnos (talk) Erokhin (talk) Андрей Романенко (talk) AndyVolykhov (talk) Vladimir Solovjev (talk) Stolbovsky (talk) Brateevsky (talk) Podbrushkin (talk)
  Notified participants of WikiProject Russia. —putnik 18:46, 25 June 2024 (UTC)[reply]
•  Support --MasterRus21thCentury (talk) 20:31, 25 June 2024 (UTC)[reply]
•  Support Podbrushkin (talk) 10:11, 26 June 2024 (UTC)[reply]
•  Support evs 💬 15:24, 28 June 2024 (UTC)[reply]

One of the properties for RGALI ID (P6752) replacement. Old links with universal IDs are broken, and new links are separated by entity type. See also Wikidata:Property proposal/RGALI person ID.  – The preceding unsigned comment was added by Putnik (talk • contribs) at 18:43, 25 June 2024‎ (UTC).[reply]

• Vladimir Alexiev Jonathan Groß Andy Mabbett Jneubert Sic19 Wikidelo ArthurPSmith PKM Ettorerizza Fuzheado Daniel Mietchen Iwan.Aucamp Epìdosis Sotho Tal Ker Bargioni Carlobia Pablo Busatto Matlin Msuicat Uomovariabile Silva Selva 1-Byte Alessandra.Moi CamelCaseNick Songceci moz AhavaCohen Kolja21 RShigapov Jason.nlw MasterRus21thCentury Newt713 Pierre Tribhou Ahatd JordanTimothyJames Silviafanti Back ache AfricanLibrarian M.roszkowski Rhagfyr 沈澄心 MrBenjo S.v.Mering Hiperterminal (talk) מקף
  Notified participants of WikiProject Authority control. —putnik 18:46, 25 June 2024 (UTC)[reply]
• MasterRus21thCentury (talk) Infovarius (talk) MaksOttoVonStirlitz (talk) evs (talk) putnik (talk) Niklitov (talk) Redboston (talk) Arbnos (talk) Erokhin (talk) Андрей Романенко (talk) AndyVolykhov (talk) Vladimir Solovjev (talk) Stolbovsky (talk) Brateevsky (talk) Podbrushkin (talk)
  Notified participants of WikiProject Russia. —putnik 18:46, 25 June 2024 (UTC)[reply]
•  Support --MasterRus21thCentury (talk) 20:32, 25 June 2024 (UTC)[reply]
•  Support --Newt713 (talk) 07:43, 26 June 2024 (UTC)[reply]
•  Support Podbrushkin (talk) 10:09, 26 June 2024 (UTC)[reply]
•  Support evs 💬 15:24, 28 June 2024 (UTC)[reply]

Notified participants of WikiProject Ancient Greece LAGL Catalog has the main aim of providing permanent identifiers for authors (and works: I think I will propose soon a property also for works) in Ancient Greek and Latin, especially for the ones whose works have not been preserved, or are fragmentary, and for this reason aren't well mapped by existing databases, which mainly deal with authors of fully or mostly preserved works. In particular, as of now the database identifies with new IDs nearly 300 ancient Greek authors (and I think also Latin authors will be similarly added in the future) and all the authors are already linked to Wikidata, so the import of all the IDs will be very easy and will help building a reliable framework for referring univocally to ancient Greek fragmentary authors. The database also provides a very useful function, i.e. giving an easy link to the passage(s) of ancient source(s) mentioning each author. --Epìdosis 20:19, 27 June 2024 (UTC)[reply]

•  Comment Some of the authors on LAGL have a TLG prefix and I'm guessing that the addition of Latin authors and works will need the inclusion of the greekLit/latinLit prefix as well. Also, shall this property be approved, will we still have a use for Digital Athenaeus Catalog author ID (P12600)? If we are to use CTS URN anyway it would probably be a good idea to have a single property for that. --Jahl de Vautban (talk) 21:22, 27 June 2024 (UTC)[reply]

  @Jahl de Vautban: you are perfectly right; I have just spoken with @Digitalphilologist: and she said that the property for Digital Athenaeus (P12600) is obsolete and she has just asked for its deletion; in fact all the IDs of Digital Athenaeus are now a subset of the IDs of the LAGL Catalog. I also edited the examples above to include all the possible types of IDs. --Epìdosis 15:30, 29 June 2024 (UTC)[reply]

  @Epìdosis, Digitalphilologist: it looks better now, but in my understanding CTS URN are universal and thus not limited to LAGL; the last two examples at least resolve in Perseus as well [1] [2] and the last one in Scaife [3]. I'm not really understanding the technical know-how, but I think we should leverage that and go right away with a more universal approache, that would consist in 1) a CTS URN author/work property, perhaps two if we are to distinguish between them and 2) a CTS URN resolver property, to store the base URL to which you could append the author/work property and that would go on the project Qid. In my opinion this would allow for a much wider use. --Jahl de Vautban (talk) 17:01, 29 June 2024 (UTC)[reply]

  @Jahl de Vautban: yes, the issue of CTS URNs is fairly complex, you are perfectly right in raising it! So, firstly I now created an embrional CTS URN (Q126941791): unique identifier for authors and literary works for initial reference. The use of CTS URNs originated from the studies about Ancient Greek and Latin literature, although, being a more general specification (https://cite-architecture.github.io/ctsurn_spec/), it could expand (and sometimes has expanded) beyond it. The concept of CTS URN, being a specification, is not specifically connected to a single database, but each database, using the rules of the specification CTS URN, can construct its own CTS URNs; the rule is urn:cts:CTSNAMESPACE:WORK:PASSAGE, of course we are only interested in the part urn:cts:CTSNAMESPACE:WORK; although the specification doesn't say it, since in Perseus CTS URNs WORK is obtained through AUTHORID.WORKID, in fact we can consider (broadly speaking) urn:cts:CTSNAMESPACE:AUTHORID as a CTS URN for authors.

  CTS URNs are not unique, even inside the same database: e.g. considering the most important collection of CTS URNs for ancient Greek and Latin texts, the one offered by Perseus Catalog, we find e.g. both https://catalog.perseus.org/catalog/urn:cts:latinLit:phi0978 and https://catalog.perseus.org/catalog/urn:cts:latinLit:stoa0232 for Pliny the Elder (Q82778): 1st-century Roman military commander and writer; this is because the same author has different numbers in different collections and CTS URNs are not unique IDs strictly speaking, but only unique for one collection of texts (e.g. Stoa vs PHI). The LAGL project (of which of course @Digitalphilologist: knows much more than me) has chosen to use CTS URNs relating on TLG for Ancient Greek authors (so the same as Perseus) and CTS URNs relating to PHI whenever possible or otherwise to Stoa for Latin authors (so the same as Perseus, but always unique unlike Perseus); however, for Greek authors absent in TLG and for Latin authors absent in PHI and in Stoa, it has chosen to create new CTS URNS, relating to LAGL itself. So yes, the issue is very much complex. I try to articulate the following proposal, as follows:

  1. since CTS URN is a specification that can be used to produce different but equally valid IDs (insofar as the follow the rules of the CTS URN specification), I think having one single property "CTS URN" is not feasible, mainly because some IDs would only work with a certain formatter URL (e.g. linking to Perseus Catalog) and some others with a different formatter URL (e.g. linking to LAGL Catalog)
  2. I would generally distinguish properties for CTS URNs for authors and for works, mainly because having different properties allows to set more precise format constraint (Q21502404) and subject type constraint (Q21503250) for each
  3. given these two premises, I think we could be interested in creating a total of 4 properties: 1) Perseus Catalog CTS URN for authors 2) Perseus Catalog CTS URN for works 3) LAGL CTS URN for authors 4) LAGL CTS URN for works. Since works in LAGL are still experimental (whilst authors in LAGL are now stable), I would wait for number 4; I would keep this proposal for number 3 (I have now put "urn:cts:" in the ID instead of in the formatter URL); finally, I can propose separately numbers 1 and 2 (we can easily massive import values of number 1 on the basis of our Perseus author ID (P7041) values).

  Do you agree with my proposal? Of course we can discuss further improvements! --Epìdosis 21:00, 29 June 2024 (UTC)[reply]

•  Support I have just spoken with @Epìdosis: and I confirm that I'm asking the deletion of the Digital Athenaeus property. The LAGL Catalog will include the IDs of the Digital Athenaeus and will also include Latin authors. This is the reason why the prefix before the number is important (e.g., lagl0003) is important. Thank you.--Digitalphilologist (talk) 15:35, 29 June 2024 (UTC)[reply]

Claims to be the biggest Arabic Database for profiles of people. It has 200K entries. I've personally run into this database a lot when researching famous arabic people. Quick-ease2020 (talk) 19:04, 29 June 2024 (UTC)[reply]