Property talk:P227
Documentation
identifier from an international authority file of names, subjects, and organizations (please don't use type n = name, disambiguation) - Deutsche Nationalbibliothek
The Integrated Authority File (Q36578) (GND) is managed by the German National Library in cooperation with various library networks in German-speaking Europe and other partners.
Allowed qualifiers
Wikidata qualifier (Q15720608) | entity (Q35120) | Example |
---|---|---|
subject named as (P1810) | person (Q215627) | Naguib Mahfouz (Q7176): Maḥfūẓ, Naǧīb |
subject named as (P1810) | geographical feature (Q618123) | Universe (Q1): Weltall / Kosmos <Begriff> |
alternative name (P4970) | person (Q215627) | Édith Piaf (Q1631): Gassion, Edith G. |
start time (P580) | geographical feature (Q618123) | Dnipro (Q48256): subject named as (P1810): Jekaterinoslaw (1776) |
end time (P582) | corporate body (Q106668099) | Leipzig University (Q154804): subject named as (P1810): Karl-Marx-Universität Leipzig (1991) |
point in time (P585) | event (Q1656682) | Chaos Communication Congress (Q516804): 2005 |
object has role (P3831) | person (Q215627) | Mark Twain (Q7245): subject named as (P1810): Twain, Mark + object has role (P3831): pseudonym (P742) |
object has role (P3831) | corporate body (Q106668099); more precise: museum (Q33506) |
Panorama Mesdag (Q1738414): museum in the Hague |
object has role (P3831) | work (Q386724) | Q110996824: no description |
object has role (P3831) | geographical feature (Q618123) | Tomb of the Scipios (Q1540716): subject named as (P1810): Rom / Scipionen-Grab + object has role (P3831): cross-reference (Q1302249) |
object has role (P3831) | term (Q1969448) / topical term (Q115439461) | book publisher (Q1320047): subject named as (P1810): Verlag + object has role (P3831): quasi-synonym (Q2122467) |
applies to part (P518) | geographical feature (Q618123) corporate body (Q106668099) |
Peace Palace (Q834448): architectural structure Peace Palace (Q834448): organization |
location (P276) | corporate body (Q106668099) | Academic Press (Q2076913): New York / San Diego |
sex or gender (P21) | term (Q1969448) / topical term (Q115439461) | pianist (Q486748): male or of unspecified gender / female |
scope note (P9570) | work (Q386724) | Xenien (Q523255): Goethe / Schiller |
scope note (P9570) | Ukrainian literature (Q1276062) | Benutze Kombination: Ukrainisch AND Literatur + object has role (P3831): cross-reference (Q1302249) |
scope note (P9570) | creator of the GND (for help with indentification) |
Karl-Heinz Schulze (Q113454903): Datensatz angelegt von DFF - Deutsches Filminstitut & Filmmuseum / filmportal.de [DE-Wi17FP] |
identifier shared with (P4070) | term (Q1969448) / topical term (Q115439461) | Orient (Q205653) ≈ Q1947733 |
reason for deprecated rank (P2241) | refers to different subject (Q28091153) unconfirmed (Q28831311) redirect (Q45403344) | |
reason for deprecated rank (P2241) | (rare case where GND was accidentally reused) | Alfred Daiber (Q114087670): replacement (Q23009439) → Alfred Daiber (Q15782350) |
reason for deprecated rank (P2241) | (should be replace with valid GND) | undifferentiated identifier value (Q68648103) |
intended subject of deprecated statement (P8327) | In addition to refers to different subject (Q28091153) |
See: property constraint (P2302) = P227#P2302 (P227#P2302)
Sources and abbreviations
Gadget
- To import data from the authority file you can use the gadget GND reveal. You only have to add
- importScript( 'User:Magnus Manske/gnd reveal.js' )
- to your page User:…/common.js.
Notes
- Databases to look up the GND: Online-GND (English; German) and DNB-Portal.
- For subject headings the GND uses quasi-synonym (Q2122467) what is useful for libraries but contradicts the concept of Wikidata:
- If there are duplicates: Please mark preferred GND with "preferred" rank (see Help:Ranking).
- Example Supreme Court of the Netherlands (Q133765): Q133765#P227 (former GKD = winner since it's an organisation)
- Lists of possible duplicates: Wikidata:Database reports/Identical GND ID and Property talk:P227/Duplicates
- Error reports
- Error report on German Wikipedia: de:WP:GND/F
- List of undifferentiated identifier value (Q68648103): Wikidata:WikiProject Authority control/Tn
- If a conflation is too complicated to be solved immediately: Property talk:P227/Conflation
- Wikidata:WikiProject Authority control/Error reporting procedures
- Recording companies and music publishers have yet not been imported into the GND (de:Hilfe:GND#Körperschaften). Instead of GND you can use DNB edition ID (P1292).
Known VIAF/GND problems
VIAF is helpful but also often incorrect, outdated, and is mixing two identifier systems that in some cases produce dead links.
- Johannes Fabian (Q15641418), VIAF 91414487 merged in January 2014 three GNDs, only one was correct:
- VIAF changes numbers with dashes: Instituto Brasileiro de Geografia e Estatística (Q268072).
- Same name + same year of birth = different person
- In some cases VIAF merges two persons because only one of them has a GND
- Please use: GND = "no value" (for the person without a GND) [1]
- For items often confused use: different from (P1889)
- For unknown reasons VIAF is not importing all GND ids
- Samuel Ramos (Q7412445) = GND 1022446479 (created 16-05-12)
- June 2015: 3 years later the GND id still not harvested by VIAF
- DNB and VIAF have been made aware of the problem, there might have been a harvesting glitch during the first weeks of the GND going live in April 2012: GND records which never have been touched since then are still unknown to VIAF (as an estimate about 15.000 GND records for persons created in early summer 2012 are not represented in VIAF). [7. Jun. 2015 Gymel]
- Update: GND 1022446479 added to VIAF:59099151 on 2015-07-12.
- In some cases VIAF clusters get deleted instead of merged
- Åke Blomström (Q270863): VIAF 228866914; taken care by KrBot
- In rare cases VIAF clusters are reused for a different item
- William of Ockham (Q43936): VIAF:41835567 in 2015
- Lorenzo Guglielmo Traversagni (Q18674108): VIAF:41835567 in 2016
- William of Ockham (Q43936): VIAF:262145669298005170004 (created 2016-02-28)
- Drew Fudenberg (Q1258707): till 2016-09-25 VIAF:59183378 (now: "First National Bank of Lynn")
- William of Ockham (Q43936): VIAF:41835567 in 2015
- In the case a conflated VIAF cluster was used for creating an item, see Help:Conflation of two people (Wikidata:VIAF/cluster)
|
(1[0123]?\d{7}[0-9X]|[47]\d{6}-\d|[1-9]\d{0,7}-[0-9X]|3\d{7}[0-9X])
”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P227#Conflicts with P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P227#single best value, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P227#Unique value, SPARQL (every item), SPARQL (by value)
List of violations of this constraint: Database reports/Constraint violations/P227#allowed qualifiers, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P227#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P227#Entity types
List of violations of this constraint: Database reports/Constraint violations/P227#Label in 'de' language, search, SPARQL
For Persons, see de:Wikipedia:GND/Fehlermeldung. Hints for other types at User:Jneubert/GND_errors
Error type | Item(s) affected | Description/Duplicates | Exception | Reported | Resolved (also unpublished) | Resolved and published | Wikidata updated |
---|
This property is being used by:
Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
|
GND ID exists, type is human, GND ID contains - (Help)
Violations query:
SELECT ?item ?gndid WHERE { ?item wdt:P227 ?gndid; wdt:P31 wd:Q5. FILTER(REGEX(STR(?gndid), "-")) . }
List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should not have GND ID containing -
GND ID exists, type is human, sex missing (Help)
Violations query:
SELECT ?item ?gndid WHERE { ?item wdtn:P227 ?gndid; wdt:P31 wd:Q5 . MINUS { ?item wdt:P21 [] } } LIMIT 1000
List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should have sex
GND ID exists, type is human, VIAF missing (Help)
Violations query:
SELECT ?item ?gndid WHERE { ?item wdtn:P227 ?gndid; wdt:P31 wd:Q5 . MINUS { ?item wdt:P214 [] } } LIMIT 1000
List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should have VIAF
GND ID exists, type is human, is instance of a subclass of human (Help)
Violations query:
SELECT ?item ?gndid WHERE { ?item wdt:P31/wdt:P279+ wd:Q5 . ?item wdt:P31 ?type . ?item wdtn:P227 ?gndid . }
List of this constraint violations: Database reports/Complex constraint violations/P227#GND ID - type human should not be instance of a subclass of human
Discussion[edit]
Archives | |||
---|---|---|---|
|
Second half of 2021[edit]
@Emu, Kolja21: The second half of 2021 is starting, let's make a new point of the situation for GND and DtBio. I just add here the first points:
- numbers: as of now 1'252'200 items having P227 as main statement and 627'074 items having P7902 as main statement
- backlog of 2020 import: still 1138 items from 2020 import having the same VIAF as another item (https://w.wiki/3VzL)
- backlog of 30/6/2021 import: 4224 items having substantially no data (https://w.wiki/3ZrH), @Bargioni: has accepted enriching them from GND in the next weeks
I am not opposed in principle to new imports, but I think it is better to delay their discussion after cleaning the backlog from 2020 import. If you have any idea about the current situation, problems to be solved and perspectives for the next months, we can discuss them here with the greatest pleasure for us all! Good evening, --Epìdosis 18:49, 30 June 2021 (UTC)
- No. 3: Thanks @Bargioni. Importing data from GND will bring us a great step forward. No. 2 is tricky since VIAF clusters are unstable. Same problem with BBLD (Property talk:P2580). The blocked user seems to be the same who has access to Baltisches biografisches Lexikon digital (Q18616550). He is doing mainly copy & paste edits:
- BBLD: https://bbld.de/GND1228837937 with sparse information → (source for) http://d-nb.info/gnd/1228837937 (created March 2021 by Baltische Historische Kommission e.V. [DE-2813]) → (source for) Q107371295.
- The BBLD IDs have changed two or three times (own IDs, tests with ISNI, now mainly GND). We should keep an eye on these items. --Kolja21 (talk) 19:19, 30 June 2021 (UTC)
- About the backlog: Items like Ferenc Karacs (Q1104400) [2] and Marko Martinović (Q4282609) [3] are imports from Biographisches Lexikon des Kaiserthums Oesterreich (Q665807). Plus there are thousands Mathematics Genealogy Project ID (P549) imports with information about an university degree. These items have to be further individualized and merged if the person is known in Wikipedia. Those who did their doctorate in Germany usually have a GND. --Kolja21 (talk) 20:00, 30 June 2021 (UTC)
backlog of 30/6/2021 import: The new BBLD imports[edit]
- @Bargioni: Enriching from GND will probably only take us so far. Luckily, many items seem to be based on Erik Amburger database ID (P6878) data. We could consider importing the corresponding IDs and some basic data for identification. That would probably be pretty easy with a bot or OpenRefine. Do you want to look into it or should I have a look? --Emu (talk) 21:16, 30 June 2021 (UTC)
- Looking at it again: The blocked user deleted these identifiers for some reason. --Emu (talk) 21:24, 30 June 2021 (UTC)
- Unbelievable: I've checked and undid the first edit. I only can guess the reason: Since P2580 (P2580) and Template:BBLD (Q23265105) could not prevail (because of the chaos he created in German Wikipedia and BBLD itself) other sources than "his" BBLD had to be deleted. --Kolja21 (talk) 23:31, 30 June 2021 (UTC)
- @Kolja21, Emu: Enrichment on the basis of GND (VIAF ID (P214), date of birth (P569), date of death (P570)) running today. Regarding the https://quickstatements.toolforge.org/#/batch/57969, you can check some cases and if all the IDs seem correct I can undo this batch, restoring all the IDs. --Epìdosis 08:59, 1 July 2021 (UTC)
- Quite a lot of their batches should be undo-able via editgroups, in case this is the chosen path here. —MisterSynergy (talk) 10:08, 1 July 2021 (UTC)
- @Epìdosis: Yes, please undo batch/57969. Amburger database is the original source containing more information.[4] --Kolja21 (talk) 15:21, 1 July 2021 (UTC)
- Info Claim to omnipotence: 1. Copy infos from a quotable source like Erik Amburger database (Q64584900) and less reliable sources like GenWiki (Q650669) to Baltisches biografisches Lexikon digital (Q18616550) (BBLD). 2. Create an P2580 (P2580) ID. 3. Create an Integrated Authority File (Q36578) GND ID (with BBLD as only source given). 4. GND will be imported by Deutsche Biographie (Q1202222) (DtBio) with a link to BBLD (example). 5. Create an item on Wikidata. 6. Delete the original source if it is mentioned on WD. - The last step is vandalism, the other steps are questionable because the source is veiled. It would be better to create a GND or an item based on the original source. --Kolja21 (talk) 15:54, 1 July 2021 (UTC)
- Example for BBLD IP activities in German WP: de:Diskussion:Alexander von Bock#BBLD - Baltisches biografisches Lexikon digital. In 2019 he created BBLD IDs like "Bock-Alexander-Friedrich-v.-1829-1895" adding a statement that the IDs might change ("falls sich die BBLD ID ändert ..."). Till today we don't know if GND 1193664241 (I've added the full name, the occupation, the retrieval date and NUKAT as a second source) = Richard Willberg (Q12373908) is a duplicate of GND 117387363. The BBLD user likes to ask questions and assign homework but refuses to respond. - I'm just mentioning that since Wikidata:Properties for deletion#Property:P2580 is still pending and we need to decide how to handle these IDs. --Kolja21 (talk) 16:57, 1 July 2021 (UTC)
- Info Claim to omnipotence: 1. Copy infos from a quotable source like Erik Amburger database (Q64584900) and less reliable sources like GenWiki (Q650669) to Baltisches biografisches Lexikon digital (Q18616550) (BBLD). 2. Create an P2580 (P2580) ID. 3. Create an Integrated Authority File (Q36578) GND ID (with BBLD as only source given). 4. GND will be imported by Deutsche Biographie (Q1202222) (DtBio) with a link to BBLD (example). 5. Create an item on Wikidata. 6. Delete the original source if it is mentioned on WD. - The last step is vandalism, the other steps are questionable because the source is veiled. It would be better to create a GND or an item based on the original source. --Kolja21 (talk) 15:54, 1 July 2021 (UTC)
- @Epìdosis: Yes, please undo batch/57969. Amburger database is the original source containing more information.[4] --Kolja21 (talk) 15:21, 1 July 2021 (UTC)
- Quite a lot of their batches should be undo-able via editgroups, in case this is the chosen path here. —MisterSynergy (talk) 10:08, 1 July 2021 (UTC)
- @Kolja21, Emu: Enrichment on the basis of GND (VIAF ID (P214), date of birth (P569), date of death (P570)) running today. Regarding the https://quickstatements.toolforge.org/#/batch/57969, you can check some cases and if all the IDs seem correct I can undo this batch, restoring all the IDs. --Epìdosis 08:59, 1 July 2021 (UTC)
- Unbelievable: I've checked and undid the first edit. I only can guess the reason: Since P2580 (P2580) and Template:BBLD (Q23265105) could not prevail (because of the chaos he created in German Wikipedia and BBLD itself) other sources than "his" BBLD had to be deleted. --Kolja21 (talk) 23:31, 30 June 2021 (UTC)
- Looking at it again: The blocked user deleted these identifiers for some reason. --Emu (talk) 21:24, 30 June 2021 (UTC)
dnbn in URL[edit]
For Q120968405 I added what I thought a was a valid GND identifier, but the URL differs; it contains dnbn instead of gnd (https://d-nb.info/dnbn/390065072). I guess this is not a valid use of the property, is there another way to add the entry correctly? Dorades (talk) 18:50, 27 July 2023 (UTC)
- Hi Dorades, recording companies and music publishers have yet not been imported into the GND. (de:Hilfe:GND#Körperschaften: "Tonträgerfirmen und Musikalienverlage wurden gesondert erfasst und nicht in die GND importiert.) You can add these IDs with DNB edition ID (P1292). Not a perfect solution, but there is no other option at the moment. --Kolja21 (talk) 22:36, 27 July 2023 (UTC)
Removing GND redirect statements[edit]
Message from my talk page:
Headline: Removing deprecated statements
You shouldn't be removing deprecated statements like this one. Please undo your edits. Multichill (talk) 19:04, 18 November 2023 (UTC)
My reply:
Multichill, I couldn't find a rule for what you requested in the property description. Please point to the rule or write it down here. I know that User:Kolja21 and User:Magnus Manske did the same. User:Kolja21 several times thanked me after I removed a redirect ID. He is also hiddenly removing them by simply replacing them with target values. I think User:KrBot does remove redirects in VIAF statements (sometimes by replacement without adjusting references, ranks and qualifiers.)
So, it is not that only I do that.
Topic:Xspjdsm1j614amoh shows a bot operation and the statement that 438,641 redirect targets exist in the redirect file from 2023-10-13.
The highest number of GND IDs on one item about a human that I have evidence for is four, the item is Q3159374, 3x normal rank, 1x deprecated redirect.
Wikidata:Database reports/Constraint violations/P227 says under "Single value" violations "Violations count: 12359". A subset of these are redirects, while other violations can be fixed by other means, permanent redirects can't.
That means if all currently existing redirects were stored in Wikidata, the page would list at least 438,641 violations just based on the redirects, if it could handle them at all.
I think I have seen a discussion between you and several other users, one being User:Kolja21, about the removal of GND redirects, but I don't remember where. In case that you remember that discussion please provide a link to it, so one can see which arguments have been exchanged there.
Among the 10mio+ items about instances of humans there are currently:
- 1587071 that have at least one GND statement (making GND the most used ID property on instances of humans among the VIAF contributors)
- 870 GND redirects found by https://w.wiki/8CFz
- 877 GND redirects found by https://w.wiki/8CGE
I planned to remove the 870 today by batch and check the 7 that make up the difference manually, but will halt the batch and wait for feedback.
Please also note that there are tens of thousands of GND IDs in VIAF clusters about instances of humans that are not yet in Wikidata and thousands of articles about humans in the German Wikipedia that don't contain a GND ID yet.
I am not against storing redirects in Wikidata, but the software doesn't seem to provide the means to do so without getting in the way of maintainers that use the web frontend. Also, if it is done and a reference should be provided, the reference should be one to the GND item in question and not one to the whole VIAF DB as shown in the diff you provided.
Furthermore I doubt the reference in the diff you provided states the truth at all, as it was first used in 2015 while the value was not marked as redirect, and was simply kept in 2022 when the value was marked as a redirect. Kolja21 removed the statement and you reverted, by doing so re-inserting a false claim. So, on this very item two people actively working on GND maintenance removed the statement. Asterix2023 (talk) 21:44, 18 November 2023 (UTC)
- Leave them there. Identifiers serve as unique names for entities, and names do not become obsolete just because that name also has the role of an URL that now redirects. User:Multichill is correct. ---MisterSynergy (talk) 22:22, 18 November 2023 (UTC)
- You wrote three sentences without any links. The first is a command, the second a claim which can be true but doesn't address the issues raised above, the third is a claim which probably is false, as pointed out by me. Asterix2023 (talk) 23:33, 18 November 2023 (UTC)
- There are plenty of best practices which are not explicitly coded into rule etc., but Wikidata editors usually get along with a minimal set of generic policies. There is no policy to remove those claims, and no policy to keep them.
- If you look for single value constraints regarding P227, see Property talk:P227/Constraint violations/Single best value constraint. KrBot lists are not useful when ranks are involved, so you can ignore some of the sections at Wikidata:Database reports/Constraint violations/P227. Mind that we do not want to make editorial decisions based in a faulty bot report. —MisterSynergy (talk) 16:15, 19 November 2023 (UTC)
- Thank you. Others disagree with you, saying that since this is the standard report it should be at least considered. And it isn't the only problem. The redirect IDs are valid IDs, they are names as you said. Other names from a given GND object are stored next to the main statement via a qualifier.
- Why are the redirects stored differently? In a separate main statement and that statement is down ranked? Get other fully valid aliases a rank "deprecated"? Why put them on par with faulty information?
- Why not store them using a qualifier and
- get the reference (the main statement for free) and
- have a clear grouping and
- have them shown *after* the main value
- ? Asterix2023 (talk) 23:01, 19 November 2023 (UTC)
- KrBot constraint violation reports have been largely abandoned in recent years by most of the community. Its maintainer is pretty much the inventor of those constraint reports, but the bot has never been capable enough to really make useful reports for many constraint types. "Single best value constraint" is one of them, since KrBot does not access ranks at all. The reference implementation for constraint violations is much rather the one which is used by the web UI (the indicators that you see when there is a problem), but that one does not generate reports. If you want a particular report, you can set up your own one or ask for help to get it done.
- The other issue is a somewhat reasonable concern. We do want only one claim with best rank in order to allow data users to pick "the best" identifier with ease, and that usually defaults to an identifier that does not redirect on GND side. This could be achieved by raising that best claim to preferred rank and leave all other valid claims at normal rank. With P227, however, things have over time evolved differently with quite a lot of use of deprecated rank. This is an oddity indeed, but since we are using reason for deprecated rank (P2241) qualifiers usually for these deprecated ranks to indicate the reason for that editorial decision of ranking usage, this is an acceptable situation for the moment. Mind that ranks are merely visibility controllers without an intrinsic semantic meaning for the claim.
- Other than that, we do not want to replicate particular data from GND (or any other source) in the identifiers section if form of qualifiers. Such information is often not particularly stable and thus super difficult to maintain in good shape, and besides that it can be queried at GND directly in machine readable form. —MisterSynergy (talk) 23:28, 19 November 2023 (UTC)
- You wrote three sentences without any links. The first is a command, the second a claim which can be true but doesn't address the issues raised above, the third is a claim which probably is false, as pointed out by me. Asterix2023 (talk) 23:33, 18 November 2023 (UTC)
- As of now we lack a precise guideline, since Wikidata:Requests for comment/Handling of stored IDs after they've been deleted or redirected in the external database (opened in mid 2020) is still deadlocked; if I count correctly, 12 users have supported keeping redirected and obsolete IDs in some way and 4 users (including me) have somehow supported removing them; apart from the central issue (keep in some way or just remove), there is still no consensus about how we should possibly keep the IDs and also about allowing or not the addition of IDs which have already become obsolete. My personal feeling, mainly for the reasons I expressed back in 2020 (and for the ones expressed by Ivan A. Krestinin in 2021), is still in favour of removal, although I understand some of the reasons which motivate the option of the keep option. Practically, since there is an ongoing (although deadlocked discussion) where presently a majority of users favours in some way keeping these IDs, and since a massive removal of them is not (at least IMHO) a prioritary part of our curation of interlinks between Wikidata and authority files, I tend to be against massive removals of referenced redirected IDs (for not-referenced ones, I have no objection). Anyway, I have noticed that some of the removed IDs have been added by Reinheitsgebot executing AC2WD (e.g.) although they were already redirects (see deprecation after only one day), and probably also this lacks sufficient consensus, since only a minority of the users who took part in the RfC explicitly supported such additions; I think that, for the same principle, we should also avoid these additions. --Epìdosis 23:25, 18 November 2023 (UTC)
- The GND provides a new redirect file every month, which Magnus Manske is able to parse. From that file redirects can be easily added. No redirect is lost.
- As you didn't address each issue I addressed, now three direct questions:
- Do you support keeping redirects having false references?
- Do you support the increasing number of unfixable constraint violations in the standard reports page, which make the page less useful for maintainers?
- Do you support down ranking of redirects, which if the target is correct are 100% correct themselves, and by doing so putting them on a level with conflated and otherwise false IDs?
- Asterix2023 (talk) 23:49, 18 November 2023 (UTC)
- For me 1) no, I support removing them; 2) the fact that constraint violations reports don't take ranks into account is a know issue which should (but in fact has never been fixed), so it could be considered as an incidental incentive to removing redirected IDs (anyway, checking constraint violations through queries allows to filter out deprecateded statements); 3) personally my preference would be just removing redirected IDs, although (as I said above) it seems that presently a majority of users supports keeping them (on the way of keeping them there is no clear agreement in the RfC). --Epìdosis 00:52, 19 November 2023 (UTC)
- I now read the full RfC, thanks for structuring the thought process. For GND all redirects are available from the source itself as CC0/Public Domain. That is the definitive source that can tell if something is a redirect or not. There can still be reasons to store them in Wikidata, they should be written down, e.g. better technology, more detail, largest (?) CC0 ID hub. There can also be reasons against, Krestinin spoke out against from a general data perspective and as a software developer and I spoke out here against from the other end of those working on the IDs, as someone manually working on the items. Kolja21 is also a person actively working manually on the IDs and like me is against, probably also because the UI and the reports are as they are. There are probably more people actively working manually on the "GND humans", but some may never have seen items with 4 or more IDs on them. There is MisterSynergy who runs a bot, for him the UI and standard error reports are of less relevance as he can use the bot and selfmade reports instead. And then there are users in that discussion that maybe don't do any maintenance on GND humans so aren't aware of the problems maintainers face. The red and green rank colors have been mentioned, I may add that Kolja21 frequently changes the order of the values - manually. If redirects are kept, more UI users may want to do that as no bot seems to do it. I think this is distracting humans from doing other work in WD.
- A cheap option hasn't been mentioned yet: Let a bot take care of the redirects inside qualifiers, then they are visible to humans whilst requiring a minimal amount of UI space, and being placed next to the target value, no change of sort order and misuse/misleading use of the deprecated rank needed (they are called deprecated in GND, but that is not what the rank deprecated is used for in WD elsewhere, they are 100% valid IDs.) They don't need to be links as they resolve to the target anyway, it is actually better they are not, to avoid that crawlers follow them and spend energy on it. Users, me included, may like to test if a redirect really resolves to the target - if a bot takes care of the maintenance there might be less desire by these users, because they simply trust the given values. Already now qualifiers are used to present data from the source item, e.g. "subject named as" does so, therefore such usage is in line with existing practice. We could have "subject has redirect" or "subject has alias/secondary ID". That solution could, or probably should, only be used for source items that provide the aliases, which is the case for GND. No extra references on redirects as the target ID, the one in the main statement is the source for the alias as it is for "subject named as". There is also some Javascript GND reveal.js, or authority control.js, maybe it can be programmed into these tools to maintain redirects, so one is a bit more independent from bots. The tools could also provide links. Asterix2023 (talk) 05:57, 19 November 2023 (UTC)
- For me 1) no, I support removing them; 2) the fact that constraint violations reports don't take ranks into account is a know issue which should (but in fact has never been fixed), so it could be considered as an incidental incentive to removing redirected IDs (anyway, checking constraint violations through queries allows to filter out deprecateded statements); 3) personally my preference would be just removing redirected IDs, although (as I said above) it seems that presently a majority of users supports keeping them (on the way of keeping them there is no clear agreement in the RfC). --Epìdosis 00:52, 19 November 2023 (UTC)
Storing GND redirect ID in qualifier[edit]
Example using alternative name (P4970): https://www.wikidata.org/w/index.php?title=Q87718745&diff=prev&oldid=2013930086
Fulltext search finds the alias ID: https://www.wikidata.org/w/index.php?fulltext=1&search=1090225261&title=Special%3ASearch&ns0=1&ns120=1
Issues solved:
- redirect ID in Wikidata, no need for access to an external DB
- value available in truthy dump [5]
- clear relationship to primary ID (redirect target ID)
- compact representation
- no misuse or misleading use of ranks
- no sorting issues regarding primary ID, the primary is always shown first
- no false references regarding the alias nature, as the source for that claim is the item linked to in the main statement (like for "subject named as")
- moveClaim.js can move a full set of information to another item
To do:
- create a dedicated qualifier property named either
- alias ID
- alternative ID
- ...?
- update JavaScript tools so they handle that qualifier
- gnd reveal.js
- authority control.js
- ...?
- get bot help
- to add the IDs
- to check the IDs maybe monthly (after the GND redirect dump is published? At time of publication it may already be outdated)
- to provide reports on changed values?
- let Wikibase
- show links?
- sort the qualifier at the same place independent from when it has been added
- sort an ID among others independent from when it has been added to the main statement
Asterix2023 (talk) 07:34, 19 November 2023 (UTC)
@Ecelan: at Q8351762 Despuig you reverted the removal, you reverted the revert, but in talk expressed the wish to have the old values. What do you think about storing them in a qualifier? Details in the first message of this section. Asterix2023 (talk) 15:10, 19 November 2023 (UTC)
- I am generally against eliminating information (inclusionist), because you never know when it can be useful. Even wrong or old information can be useful if you present it in the correct context. So I'm in favor of keeping the old DNS numbers however you decide to do it. --Ecelan (talk) 15:25, 19 November 2023 (UTC)
GND Umleitung in Qualifier speichern[edit]
Es äußern sich immer wieder Leute zum Thema, die wohl nicht GND-Wartung per Hand per Webinterface betreiben. Die Diskussionen finden dann meist auf Englisch statt, was ja grundsätzlich OK ist, aber auch Leute ausschließen kann, die GND-Wartung betreiben. Daher hier nun in deutscher Sprache der Sprache der GND.
Direkt oberhalb ist der Vorschlag auf Englisch die Weiterleitung-IDs im Qualifier zu speichern.
Beispiel unter Verwendung von alternative name (P4970): https://www.wikidata.org/w/index.php?title=Q87718745&diff=prev&oldid=2013930086
Volltextsuche findet die Weiterleitunggs-/Alias-ID: https://www.wikidata.org/w/index.php?fulltext=1&search=1090225261&title=Special%3ASearch&ns0=1&ns120=1
Die Weiterleitungs-IDs sind ja vollständig gültige IDs, sie als "deprecated" zu speichern stellt sie auf eine Stufe mit falschen oder kaputten Werten. Es gibt rund eine halbe Million Weiterleitungen, die Wartungsseite zeigt schon gar nicht mehr alle Single-value-Regelverletzungen mehr an, keine einzige Qid hat ein Label dort, die Seite ist praktisch unbenutzbar. Es ist zudem nicht klar auf welches Ziel sich eine Weiterleitung bezieht, es können in einem Wikidata-Objekt ja mehrere Nichtweiterleitungen enthalten sein.
Findet man einen Fehler bei der Zuordnung und möchte einen Wert zu einem anderen Element verschieben (mit dem Helferlein moveClaim.js möglich), müsste man die Weiterleitungen überprüfen. Und schiebt man die dann auch rüber zu Q456, oder weil irgendeine Quelle mal sagte sie gehört zu Q123 soll sie da bleiben? Kopiert man, also bei beiden speichern?
Die Reihenfolge der Elemente ist auch problematisch, es können zuerst mehrere Weiterleitungen gelistet sein, danach kommt dann der aktuelle Hauptwert. Oder umgekehrt, allerdings stehen DtBio, Sächsische Biographie und Kalliope dann in größerer Entfernung. Überhaupt ist der Platzverbrauch viel höher im derzeitigen System.
Die Speicherung im Qualifier löst mehrere Probleme, die Darstellung ist kompakt, die Zuordnung zum Zielwert eindeutig und die Quelle der Information auch, denn wie die gelegentliche Angabe des Namens wie er in der GND steht mittels Qualifier, ist auch bei der Angabe sekundärer IDs mittels Qualifier die GND selbst die Quelle.
Meinungen? Asterix2023 (talk) 13:57, 19 November 2023 (UTC)
@U. M. Owen: du hattest auch die Löschung hinterfragt, bzw. dich etwas dagegen geäußert. Was hälst du von Speicherung in einem Qualifier? Asterix2023 (talk) 15:15, 19 November 2023 (UTC)
- Eine veraltete GND als alternative name (P4970) einzutragen, ist unzulässig. Warum? Weil eine ID kein alternativer Name ist. @Emu, Epìdosis: Can you have a look at this? It's a typical User:Humanisator idea. Trying out new concepts that contradict all the rules. --Kolja21 (talk) 22:20, 19 November 2023 (UTC)
- User:Kolja21 seit wann ist eine ID kein Name? Hast du gelesen was User:MisterSynergy schrieb [6] "Identifiers serve as unique names for entities, and names do not become obsolete just because that name also has the role of an URL that now redirects." I don't understand why you after writing in German in this section that was started in German switch to English and refer to User: Humanisator. It's a typical Humanisator idea? Did you confuse that user with MisterSynergy as it was him who seems to have first mentioned here that identifiers are names? Also, I wasn't "trying out new concepts" I just made one edit to test if the search finds a name stored in the qualifier. If you knew that before fine, I didn't. I have seen no documentation on that. Asterix2023 (talk) 23:17, 19 November 2023 (UTC)
- @Kolja21 See Wikidata:Requests for checkuser#MrProperLawAndOrder --Emu (talk) 23:29, 19 November 2023 (UTC)
- Germany-related properties
- All Properties
- Properties with external-id-datatype
- Properties used on 1000000+ items
- Authority control properties
- Properties with format constraints
- Properties with conflicts with constraints
- Properties with single best value constraints
- Properties with unique value constraints
- Properties with qualifiers constraints
- Properties with scope constraints
- Properties with entity type constraints
- Properties with label language constraints
- Properties with complex constraints