Wikidata:Property proposal/TripAdvisor ID 2

From Wikidata
Jump to navigation Jump to search

TripAdvisor ID

[edit]

Originally proposed at Wikidata:Property proposal/Place

   Done: TripAdvisor ID (P3134) (Talk and documentation)
Descriptionidentifier of a place, in TripAdvisor
RepresentsTripadvisor (Q1770710)
Data typeExternal identifier
Allowed values[0-9]+
Example 1Saint Paul hermitage (Q26389271)4037786
Example 2Cencio la Parolaccia (Q3664378)1049551
Example 3Canegrate (Q581)2023357
Format and edit filter validationNo words or symbols, just numbers
Sourcehttps://www.tripadvisor.com
External linksUse in sister projects: [ar][de][en][es][fr][he][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][commons][species][wd][en.wikt][fr.wikt].
Expected completenessalways incomplete (Q21873886)
Formatter URLhttps://www.tripadvisor.com/$1
Robot and gadget jobs
  • Convert P553Q1770710 (P554 → $1) into TripAdvisor ID → $1
  • Convert all "non-standard" and old IDs to the new and correct one
See alsoWikidata:Property proposal/TripAdvisor ID

Motivation

[edit]

Everything you need to know has been discussed here. --★ → Airon 90 12:02, 15 March 2020 (UTC)[reply]

Discussion

[edit]

@Airon90: You might wanna see this query --Trade (talk) 17:12, 16 March 2020 (UTC)[reply]

  •  Oppose. I'm sorry but just changing TripAdvisor ID (P3134) works fine for me. Thierry Caro (talk) 19:10, 19 March 2020 (UTC)[reply]
    • Users Jura1 and SilentSpike think that a new property is needed instead of changing TripAdvisor ID (P3134) --22:24, 19 March 2020 (UTC)[reply]
      • I know. And I understand that this is because they are worried about disrupting third parties using the property. But I believe that instead of having to create a new property every time an established one needs an update, we should just create one~for letting third parties indicate their use of a given property on that property page. This way we would know who we should contact before we implement a change instead of just speculating over possible external use and self-censoring because of that. Thierry Caro (talk) 16:28, 20 March 2020 (UTC)[reply]
        • I don't think there should be a requirement to request stable entities from Wikidata. Even if there was and we know some properties are used on Commons. What could they do? Commons doesn't really have a way to identify each of them nor change them easily. --- Jura 13:51, 28 March 2020 (UTC)[reply]
  •  Support I don't really have a strong opinion on whether the old property should be deprecated or just updated. However, Jura's points convinced me that it makes more sense to create a new property and deprecate the old one (as you cannot rely on third parties indicating their property use when dealing with open data). This seems like the kind of thing the Wikidata community should establish precedent on for future decisions. --SilentSpike (talk) 13:20, 27 March 2020 (UTC)[reply]
  • Oppose for a new property, given the change is backward-compatible.--GZWDer (talk) 12:05, 2 April 2020 (UTC)[reply]
  •  Oppose. It is unclear to me how replacing this will break anything. What uses outside of Wikidata would be affected? Unless somebody decides to join multiple resources on this one identifier, there is nothing to worry about. To support a new property, @Jura1: and @SilentSpike: should show an example of where a problem will exist and instead of bringing up hypothetical problems (e.g. find a project that uses tripadvisor ids as stable identifiers to match to Wikidata). Otherwise downstream projects can use the Q-id for stable identifiers and simply update the tripadvisor ids. I dont see the need for a new property, that is only confusing -- Or am I somehow misunderstanding the problem here? Properties get deleted from time to time and/or change their meaning and downstream projects will have to deal with this. --Hannes Röst (talk) 17:23, 26 June 2020 (UTC)[reply]
  • {{Not done}} In this case TripAdvisor does not introduce a new type of ID, and the new one is really canonical.--GZWDer (talk) 02:20, 2 July 2020 (UTC)[reply]
  •  Support per above. --- Jura 13:57, 2 July 2020 (UTC)[reply]