Property talk:P821

Latest comment: 1 year ago by VIGNERON in topic Use as reference deprecated

Documentation

CGNDB unique ID
identifier(s) for a geographical feature contained in the Canadian Geographical Names Database (CGNDB)
DescriptionIdentifier the geographical feature of the Geographical Names Board of Canada / Commission de toponymie du Canada.
Applicable "stated in" valueCanadian Geographical Names Database (Q14934367)
Data typeExternal identifier
Template parameteren:Template:Cite cgndb - Template:Cite cgndb (Q6927131)
Domainplace (note: this should be moved to the property statements)
Allowed values[A-O][A-Z]{4} (5 uppercase letters)
ExampleRed River of the North (Q156006)GAWTC
GBFMO
Québec City Jean Lesage International Airport (Q794549)EPWHM
SourcePlace names - Query by name
Noms de lieux - Recherche par nom de toponyme
Formatter URLhttps://geonames.nrcan.gc.ca/search-place-names/unique/$1
Tracking: usageCategory:Pages using Wikidata property P821 (Q27485862)
Related to country  Canada (Q16) (See 163 others)
See alsoBC Geographical Names ID (P2099), Banque de noms de lieux du Québec ID (P2100)
Lists
Proposal discussionProposal discussion
Current uses
Total365,186
Main statement363,05499.4% of uses
Qualifier3<0.1% of uses
Reference2,1290.6% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Distinct values: this property likely contains a value that is different from all other items. (Help)
List of violations of this constraint: Database reports/Constraint violations/P821#Unique value, hourly updated report, SPARQL (every item), SPARQL (by value)
Format “[A-O][A-Z]{4}: value must be formatted using this pattern (PCRE syntax). (Help)
List of violations of this constraint: Database reports/Constraint violations/P821#Format, hourly updated report, SPARQL
"exceptions" is incompatible with "mandatory" parameter List of violations of this constraint: Database reports/Constraint violations/P821#Item P131, hourly updated report, search, SPARQL
Item “coordinate location (P625): Items with this property should also have “coordinate location (P625)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P821#Item P625, SPARQL
Single value: this property generally contains a single value. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P821#Single value, SPARQL
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P821#Entity types
Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P821#Scope, SPARQL
 
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)


No single value

edit

Hello. I have withdrawn the single value constraint, as the database is full of entries in both French and English, each language getting a different identifier. Thierry Caro (talk) 04:20, 8 November 2016 (UTC)Reply

@Thierry Caro: There is also one entry by province. Actually the Gulf of Saint Lawrence (Q169523) is the most exteme case whit 10 different ID. --Fralambert (talk) 04:42, 8 November 2016 (UTC)Reply

Toponymic Feature ID

edit

I see that it was briefly mentioned when the property was created, but there also exists a "Toponymic Feature ID" which works fine using the same formatter URL and is actually unique for each item unlike the "Key" currently used. Not sure why this was not discussed further before creation because it makes sense to me to either use that or allow it as another value for this property (alter the regex). --SilentSpike (talk) 16:13, 8 August 2019 (UTC)Reply

An example for the existing property example: http://www4.rncan.gc.ca/search-place-names/unique/703f61a8ba3311d892e2080020a0f4c9 --SilentSpike (talk) 16:14, 8 August 2019 (UTC)Reply
Yes, looks like current property is for one of several names of a geographical feature, not for a geographical feature itself as misleadingly stated in property description. As items are for geographical feature and not their individual name variants, then it would make sense indeed to replace keys like GAWTC with IDs like 703f61a8ba3311d892e2080020a0f4c9.
The same formatter URL would apply to both, but I think it'd be better to create new property for these longer IDs. Short keys and longer IDs have distinct purpose, new property would be for longer ID that is actually unique to individual geographical feature. So accurate label, description and format constraint could be used for each. 2001:7D0:81C5:A580:15D3:1269:BF2A:C740 18:04, 8 April 2022 (UTC)Reply
@SilentSpike I think the best solution is that even if the two have share the same format url, is to create a new property for the Toponymic Feature ID. It will be better for the format constraint. Fralambert (talk) 15:30, 9 April 2022 (UTC)Reply
Once I get all the CGNDB five-letter keys into Wikidata, I will be in a position to populate the Toponymic Feature IDs upon the creation of that property. -- Denelson83 (talk) 06:58, 20 July 2022 (UTC)Reply

First letter uniquely identifies province or territory

edit

The first letter of a CGNDB unique ID corresponds one-for-one to a province or territory. I feel that if P821 is added to an item, it should automatically add the correct corresponding value for P131 based on this first letter, provided that P131 is not already yet present and set to the correct value:

  • A = Newfoundland and Labrador (Q2003)
  • B = Prince Edward Island (Q1978)
  • C = Nova Scotia (Q1952)
  • D = New Brunswick (Q1965)
  • E = Quebec (Q176)
  • F = Ontario (Q1904)
  • G = Manitoba (Q1948)
  • H = Saskatchewan (Q1989)
  • I = Alberta (Q1951)
  • J = British Columbia (Q1973)
  • K = Yukon (Q2009)
  • L = Northwest Territories (Q2007)
  • M = (Reserved, undersea features)
  • N = (Reserved, international waters, e.g. NAABF for Gulf of Maine)
  • O = Nunavut (Q2023)

-- Denelson83 (talk) 07:21, 29 April 2022 (UTC)Reply

edit

Due to a change it is necessary to convert the link format of the objects from: http://www4.rncan.gc.ca/search-place-names/unique.php?id=$1 to http://toponymes.rncan.gc.ca/search-place-names/unique.php?id=$1. Paelius (talk) 11:22, 21 April 2022 (UTC)Reply

Unfortunately, that is not working either. I would suggest this format instead: https://geonames.nrcan.gc.ca/search-place-names/unique/$1 -- Denelson83 (talk) 04:03, 22 April 2022 (UTC)Reply
edit

Because of the fact that there are now almost 100,000 occurrences of this property in Wikidata, I am providing these links to filter these occurrences by province or territory before displaying them on a map.

-- Denelson83 (talk) 16:32, 19 July 2022 (UTC)Reply

Exception to constraint needed - "subject named as"

edit

It should not be a single-value constraint violation to have more than one P821 value in the same item if those multiple values have different names attached to them as P1810 values in their references. For a lot of the currently-listed single-value constraint violations, the only distinction among the multiple values in each such item is their referenced P1810 values. -- Denelson83 (talk) 04:50, 9 December 2022 (UTC)Reply

Use as reference deprecated

edit

With my project to put all of the CGNDB codes into Wikidata past the 84 percent mark at this point, I have deprecated the use of this property as a reference because such a use has now become redundant. -- Denelson83 (talk) 07:07, 11 January 2023 (UTC)Reply

@Denelson83: It is redundant as a reference for the primary entry, but what about for secondary entries? For example indicating for a lake that the outflow is a particular watercourse? I would use the CGNDB code for the watercourse as a reference, not the primary entry's CGNDB code. Or is it assumed that by mentioning the watercourse, which would have its own CGNDB code at its own entry, that that would be sufficient proof? Thanks!   --Qui1che (talk) 03:33, 13 January 2023 (UTC)Reply
It would be redundant for secondary entries as well. As I have said, I am adding all CGNDB codes to Wikidata, over 360,000 of them. Such relations can be specified just by using the Wikidata items themselves. And besides, the CGNDB itself does not indicate such relations. -- Denelson83 (talk) 04:07, 13 January 2023 (UTC)Reply
No issue doing that way. Also note that for Ontario entities -- like lakes and rivers, and incorporated towns and cities -- the CGNDB enties shows the extent of the feature, and so, for example, would indicate that a river started at a particular lake, or that a lake was on a certain river. One of my recent edits is the Fawn River; here is the CGNDB page for it. I will admit that I think that the info is most often available for Ontario features and not consistently for those in other provinces. --Qui1che (talk) 05:30, 14 January 2023 (UTC)Reply
This is probably because the province of Ontario provided polyline data for most, if not all, of its watercourse entries to the CGNDB, while the other provinces could not be bothered to as great an extent. The individual provinces and territories are responsible for maintaining the lion's share of the CGNDB, and each entry in the CGNDB tells you which agency, whether provincial, territorial, or to a much lesser extent federal, contributed it.
As for the example you gave, Fawn River (Q1398954), its CGNDB unique ID (P821) appears five times in its Wikidata entry, once as a main value, and four times as a reference. I do not consider it necessary to have a specific P821 value appear in our database more than once, as it exists solely as a method of authority control. The statement "stated in (P248) = Canadian Geographical Names Database (Q14934367)" as a reference for other main statements in that entry, combined with the appropriate P821 as just a main value in the same entry, should suffice. -- Denelson83 (talk) 07:14, 14 January 2023 (UTC)Reply
@Nikki: You seem to disagree with this, as you reverted this deprecation. -- Denelson83 (talk) 05:49, 21 January 2023 (UTC)Reply
@Fralambert: You have also reverted this deprecation. Can you please explain why? -- Denelson83 (talk) 17:37, 5 February 2023 (UTC)Reply
Because it was a constraint violation ad I also use it sometime as a reference (mostly for the coordinates). I don't kow how it should be different as Banque de noms de lieux du Québec ID (P2100), even if this second one give more information, as also BC Geographical Names ID (P2099). Fralambert (talk) 18:50, 5 February 2023 (UTC)Reply
Also useful for citing the official names (When we have many in particular, like Labyrinth Lake (Q22586133)). Fralambert (talk) 20:28, 5 February 2023 (UTC)Reply
But they are already cited in the main values. -- Denelson83 (talk) 07:32, 8 February 2023 (UTC)Reply
@Denelson83: it's not the same thing. A main value is very general ("more information about this item can be found there") while a reference is specific ("you can check this specific data there") ; not all data on an item can be found on the database(s) present as main value, references are essential to know for each data where they come from. Cheers, VIGNERON (talk) 18:38, 10 February 2023 (UTC)Reply
Return to "P821" page.