Wikidata

Wikidata:Property proposal/Olympedia Affiliations ID

< Wikidata:Property proposal

Olympedia Affiliation ID edit

Originally proposed at Wikidata:Property proposal/Sports

Descriptionidentifier for the affiliation of athletes in Olympedia athlete database
RepresentsOlympedia (Q95606922)
Data typeExternal identifier
Domainorganization (Q43229)
Allowed values[1-9]\d{0,5}
Example 1Stadtturnverein Winterthur (Q1728217) → 6324
Example 2Waseda University (Q274486) → 999
Example 3Industriales (Q1661948) → 12047
Number of IDs in source>15200
Expected completenessalways incomplete (Q21873886)
Formatter URLhttps://www.olympedia.org/affiliations/$1

Motivation edit

Deutsch: Wir haben bereits alle möglichen Kennungen für olympische Athleten. Aber zusammen mit den Athleten sind bei vielen auch Zugehörigkeiten zu Clubs oder Universitäten dokumentiert, hier am Beispiel von Olympedia.org. Es macht Sinn, dass wir diese Zugehörigkeiten auch mit den entsprechenden Items verlinken. Fundriver (talk) 10:31, 28 December 2020 (UTC)[reply]
English: We already have all possible olympic athletes ID. But together with them also affiliations to sport-clubs, universities and so on are documented in the olympic-databases, here on the example of Olympedia.org. It makes sense to also link those affiliations to the correspondending items. Fundriver (talk) 10:31, 28 December 2020 (UTC)[reply]

Discussion edit

I don't totally understand? The Affiliation-ID belongs to the institution - which is supposed to be created here? For sure those affiliations also indicate our member of sports team (P54)-relation we have here and would be nice, if this could be mapped somehow automated. However, to have this ID also as property to have a reference of Olympia-participants of certain sportclub is useful. Fundriver (talk) 06:19, 29 December 2020 (UTC)[reply]
  Support Cool - that answers my question about usage so all good from me :) Sillyfolkboy (talk) 01:16, 2 January 2021 (UTC)[reply]
  •   Support --Edgars2007 (talk) 13:35, 29 December 2020 (UTC)[reply]
  •   Support --Sannita - not just another it.wiki sysop 21:20, 29 December 2020 (UTC)[reply]
  •   Support --Phikia (talk) 02:06, 30 December 2020 (UTC)[reply]
  •   Support --Migrant (talk) 15:28, 30 December 2020 (UTC)[reply]
  •   Comment -- Note that the listed affiliations at the athlete-pages are the affilitions they were under during their olympic participation, which means that they are not always complete for the sports athletes career. Migrant (talk) 15:35, 30 December 2020 (UTC)[reply]
  •   Strong oppose @MisterSynergy, Fundriver:, Just like P9055 and P8286, "expected completeness" is completely wrong. All these properties take the value always incomplete (Q21873886). —Eihel (talk) 09:57, 28 January 2021 (UTC)[reply]
    Is this really meant to be opposition to the proposal? The "expected completeness" as given above should not matter for this, right? Aside from that, I still strongly disagree with your position, as "expected completeness" refers to the completeness of our mapping to external database entries, not the indefinite completeness of the external database itself. —MisterSynergy (talk) 23:36, 28 January 2021 (UTC)[reply]
    Dear MisterSynergy, I come back after careful consideration, because you raise several points and I wanted to respond you with hindsight and calm. I am really very surprised by your first sentence. I put here an aspect of the recommendations present since April 2020: All opposing points of discussion should be addressed before creation occurs. If there is still disagreement, it is up to the property creator to consider the thoughtfulness and logic behind points of discussion (i.e. an opposing voice with no thought behind it should not block creation, but a single reasonable opposing voice against many supporters may do so). Can an error be propagated in production? Why are there PCs? I wouldn't offend you on this first point.
    Through our discussions, here and on your TP, you should only use always incomplete (Q21873886) very little. But it's one of the most used values, it's surprising. The fact that you do not agree with me does not advance our case.
    I'm glad you used the term "mapping". Data mapping is used as the first step in data integration tasks. This process can be verified in numerous works, worthy of the name, dealing with this subject. If the mapping is designed or verified at a time t, the data integration is part of a duration aspect. The level of data integration by users is also the goal of P2429 ("set of real-world items").
    If the external db accepts new entries, the mapping becomes incomplete on the WD side. Athletes or sporting events become known only from new OGs (non-existent items). The mapping only exists from a link between WD and an external source, that is, a property and in the way you approach the subject, completeness is changing over time. No, almost not. Yes, "expected completeness" refers to the completeness of our mapping to external database entries, but this must be valid over time (data integration), therefore completely linked to the external database itself.
    In the past, an example has already been given: If a user asks for an ISBN that we don't have, there's a good chance it's a good ISBN that we don't cover - but if they're looking for a country code that we don't have, there's chances are it is an invalid code. Let's redo the process: if a user asks for an athlete ID that we don't have, there is no good chance that it is an invalid ID. So this deduction proves to you that it's always incomplete (Q21873886) that you have to put here and on the properties that I mentioned in my first intervention, as is ISBN-13 (P212). QED (will never be complete at any level).
    I do not intend to come back to this problem indefinitely: the proposition is false and prevents the creation of the property. Warmest regards. —Eihel (talk) 05:34, 7 February 2021 (UTC)[reply]
    @MisterSynergy: Okay, I notify you by correction, even though i haven't been. —Eihel (talk) 05:47, 7 February 2021 (UTC)[reply]
    Wow, this process that I have to proposal before creation isn't that straight-forward, regarding that everybody can edit this minor thing. For me as an editor it doesnt matter. However, I changed it to always incomplete (Q21873886). I hoipe we can forward to creation of this item. Fundriver (talk) 14:25, 5 April 2021 (UTC)[reply]
  • The examples do not match the definition of the property. If this is the affiliation of an athlete, the Q item examples should be for athletes not organizations. UWashPrincipalCataloger (talk) 01:09, 5 April 2021 (UTC)[reply]
    No, this is correct. This property maps an organisation (reffered in the "affiliation ID") to the actual organisation here on Wikidata. It doesnt match an athlete on Wikidata to an affiliation ID (which wouldn't be the same). Best regards, Fundriver (talk) 14:25, 5 April 2021 (UTC)[reply]

@Fundriver, MisterSynergy, Deansfa, Sillyfolkboy, Edgars2007, Sannita:@Phikia, Migrant, Eihel:   Done Now Olympedia affiliations ID (P9447) --Lymantria (talk) 14:12, 16 April 2021 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Olympedia_Affiliations_ID&oldid=1402636578"