Wikidata:Property proposal/Authority control - Wikidata


Authority file

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

  Notified participants of WikiProject Russia reliable source regarding Siberia; 1579 values already present in Wikidata as qualifier URL (P2699) of described by source (P1343)Historical Encyclopedia of Siberia (Q113559915) (query: https://w.wiki/BBup) thanks to the work of @Podbrushkin:, their conversion through QuickStatements will be very easy. --Epìdosis 09:16, 14 September 2024 (UTC)[reply]

National Company Register of Finland. OpenCorporates uses the same codes so it should be easy for someone with a bot to migrate those to the new property.  – The preceding unsigned comment was added by Sabelöga (talk • contribs) at 22:20, 25 August 2024 (UTC).[reply]

  Notified participants of WikiProject Finland

lww.com (Q130266158) is the official website of the academic publisher Lippincott Williams & Wilkins (Q2407351), containing information about scientific publications. There should be more than 300 IDs for journals, at least for what concerns the ones currently covered on Wikidata. --Horcrux (talk) 13:44, 9 September 2024 (UTC)[reply]

BioMed Central journal ID

edit

biomedcentral.com (Q130266220) is the official website of the academic publisher BioMed Central (Q463494), containing information about scientific publications. There should be more than 370 IDs for journals, at least for what concerns the ones currently covered on Wikidata. --Horcrux (talk) 13:44, 9 September 2024 (UTC)[reply]

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

Currently, many conlangs (constructed languages) that don't have official ISO 639-3 codes have an ISO 639-3 code (P220) value listed anyway, for a code issued by the ConLang Code Registry; they generally take the format Black Speech (Q686210)ISO 639-3 code (P220)qbsissued by (P2378)ConLang Code Registry (Q107713633). The problem is that this is wrong: the ISO 639-3 standard defines the codes qaa-qtz as "reserved for private use", which means that anyone can use them for any purpose, and still be compliant with the standard. The fact that the ConLang Code Registry has issued codes in this range does not mean that these conlangs have actually received ISO 639-3 codes, though; it just means that a completely separate organisation has decided to issue codes which just-so-happen to be in ISO 639-3's private use range.

This is obviously intentional, as it allows them to be used as language codes without conflicting with the official ISO standard, but that doesn't mean we should have statements which claim they're actually part of the standard. Simply saying that the code is "issued by the ConLang Code Registry" doesn't make it clear that the ConLang Code Registry is not entitled to issue ISO 639-3 codes, and therefore obscures the fact that the code isn't actually part of the standard in the first place (i.e. that the statement is wrong). Outside of conlang communities, these codes see almost no use, and they may conflict other privately-issued codes used in other communities.

To get around the issue, I'd like to propose a separate property for the ConLang Code Registry, so that these codes can be listed without polluting the data for those who only want information on official ISO 639-3 codes.  – The preceding unsigned comment was added by Theknightwho (talk • contribs) at 12:47, August 16, 2024‎ (UTC).

  •   Support This makes sense to me. Are there really 255 of these? ArthurPSmith (talk) 19:24, 16 August 2024 (UTC)[reply]
    @ArthurPSmith Yes - 252 active codes and 3 retired ones according to https://www.kreativekorp.com/clcr/. There are 520 codes in the private use range (qaa-qtz), which is the theoretical maximum, and growth is quite uneven, with some years seeing very few codes added (2 added in 2021), while others see many (32 added in 2023). Codes are retired if they're replaced by genuine ISO 639-3 codes. Theknightwho (talk) 21:18, 16 August 2024 (UTC)[reply]
  •   Support --Lewis Hulbert (talk) 11:16, 19 August 2024 (UTC)[reply]
  •   Oppose I don't think this would be a good idea.
    It's not a coincidence that the ConLang Code Registry (CLCR) codes are in ISO 639-3's private-use range, the whole point is that they are private-use ISO 639-3 codes for use as ISO 639-3 codes.
    ISO 639-3 provides the set of private-use codes for people to use how they want, which means that users assign their own meanings. It's true that other places may assign conflicting meanings, but that's why those statements all have a qualifier saying who gives it that meaning. Conflicts shouldn't be a problem either, we can use constraints like single-best-value constraint (Q52060874) and/or add separator (P4155) to the constraint.
    The existing statements shouldn't pollute the data if you're using it correctly. The items with private-use codes also have a no value statement set to preferred rank to indicate that they have no official code, and if you're looking at all statements, you need to take ranks and qualifiers into account for the data to be meaningful anyway.
    The real issue here is: How should we model usage of private-use codes? This isn't limited to CLCR or even ISO 639-3 (e.g. XK is widely used as the ISO 3166-1 code for Kosovo, Qaag is used by Unicode and CLDR as the ISO 15924 code for Zawgyi, U+F8D0 is the Unicode codepoint normally used for the Klingon letter "a"), so I don't think it makes sense to have a property specifically for CLCR's private-use ISO 639-3 codes. We should have a model we can apply to private-use codes in general instead.
    - Nikki (talk) 09:23, 28 August 2024 (UTC)[reply]
    @Nikki These are not ISO 639 codes, though - these are codes assigned by another body which have been intentionally designed to match up with ISO 639's private use range. It's not a question of qualifying the codes or setting no value as a preferred rank - it's the fact that it is factually wrong to say that they are ISO 639 codes at all, and they shouldn't be listed there at all. Theknightwho (talk) 22:09, 5 September 2024 (UTC)[reply]
    @Nikki, any changes in your opinion based on the response? Regards, ZI Jony (Talk) 18:25, 16 September 2024 (UTC)[reply]

This is a restart of WIPO Lex ID (P12720), which I proposed in Wikidata:Property_proposal/case_number_(mainland_China), but the community finally defined the property as WIPO Lex ID, since all examples (court judgements/decisions) I introduced in the proposal were from the WIPO website. :D
Today when I wanted to enter data for this property, I find it completely changed, but reasonable.

I'm re-proposing the China property here.
For any formal judgement from a court (or eligible authority) in mainland China, there's a unique case id (案号, lit. case number) assigned to that legal proceeding. See third line (right-aligned) of Page 1 of a formal court decision. This id is almost the same as U. S. Supreme Court docket number (P7063).

There's a definitive regulation of case ids published in 2015 by China's supreme court. An unofficial English translation is available here if you're interested.

Case ids before 2015 (start of nation-wide digitization) can't be expected to follow a fixed style or format. So I would like to allow this property as a free-form text field, rather than a very strict one. --XsLiDian (talk) 14:04, 26 August 2024 (UTC)[reply]

References

  1. ↑ "最高人民法院工作报告". 全国各级法院收案4557.4万件，结案4526.8万件，同比分别增长15.6%、13.4%。 For the year of 2023: "45574k new cases; 45268k newly-resolved cases."

{{Basketball properties}}. 290524, 290524, ID is stable.--HanTsî (talk) 21:38, 16 September 2024 (UTC) （在这里填写您添加这个属性的动机并签名）[reply]

{{Basketball properties}}--HanTsî (talk) 06:21, 17 September 2024 (UTC) （在这里填写您添加这个属性的动机并签名）[reply]

I was approached by them to help sync their data with Wikidata, and I think we should support this! They already have plenty of entries associated with Wikidata/Wikipedia and also GND/VIAF/etc on their side. Mix'n'Match already has half of their IDs matched to Wikidata items.

  Support. URIs, RDF and everything, of course they should have an external identifier! Abbe98 (talk) 10:38, 20 September 2024 (UTC)[reply]

  Support, obviously. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 21 September 2024 (UTC)[reply]

  Support DerHexer (talk) 09:18, 23 September 2024 (UTC)[reply]

  Support very useful, especially as the institution is part of a larger body that might be inspired to follow suit Awinkler3 (talk) 09:36, 23 September 2024 (UTC)[reply]

  Support. The Münzkabinett is not only one of the most important and alongside London, Paris, Wien and St. Petersburg one of the biggest numismatic collections with a long history in the world, this museum/collection is also a great friend of the Wikiverse and tries to connect in a lot of ways. We should support this too in all possible ways. One way is to create this very usefull property. 22.000 objects in the moment are just the beginning. The collection of the Münzkabinett incloudes a half million objects. So this number will increase ongoing, due to there will be worked on regular. And in a second step, there will be probably the numid notwork with other collections, mainly in Germany, but also Austria, Switzerland and Greece, and their online catalogue (one part of this catalogue is the smb-ikmk, of which we're talking here). -- Marcus Cyron (talk) 16:50, 23 September 2024 (UTC)[reply]

  Support, because of the reasons already mentioned. --DerMaxdorfer (talk) 19:31, 23 September 2024 (UTC)[reply]

  Support --Kdkeller (talk) 18:50, 27 September 2024 (UTC)[reply]

  Neutral I'm not really in favour of creating such all-in-one properties that mix several separate IDs and basically store just a slug (Q99601940) that might change anytime. Wikidata has generally moved away from that approach. Also makes it harder to set up constraints and find mismatches. But it seems they have 19 categories in total, several of which would probably be too small to warrant their own property. Not optimal either way. --2A02:810B:5C0:1F84:2836:F2FD:EE77:CF71 09:02, 30 September 2024 (UTC)[reply]

I agree in principal, however, as you said, it is not really practical to split it in this case. GND ID (P227) is a similar "mess", but at least here, one can tell the category by the ID prefix if need be. --Magnus Manske (talk) 09:53, 2 October 2024 (UTC)[reply]

beniabbandonati ID for a building in Italy (detailed sheet)

edit

beniabbandonati ID for a building in Italy (summary sheet)

edit

  Notified participants of WikiProject Italy this identifier is for abandoned buildings registered by the Italian Ministry of Culture in the database beniabbandonati.cultura.gov.it. I propose two identifiers for this database: the first one is for detailed sheets, human readable; the second one is for summary sheets, machine readable. --Yiyi .... (talk!) 11:26, 23 September 2024 (UTC)[reply]

The Czech Digital Library is the Czech national gateway to all digitalized objects. Skim (talk) 16:01, 25 September 2024 (UTC)[reply]

  Notified participants of WikiProject Czech Republic Skim (talk) 16:02, 25 September 2024 (UTC)[reply]

I have more information. Sorry fo delay. I needed to verify it. ČDK collects data from various Kramerius, but not all of them in the country. It takes the UUID from the digital library that published the document. In case the same document is in multiple libraries, it is possible to select which one I want to see in the ČDK interface (drop down box with digital library selection). UUID is from library the system grabbed the data first. The ČDK itself does not assign any UUIDs. So the UUIDs in the local Kramerium and the ČDK are mostly the same, they differ in the URL. One time the URL goes to the local Kramerius, the other time to the ČDK. So those local UUIDs cannot be considered duplicates. So the UUID in the ČDK is not unique. It always occurs in at least one Kramerium as well. Steam Flow (talk) 06:28, 4 October 2024 (UTC)[reply]

The Western Australian Biographical Index (Q130366635) (WABI) was compiled in the 1970s by Rica Erickson (Q4357043) and many other people, to build a database of people relating to Western Australia in the 19th Century (up to 1914). It has been transcribed and is published by the State Library of Western Australia (Q7603408) under a CC-BY license. The Dictionary of Western Australians (Q5273978) and Bicentennial Dictionary of Western Australians (Q115122719) both come from the work of the Index (they're not open licensed).

Although lots of the entries will not be matched to Wikidata items, a great number will and the cards often contain useful information about the people.

This property will also be useful in references, where knowledge is extracted from the cards (but no item created for the primary person).

There are 421 duplicate IDs in this dataset. These can be resolved to their correct contents by looking at the scans (which are addressed by filename and, at least as far as I can see so far, are unique; this may mean that some records are not backed by scans, or that some scans do not have records to match).

—Sam Wilson 11:58, 26 September 2024 (UTC)[reply]

The Cihai is a large-scale dictionary and encyclopedia of Standard Mandarin Chinese. Note there are multiple types of IDs - this one is for encyclopedia entries; there are another one for dictionary entries (Wikidata:Property proposal/Cihai dictionary entry ID).--GZWDer (talk) 17:48, 28 September 2024 (UTC)[reply]

The Cihai is a large-scale dictionary and encyclopedia of Standard Mandarin Chinese. Note there are multiple types of IDs - this one is for dictionary entries; there are another one for encyclopedia entries (Wikidata:Property proposal/Cihai encyclopedia entry ID).--GZWDer (talk) 17:48, 28 September 2024 (UTC)[reply]

identifiant CIRDOC d'une publication (fr) – (Please translate this into English.)

edit

  Notified participants of WikiProject France. Maxime 15:46, 1 October 2024 (UTC)[reply]