Shortcut: WD:PP/PLACE

Wikidata:Property proposal/Place

From Wikidata
Jump to: navigation, search


Property proposal: Generic Authority control Person Organization
Event Creative work Term Space
Place Sister projects
Economics Transportation Natural science Property metadata

See also[edit]


This page is for the proposal of new properties.

Before proposing a property
  1. Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Change status=ready on template to attract the attention of a property creator.
  2. Creation can be done after 1 week by a property creator or an administrator.
  3. See steps when creating properties.


On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2016/12.

Place[edit]

official classification of settlements[edit]

   Under discussion
Description A specification of the official classification codes used for settlements in a country.
Data type Item
Domain country (Q6256)
Allowed values unique identifier (Q6545185)
Example
Planned use Make w:ro:Module:InfoboxSettlement capable of automatically finding the relevant classification number for any country who has an item specified for the proposed property.
Motivation

When working on making the ro.wp equivalent of w:en:template:Infobox settlement (implemented as w:ro:Module:InfoboxSettlement) capable of getting data from Wikidata, I stumbled upon the fact that the official classification codes for each settlement have separate schemes for each country. We already have Wikidata property for some of the national codes (see examples above), but there is no way of knowing automatically which one applies to a certain settlement. One way of solving this is making the module aware of all possible classification systems in the world, but a cleaner solution would be to be able to access country (P17), and then this property, and then Wikidata property (P1687) in order to get the actual property of the current item to seek. Andrei Stroe (talk) 12:03, 29 November 2016 (UTC)

Discussion

HAER building ID[edit]

   Under discussion
Description identifier for an historic building or other structure, in the Library of Congress' Historic American Engineering Record
Data type External identifier
Template parameter |id= in en:Template:HAER
Domain historic buildings or structures in the United States
Example Washington Monument (Q178114)dc0968
Formatter URL https://loc.gov/pictures/item/$1
Robot and gadget jobs import from en.Wikipedia
See also Wikidata:Property proposal/HABS building ID
Motivation

HAER is an official programme of the Library of Congress (Q131454). Template:HAER (Q15943784) exists in three Wikipedias. en.Wikipedia has over 1000 of these IDs, in templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 18 August 2016 (UTC)

Discussion
Both this HEAR and HABS are subsets of the large picture collection of the Library of Congres and are in the same https://loc.gov/pictures/item/* structure. Does it actually identify a building or is it just an id for each time they came by and did a survey? Multichill (talk) 12:35, 21 August 2016 (UTC)
The former. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 2 September 2016 (UTC)
If that number is a straight subset, why do we need it as extra data? ChristianKl (talk) 11:16, 14 September 2016 (UTC)
A question beginning "If that number is a straight subset, why..." makes no sense. Also, as noted, the ID is used in en:Template:HAER; and Template:HAER (Q15943784) exists in three Wikipedias. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:52, 22 October 2016 (UTC)
A „mabbettly answer“needs verification . --Succu (talk) 21:06, 22 October 2016 (UTC) Is it about Historic American Buildings Survey or Historic American Engineering Record or Historic American Landscapes Survey? --Succu (talk) 21:20, 22 October 2016 (UTC)
The verification you request is in the links I provided: en:Template:HAER; and Template:HAER (Q15943784). As clearly stated in the proposal, this is for the "Historic American Engineering Record". Please refrain from ad hominem abuse. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:33, 25 October 2016 (UTC)

HABS building ID[edit]

   Under discussion
Description identifier for an historic building or other structure, in the Library of Congress' Historic American Buildings Survey
Data type External identifier
Template parameter |id= in en:Template:HABS
Domain historic buildings or structures in the United States
Example Washington Monument (Q178114)dc0261
Formatter URL https://loc.gov/pictures/item/$1
Robot and gadget jobs import from en.Wikipedia
See also Wikidata:Property proposal/HAER building ID
Motivation

HABS is an official programme of the Library of Congress (Q131454). Template:HABS (Q17279094) exists in four Wikipedias. en.Wikipedia has over 1900 of these IDs, in templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:09, 18 August 2016 (UTC)

Discussion

ITU prefix[edit]

   Under discussion
Description The International Telecommunication Union (ITU) allocates call sign prefixes for radio and television stations of all types
Represents ITU prefix (Q1344924)
Data type String
Domain countries, Organization
Allowed values Letter/number
Example
Source w:ITU prefix
Robot and gadget jobs No
Motivation

The International Telecommunication Union (ITU) allocates call sign prefixes for radio and television stations of all types. They also form the basis for, but do not exactly match, aircraft registration identifiers. These prefixes are agreed upon internationally, and are a form of country code. A call sign can be any number of letters and numerals but each country must only use call signs that begin with the characters allocated for use in that country. GZWDer (talk) 20:00, 10 July 2016 (UTC)

Discussion


  • Symbol support vote.svg Support, but datatype should be "external-id". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:53, 10 July 2016 (UTC)
  • Symbol support vote.svg Support as external-id per Andy. Thryduulf (talk) 23:03, 10 July 2016 (UTC)
  • Pictogram voting comment.svg Comment Trying to grasp the system from w:ITU prefix and http://www.itu.int/online/mms/glad/cga_callsign.sh?lng=E I understand that call-signs are up to three digits, and if a country has a complete set A-Z allocated, then it may use 0-9 as well in that position. The proposal is to add only the fixed parts of the allocation. Okay with me, but I don't think that "external identifier" suits here as @Pigsonthewing, Thryduulf: suggest. Support for string datatype. Lymantria (talk) 22:13, 3 August 2016 (UTC)
  • Symbol support vote.svg Support as string, GA candidate.svg Weak support as external-id. --Srittau (talk) 23:03, 19 August 2016 (UTC)
  • @Thryduulf, Pigsonthewing: Would you object to this property being created as String as proposed and as favored by Srittau and Lymantria? ChristianKl (talk) 12:26, 9 September 2016 (UTC)
    • Yes, without explanation as to why external identifier is not appropriate here. Thryduulf (talk) 12:33, 9 September 2016 (UTC)
      • @Lymantria: why do you think this is not suitable for an external ID datatype? Thryduulf (talk) 14:54, 14 September 2016 (UTC)
        • That is because a part of a prefix IMHO is not an identification code. "IS3" for instance is a prefix, while "I" is the proposed identification code, appointed to Italy. While codes are far from unique, some are ambiguous (China!). Lymantria (talk) 15:06, 14 September 2016 (UTC)  – The preceding unsigned comment was added by Lymantria (talk • contribs).
          • @Lymantria: why does it being a prefix stop it being an identifier? I'm also not clear why you regard this as ambiguous, nor why that makes it unsuitable for an external identifier but suitable for a string? Thryduulf (talk) 14:35, 4 November 2016 (UTC)
      • @Srittau: do you have an opinion regarding the datatype? Thryduulf (talk) 14:54, 14 September 2016 (UTC)
    • It's an identifier, and it's not internal to Wikidata, so yes, I would. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:02, 9 September 2016 (UTC)
  • Pictogram voting comment.svg Comment I've removed the "ready" status as there is no consensus currently regarding the datatype.
  • Symbol oppose vote.svg Oppose I think this is the wrong approach. Why not create a wikidata item for each identifier, make it an instance of ITU prefix (Q455644) and provide the appropriate country (P17) statement. That way these are not cluttering up the country items but they are still linked to the country so that can be discovered easily enough. And if there are other appropriate geo-location properties associated with particular prefixes they can be added also. ArthurPSmith (talk) 20:22, 4 November 2016 (UTC)

population density[edit]

   Ready <create>
Description density of the human population of a particular area/region.
Represents population density (Q22856)
Data type Number
Template parameter population_density in {{Geobox}}
Domain subclass of territorial entity (Q1496967)
Allowed values any positive number
Allowed units we may need to create some units here
Example Lisbon (Q597) → 6458 people/km2
See also Discussion at https://www.wikidata.org/wiki/Wikidata:Project_chat#density_vs._population_density
Motivation

Looks like we do not have a property to describe population density, and people start adding the numbers under "density", which is wrong. We should add this property.

See also: Wikidata:Project chat#density vs. population density Laboramus (talk) 20:25, 15 August 2016 (UTC)

  • Symbol support vote.svg Support. If the intention is to restrict this to human populations then the units can just be "per km²" but if we want other populations then we'll need "people per km²". I support either. Thryduulf (talk) 20:59, 15 August 2016 (UTC)
  • Symbol oppose vote.svg Oppose Density is the result of population/land area. I don't see the neccessity to create a property when we can calculate it with other properties. --Fralambert (talk) 04:22, 16 August 2016 (UTC)
  • Symbol oppose vote.svg Oppose. This should be calculated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 16 August 2016 (UTC)
    • It may be calculated, indeed, if the source data is known (not always so). Still, a lot of encyclopedic sources, reference literature and Wikipedia infoboxes produce these numbers. Judging by use of wrong "density" property, there's demand for this in Wikidata too. Also, there might be different population densities for parts of the whole, for example. --Laboramus (talk) 04:46, 19 August 2016 (UTC)
  • Symbol support vote.svg Support. Would be better to not restrict to people - many ecology studies have population densities of different species (or also of breeding pairs). This sort of detail could be added as a qualifier.
    Population densities may be estimated from sampled areas rather than being simply being a matter of dividing the count by the area - an example of sampling methodology from British Trust for Ornithology (Q2925763).
    Also, the given population density in a source may be given to a certain number of significant figures which the source has deemed appropriate, and not overly concise, for example the Office for National Statistics (Q1334971) gives population density from censuses as just 2 significant figures (example here). BTW - they give the figure as "per ha²"... Robevans123 (talk) 13:05, 18 August 2016 (UTC)
    • That's a different property. The one proposed here is specifically framed in terms of human population density (or is otherwise very badly explained). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:00, 18 August 2016 (UTC)
      • Yes, I meant human population. --Laboramus (talk) 04:46, 19 August 2016 (UTC)
        • @Laboramus: Can you amend the proposal (either the name or description or both) to make this clear (and to avoid people using this property for other population densities)? Also amend the units to "per km²" as per Thryduulf's comment? Robevans123 (talk) 14:58, 19 August 2016 (UTC)
Yes - a human property density may be calculated, but this is fraught with difficulties:
  • to what precision should the result be displayed? Naively this may be derived from the number of significant figures of the population and the area, but many population figures given are themselves estimates, or have instrinsic unknowns (do we know how many households complete a census and how accurately)?
  • what if the population figure and the area data come from different sources and/or different times (boundaries can and do change)?
  • Published figures for population densities are often rounded to a whole number (or sometimes one decimal point). Presumably the Office for National Statistics (Q1334971) have a good idea of what constitutes an appropriate level of precision for the figure to be meaningful and useful.
Wikidata should ideally include verifiable information. If we have verifiable information from a reliable authoritative source, surely we should include that, rather than relying on, for example, a Wikidata enabled infobox, to carry out the calculation (with all the intrinsic problems of displaying appropriate precision that would entail)? BTW - I'd be quite happy for infobox code to carry out the calculation if no population density is available, but it should clearly indicate that it is a calculated value and not a sourced value... Robevans123 (talk) 15:36, 19 August 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

"to what precision should the result be displayed?" that's a matter for the consumer, not Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:44, 19 August 2016 (UTC)
Speaking as a consumer, I'd like a well-sourced figure from a authorative source, thank you very much! Robevans123 (talk) 16:29, 19 August 2016 (UTC)
I'm sorry but, as explained, this would be a derived property, which is currently not supported in Wikidata. In the future, it would be a great idea to show derived values or to save internally some frequently-used derived values in order to increase query performance but, currently, this feature is not available. Symbol oppose vote.svg Oppose. Anyway, many thanks for your feedback. --abián 21:23, 20 August 2016 (UTC)
That's a mistaken claim. The property is not proposed as a derived property. It's quite possible that a source has data on this with higher precision than can be derived with public data. ChristianKl (talk) 13:18, 30 August 2016 (UTC)
It's not about displaying precision but about the inherent precision that the data has. I agree with Robevans123 that a consumer wants well sourced data and wants his data at the precision that a source provides. ChristianKl (talk) 13:13, 30 August 2016 (UTC)
  • Symbol oppose vote.svg Oppose. Redundant, and likely to lower data quality as a result. --Yair rand (talk) 10:32, 24 August 2016 (UTC)
  • Symbol oppose vote.svg Oppose sorry but I still fail to see the need and the usefulness of this property as the value can easily be calculated with two common properties (and BTW, precision is easily calculable too). Cdlt, VIGNERON (talk) 09:28, 29 August 2016 (UTC)
  • Symbol support vote.svg Support Different sources have different rules for calculating precision. If you devide a number with 3 degrees of accuracy by another number with 3 degrees of accuracy you get a number with less degrees of accuracy. If a source publishes population, area and population density all with 3 degrees of accuracy you can't reconstruct the population density that the original source has by doing math.
Given NPOV we should be able to document different view and there's no reason to limit the world in this case. When it comes to making Wikidata easy to use for list making, I also see advantages to having a straightfoward property. ChristianKl (talk) 13:09, 30 August 2016 (UTC)
  • Symbol support vote.svg Support--Mikey641 (talk) 02:46, 21 October 2016 (UTC)
  • I've marked this as ready as it seems to me (although I am neither a property creator nor uninvolved here) that the arguments in opposition to the property have all been addressed - namely that this is not always calculable (a) at all because the source data for the population and/or area concerned is not always known; (b) to the same level of precision if only post-rounding figures are given or the source figures are given to different precisions. I expect a property creator to fully read the discussion and make a determination for themselves though - the "ready" flag is intended as a signal for them to do so. Thryduulf (talk) 14:45, 6 November 2016 (UTC)
  • Symbol oppose vote.svg Oppose redundant. --Gloumouth1 (talk) 14:39, 17 November 2016 (UTC)
    • @Gloumouth1: Why do you think it is redundant in all cases? Please respond to the arguments made above that it is not always calculable - either at all or to the same level of precision. If calculability is not the basis for your opposition, please explain your reasoning further. Thryduulf (talk) 11:56, 18 November 2016 (UTC)

average yearly temperature[edit]

   Under discussion
Description temperature calculated by averaging the minimum and maximum daily temperatures over 30 years in a certain place
Data type Number
Domain instances of geographic region (Q82794) and instances of, recursively, its subclasses
Allowed values from -400 (minimum using degree Fahrenheit (Q42289), near to the absolute zero (Q81182)) to 350 (maximum using kelvin (Q11579), perhaps could be reached inside a volcano)
Allowed units the same as temperature (P2076), that is, degrees Celsius (Q25267), kelvin (Q11579) and degree Fahrenheit (Q42289)
Example Zaragoza (Q10305) → 15.5 °C (according to aemet.es, the Agencia Estatal de Meteorología (Q2826727))
Planned use firstly, importing data for some Spanish municipalities from the Agencia Estatal de Meteorología (Q2826727)
Robot and gadget jobs creating and regularly updating a world map (Q653848) that represents how these values are distributed across the planet
See also temperature (P2076), Köppen climate classification (P2564)
Motivation

Wikidata is lacking in climate data, and the average yearly temperature is a particularly relevant measurement. abián 15:57, 28 August 2016 (UTC)

Discussion
I think that we have a problem.
  1. If we only create a property for the average monthly temperature, we won't be able to get the average yearly temperature if we don't have well-defined data of all months. In some cases, we know the average yearly temperature but not the average monthly one.
  2. If we only create a property for the average yearly temperature, we'll never be able to know the average monthly temperature.
  3. If we create both properties, we should never use both for the same Wikidata item. This situation could be controlled using a {{Constraint:Conflicts with}}.
There isn't a perfect solution. If we usually know the average monthly temperature, I would say 1. If we usually know the average yearly temperature but hardly ever the average monthly one, I would say 2. And, if there's no a "usual" situation, I would say 3. If I would have to choose right now, without being able to talk or to find out about this, I would choose 3. --abián 20:37, 28 August 2016 (UTC)
  • Average monthly temperatures are way more informative than plain yearly average. Whether we create a specific property for this or not, we should think about how bring here monthly averages too, creating a coherent model including the later ones too.
1) Having a specific property for yearly averages and using generic temperature (P2076) 'qualified' with determination method (P459) for the monthly ones would be pretty awkward.
2) Having "average yearly temperature" and "average monthly temperature" using somehow the month as qualifier would make a little more sense. I don't know.
3) Having "average yearly temperature", "average january temperature", and "average february temperature" and... -> no.
Regardless all that, qualifiers as start time (P580) or end time (P582) should be added too. Strakhov (talk) 20:09, 28 August 2016 (UTC)
Option 2 makes much sense. :-) --abián 20:49, 28 August 2016 (UTC)
month of the year (P2922) would work as the qualifier in this scenario. Thryduulf (talk) 22:11, 28 August 2016 (UTC)
We'd need "average maximum temp." and "average minimum temp." too. Recently we approved precipitation height (P3036), but it seems pretty weird, as it represents a point in time, not an average. How about "average montly precipitation height" and "average yearly precipitation height"? Seriously, I think we need to apply here a more holistic view, not proposing one by one. Strakhov (talk) 17:09, 30 August 2016 (UTC)
  • Pictogram voting comment.svg Comment would it be possible to consider instead a property that provides a database of temperatures for the location so that whatever monthly or yearly averages are wanted can be computed from it? It might have to be a URL to a dataset...? ArthurPSmith (talk) 19:19, 30 August 2016 (UTC)
    The average yearly temperatures in a certain decade are fixed values, they won't change. However, external links will probably do, sooner or later. And, as only linking an external database wouldn't be enough to retrieve data from the Wikimedia projects, I think that it's better to directly save these data in Wikidata. --abián 09:16, 2 September 2016 (UTC)
  • Well, sometimes old values do change thanks to reanalyses - or at least in certain datasets they wouldn't be perfectly fixed. In any case, what I think would be best here would be to be able to store the full dataset, say as a CSV file, in Wikimedia Commons. However, Commons doesn't allow CSV or other dataset files at the moment. If we store monthly averages directly in wikidata, then you have 12 statements per year - for some locations there are 150 years or so of data (perhaps more in England?) so you could have 1800 temperature statements on a location item in wikidata under this approach. That doesn't seem like a good idea to me. ArthurPSmith (talk) 15:41, 21 September 2016 (UTC)
  • Per Phabricator:T120452, tabular data storage is coming to Commons at some point. I'm not familiar with what the current state of work on it is. Thryduulf (talk) 20:11, 21 September 2016 (UTC)
  • They wouldn't be 1800 temperature statements in any case. These values are average ones, usually, in a 30-years period, not in a year. --abián 18:11, 22 September 2016 (UTC)

If I'm not wrong, these are the possible Wikidata properties concerning average temperatures and their dependencies.

Deriving average temperatures.svg

These dependencies can be applied, mutatis mutandis, to any kind of average climate data (average rainfall, average relative humidity, average number of frosty days, etc.).

Having read all comments, having done some research, and knowing that these data:

  • have an absolutely different availability depending on the relevance of the place, on the country and on the antiquity;
  • should always be used with qualifiers start time (P580) and end time (P582);
  • should always have a direct reference;
  • are historical and should never change since they are added to Wikidata;

... I propose that we exceptionally assume some degree of duplication with them and that we allow to store multiple declarations using these properties even for the cases that some of them could be derived from others.

For the case of monthly data, declarations should also necessarily have the qualifier month of the year (P2922).

In conclusion, concerning this property, "average yearly temperature", I still think that creating it would be a good idea. --abián 12:25, 2 September 2016 (UTC)

  • Given that it makes sense to fill for almost any place with a location, I think having a specific property for it is warranted. Symbol support vote.svg Support ChristianKl (talk) 18:20, 25 September 2016 (UTC)
  • Pictogram voting comment.svg Comment I think it would be good to have the monthly series of min/max/avg, but I don't think current quantity type and GUI is quite ready for this.
    --- Jura 23:53, 29 September 2016 (UTC)
  • Pictogram voting comment.svg Comment Please see Phabricator:T147049.
    --- Jura 09:03, 30 September 2016 (UTC)

French canton[edit]

   Under discussion
Description french canton of which all or part is all or part of the french commune
Data type Item
Template parameter « canton » in w:fr:Modèle:Infobox_Commune_de_France
Domain instances of commune of France (Q484170)
Allowed values instances of canton of France (until 2015) (Q184188) or canton of France (starting March 2015) (Q18524218)
Example Auxerre (Q167600)canton of Auxerre-Est (Q1724308) (end time (P582) 2015-01-01)
Reims (Q41876)canton of Reims-8 (Q783557)
Planned use Apply to all lines in this SPARQL query, including qualifiers where there are any.
See also Wikidata:Property proposal/territory overlapse
Motivation

As I hope I've demonstrated clearly enough in the introduction to my blogpost on the topic, a french canton (for which, by the way, we have two classes, canton of France (until 2015) (Q184188) and canton of France (starting March 2015) (Q18524218), but fixing that is for another place and another time than this property proposal, and please don't merge them right away, this requires a bit more finesse for data quality) is not technically a fully meaningful located in the administrative territorial entity (P131) for a french commune : some cantons hold exactly several communes and nothing else, while other cantons hold one or more communes and parts of other communes, some only hold parts of two or more communes, some are merely a part of a commune, and some even hold a commune and two different parts of another commune. Yes, french administrative subdivisions do seem like they were created while under the influence of way too much wine ^^'

On top of that territorial meaninglessness, french cantons aren't technically administrative subdivisions, but territories on an electoral map, with no specific administration or local government.

I recently added (and it was the subject of my blogpost) the department of France (Q6465) in which all communes are directly located where missing (as communes are technically grouped into départements and no other entity in between, even though départements can be divided into arrondissement of France (Q194203)), and that was only the beginning of a process intended to provide a clean ontology for subdivisions of France - and perhaps offer a showcase ontology for other countries with messed up subdivisions ? ^^' Alphos (talk) 13:04, 11 September 2016 (UTC)

Discussion
  • Symbol support vote.svg Support-Ash Crow (talk) 15:04, 11 September 2016 (UTC)
  • Pictogram voting question.svg Question Euh, c'est pas très clair, pourquoi "territory overlapse" suffirait pas ? J'ai surtout l'impression que les cantons sont liés techniquement aux départements, et pas tellement aux communes, vu que ça sert à élire des conseillers départementaux. author  TomT0m / talk page 16:58, 11 September 2016 (UTC)
    Symbol oppose vote.svg Oppose until more justification - territory overlapse should do the job, and "cantons" are linked to departments, and not so much to communes. author  TomT0m / talk page 17:02, 11 September 2016 (UTC)
    As with any derivative property, to avoid multiplication of qualifiers in statements, in this case as (P794). Same applies for instance to contains administrative territorial entity (P150) : why would we need it if has part (P527) does the job ? To avoid adding qualifiers when a derivative property does the job. Alphos (talk) 19:18, 11 September 2016 (UTC)
    @Alphos: We don't need a qualifier. Or I don't see why. author  TomT0m / talk page 19:22, 11 September 2016 (UTC)
    @TomT0m: as (P794):canton of France (starting March 2015) (Q18524218), plainly and simply. Alphos (talk) 19:27, 11 September 2016 (UTC)
    @Alphos: We just don't need this, this is redundant. We already know the type of items from their instance of (P31) statements. author  TomT0m / talk page 19:34, 11 September 2016 (UTC)
    You've failed to explain how exactly that purported unneededness differs from that of other derivative properties. I'm not saying the property I'm proposing here isn't redundant with the other one, I'm saying it adds a modicum of information, of specificity, to said redundance. Alphos (talk) 21:14, 11 September 2016 (UTC)
    I hope that after the live discussion we had on another channel this is more clear. author  TomT0m / talk page 06:37, 12 September 2016 (UTC)
  • Symbol support vote.svg Support Il serait sans doute intéressant de prévoir de même de régler le cas des French legislative constituency (Q2973941) qui, étant basées en grande partie sur les cantons d'avant 2015, comprennent elles aussi des communes entières et/ou un ou des fraction(s) de commune(s) (Loire-Atlantique's 2nd constituency (Q3025212) ne comprend qu'un morceau de Nantes (Q12191), Ille-et-Vilaine's 8th constituency (Q3142930) comprend un morceau de Rennes (Q647) et d'autres communes, etc.). Pymouss (talk) 17:16, 11 September 2016 (UTC)
    Je n'y vois pas d'inconvénient. Je n'ai juste pas écrit de post de blog dessus, donc je n'ai pas d'exemple en tête :tongue: Alphos (talk) 19:18, 11 September 2016 (UTC)
    Pour régler les cas de la compositions des cantons, l'Insee a introduit une division utile qu'il appelle la "fraction cantonale" (d'une commune). Les cantons sont donc composés soit de communes entières, soit de fractions cantonales (qui ne correspondent en fait que rarement à la délimitation administrative des quartiers, mais parfois correspond à la délimitation des anciennes communes devenues communes associées (ou communes déléguées dan les "communes nouvelles").
    Dans ce cas la commune qui serait divisée serti composée de fractions cantonales: chaque fraction cantonale n'appartient qu'à une seule commune et à un seul canton. Et il n'y a plus aucune ambiguité: une commune peut alors n'appartenir à aucun canton (si elle en a plusieurs, ou si elles est dans un département ou une COM sans aucun canton), et un canton peut n'appartenir à aucune commune (s'il est composé de communes entières ou fractions cantonales). C'est pas plus compliqué que ça. Mais ça ne l'empêche pas la commune d'être évenutuellement chef-lieu d'un ou plusieurs cantons (même d'un canton dont le chef-lieu ne fait pas partie) et un canton ne pas contenir son chef-lieu. Dans tous les cas pour toute commune on pourra lister le ou les éventuels cantons qui la recouvre.
    En nouvelle Calédonie on a aussi le cas d'une commune qui a deux fractions provinciales (elle est à cheval entre deux provinces). En Espagne on a des tas de cas similaires entre les comarques et les provinces, et me^me dans certains cas des comarques à cheval sur plusieurs communautés autonomes, plus des comarques internationales (une partie en France, l'autre en Espagne, avec une cogestion ou une gestion qui alterne tous les 6 mois). Il y a aussi d'autres cas de territoires cogérés en France, notamment les parcs naturels, le golfe de Gascogne, et une bonne partie de la Méditerranée pour laquelle, hormis les eaux territoriales, les autres zones se heurtent et ne permettent pas d'extension, ou les eaux au large de Gibraltar entre 6 et 12 miles, que l'Espagne revendique au même titre que Gibraltar tout entier, mais où Gibraltar a obtenu les 6 miles mais en se réservant le droit de réclamer les 12 miles (donc Gibraltar s'oppose à la revendication territoriale de l'Espagne, et considère encore qu'entre 6 et 12 miles ce sont des eaux internationales.
    La géographie est une science humaine, pas une science exacte, elle a donc de nombreuses exceptions et complications: on ne peut pas cadrer purement un modèle théorique qui gère 90% des cas mais on doit tenir compte des exceptions (très nombreuses).
    Même en France je vous mets au défi de savoir ce qu'est une "région": selon qu'il s'agit de la collectivité locale ou de l'adminsitration déconcentré de l'Etat ce n'est pas du tout la même chose, et même au sein de l'Etat seul il y a plusieurs définitions, correspondant à des compétences différentes des préfets et tout un tas de lois et accords passés. Et même si les nouvelles régions ont été redessinées, ces différences subsistent: on n'a pas deux régions ayant le même statut, mais juste des cas "d'assimilation" dans certains domaines de la loi. La géographie par définition c'est compliqué à modéliser, depuis toujours. Verdy p (talk) 19:03, 11 September 2016 (UTC)
    Sans intérêt : l'INSEE peut bien faire comme elle veut, ses décisions internes n'ont pas de portée administrative dans le domaine. Et pourquoi donc parle-t-on des régions sur une proposition de propriété concernant les communes et leurs cantons ? Alphos (talk) 19:18, 11 September 2016 (UTC)
    Sans intérêt les définitions de l'INSEE ? alors qu'ells ont une porté légale en France. La définition légale même des cantons s'appuie sur ces fractions cantonales qui sont clairement décrites une par une là où il y en a (ce n'est pas toujours aussi clair concernant le découpage infra-communal des circonscriptions législatives qui s'appuient cependant sur les communes mais aps toujours les mêmes découpages infra-communaux car ces découpages sont liés à des mesures de population légale prise à des dates de référence différentes, selon la date de chaque scrutin à venir et les délais légaux de procédure, il y a des décalages alors selon les années entre ces découpages, eux-mêmes basés sur des éléments plus petits, les IRIS, dans les communes suffisamment peuplées: on passe donc d'un découpage statistique, interne à l'INSEE ou pour certains usages commerciaux ou la planification, à un découpage légal qui s'appuie dessus et qui concernera tout le monde et sera public quand il y a un suffrage universel, et qui aura ensuite un impact long par le fait des élus prenant des décisions aussi concernant les territoires concernés). La fraction cantonale reste donc une division administrative même s'il n'y a pas de collectivité ni d'élections ni élus à son niveau. Elle existe dans les allocations budgétaires des communes concernées.
    Bref la fraction cantonale est bien connue, elle est relativement stable avec le temps (en dehors du renouvellement complet de la totalité des cantons en 2015, événement exceptionnel, les redécoupages pour les élections suivantes les conserve en l'état sur des décennies, et seules quelques grosses communes dont la population varie beaucoup sont redécoupées, mais ce n'est pas toujours nécessaire: on peut sortie ou ajouter une commune voisine aussi: le redécoupage suppose un changement de physionomie significatif de la densité d'habitants au sein d'une commune et le franchissement de certains seuils statistiques qui sont très longs à atteindre et dépasser).
    J'ai aussi parlé des régions car la question initiale était plus large et que le cas des communes et cantons est un cas particulier pour la France, mais pas exceptionnel si on regarde ailleurs ou à un autre niveau (ici on a sorti une partie de la discussion commencée à un niveau plus grand sur une autre page).
    On a d'autres découpages infra-communaux : les quartiers (avec conseils de quartiers), ou unités administratives (regroupement de quartiers pour certaines villes). Mais qui ne s'appuient pas non plus sur le zonage cadastral (qui a des conséquences pour la fiscalité locale applicable) qui conserve la trace des anciennes communes ou des communes déléguées ou associées. Les IRIS qui sont revus en fonction des plans d'aménagement à venir pour étudier leur impact local ou leur efficacité (mais qui intéresse aussi le secteur économique), mais les IRIS n'ont aucune existence administrative, contrairement aux fractions cantonales, quartiers et unités administratives (même si ces dernières ont une portée limitée et aucune autonomie, ils correspondent directement et précisément à la composition légale d'entités administratives ou collectivités plus grandes), et cela marque le terrain. Sans cela on ne peut pas savoir si tel ou tel point est concerné par une entité ou une autre, ou plusieurs (et cela reste vrai qu'on parle de "localisation administrative" ou d'un autre lien comme "géré par" qui pourrait aussi être utilisé pour lier des collectivités avec des organisations privées, y compris dans d'autres pays).
    Je pense que "géré par" est plus un niveau organisationnel, non spécifique aux collectivités, mais à toute organisation (on pourrait aussi avoir "contrôlé par", "majoritairement détenu par", "actionnaires principaux connus", "copropriétaires...", avec toute la difficulté et la complexité des liens liant des organisations entre elles, et même des individus, et le fait que bon nombre de ces relations ne sont pas rendues publiques et n'ont pas légalement à l'être le plus souvent car on tombe dans le droit privé et même l'INSEE est tenu légalement de garder le secret statistique et doit donc agréger certaines données) et ça n'a rien à voir avec la territorialité (au sens géographique), plus avec la propriété, la'argent et la responsabilité légale (on ne parle plus de territoires mais de personnes). Pourtant les entités territoriales ont bien des compositions précises en sous-territoires qui les composent, même si ces sous-territoires n'ont pas tous une existence administrative autonome, ils sont nécessaires pour modéliser ces données essentielles (sinon plus moyen de décrire précisément les entités territoriales mères). Verdy p (talk) 10:15, 12 September 2016 (UTC)
    Ça m'a pas l'air si compliqué que ça. Plusieurs entités administratives peuvent se partager la gestion d'un même territoires ou de différents aspect d'un territoire. Le statut différent des régions ça ne change pas le fait que l'administration les définit comme des régions. À mon avis déjà en séparant les territoires et leur gestion administratives on évite un beau bordel. En ayant une relation "administré par" qui lie les territoire à l'administration et en évitant les trucs mal définis comme "situé dans", ce serait un pas dans la bonne direction. author  TomT0m / talk page 19:11, 11 September 2016 (UTC)
    Mon cher Philippe, je n'ai lu que la première phrase de ta réponse, le reste n'étant sans doute pas dénué de sens, mais n'ayant, comme d'habitude, qu'un rapport très lointain avec la question. La question posée par Alphos est : « La propriété located in the administrative territorial entity (P131) est souvent renseigné dans les fiches des communes par le canton of France (until 2015) (Q184188) et/ou le canton of France (starting March 2015) (Q18524218) correspondant. Or, dans un certain nombre de communes, cet élément n'est pas supra-communal mais infra-communal. Apparaît-il donc pertinent de créer une nouvelle propriété pour ne pas perdre cette information dans Wikidata tout en évitant des incongruités comme "Fougères (Q4043) est localisé dans canton of Fougères-1 (Q17354607) et dans canton of Fougères-2 (Q17354608)" ? ». Voili, voilou, Pymouss (talk) 20:29, 11 September 2016 (UTC)
  • Symbol support vote.svg Support parce que la situation actuelle avec located in the administrative territorial entity (P131) est juste impraticable et inutilisable, ce qui est logique la propriété located in the administrative territorial entity (P131) porte sur la localisation alors que le lien entre une commune et un canton porte sur la composition. Avec et , on a l'impression que la commune de Rennes (Q647) est entièrement comprise dans les deux cantons, ce qui est évidemment faux et il est impossible de distinguer la relation entre les deux cantons par rapport à Rennes. On pourrait peut-être se passer de located in the administrative territorial entity (P131) et utiliser has part (P527) et part of (P361) (cela a déjà été discuté d'ailleurs mais aucune solution n'a été trouvée) ; une nouvelle propriété spécifique me semble encore la meilleure solution (ou a minima, la moins pire). VIGNERON (talk) 20:40, 11 September 2016 (UTC)
    Utiliser has part (P527)/part of (P361) impliquerait de "scinder" les communes en fractions de communes, donc de créer les entités pour chaque fraction de commune, indiquant quelle partie de quelle commune appartient à quelle commune et quel canton. C'est une solution malsaine pour une base de données généraliste, et c'est justement pour ça que j'ai proposé les deux propriétés (la générique et la spécifique). Elles n'impliquent pas de lien d'inclusion, simplement un lien de corrélation territoriale partielle ou totale entre deux entités de nature différente - pour l'une sans précision quant aux entités, pour l'autre limitant complètement les classes auxquelles elles appartiennent. Alphos (talk) 21:03, 11 September 2016 (UTC)
    Le truc c'est que "localisation administrative", en réalité, ça n'a pas une granularité suffisamment fine. La localisation administrative d'un truc dépend largement de l'administration concernée, et en pratique chaque organisme découpe le territoire à sa convenance - le découpage de la CAF n'est pas forcément celui des hopitaux ou des pompiers. Du coup en fait avec "localisation administrative" on mélange des choux et des carottes. C'est pareil pour les sous-divisions : les cantons sont techniquement des divisions plus des départements que des communes. Il conviendrait donc de ne pas les lier aux communes. La solution d'avoir une propriété générique pour dire que deux subdivisions qui n'appartiennent pas vraiment au découpage de la même administration se chevauche me convient, par contre - mais ça n'a rien de spécifique aux départements. Du coup je ferai de la pub à Wikidata:Property_proposal/lower_rank_than qui a pour but justement de spécifier les hiérarchie entre les différents types d'entités :) author  TomT0m / talk page 06:37, 12 September 2016 (UTC)
  • Symbol oppose vote.svg OpposePictogram voting comment.svg Comment Use located in the administrative territorial entity (P131). Scope of P131 allows past and present entities. Set the current ones to preferred rank. If a city contains several cantons, the canton should use P131 with the city, not the other way round.
    --- Jura 10:19, 12 September 2016 (UTC)
    Changed oppose to comment. If it can help you sort it out .. -- Jura 09:33, 14 September 2016 (UTC)
    Jura1 (talkcontribslogs) having two different structures to deal with same things is quite disturbing. Even though, how do you do when a canton is above a commune and under the next commune ? (a not-so-exceptional case). Finaly, you say « If a city contains several cantons » but you make a mistake, cities are *always* divided into sevaral cantons, that's what make them cities ;) Cdlt, VIGNERON (talk) 13:52, 12 September 2016 (UTC)
    Jura1 (talkcontribslogs), You seem to have not understood a single thing I said. French cantons can partially overlap with communes. I can give you the example of canton of Reims-8 (Q783557), which has parts of Reims (Q41876) (two distinct parts, actually), but isn't entirely fitted in it. Or canton of Cannes-1 (Q16627298), which overlaps with a part of Cannes (Q39984) and a part of Le Cannet (Q207967). As such, none of these are true :
    Additionally, cantons are not technically administrative locations, they don't hold an administrative value in and of themselves, have no local government or specific administration, they only exist as structures in an electoral map.
    On top of that, it would be preferrable to have a consistent relationship between communes and cantons, if anything to query the database in an easier fashion.
    As explained before and now again, located in the administrative territorial entity (P131) is not the appropriate way to show a relationship between a french canton and a commune.
    Alphos (talk) 13:59, 12 September 2016 (UTC)
    The first two seem correct. P131 can include partial parents. I just can't see the sense of it if one includes subentities in P131 as on [1].
    --- Jura 15:06, 12 September 2016 (UTC)
    Correct? Really? I'm not even sure if it's internally correct fro Wikidata, do you have any discussion agreeing on partial inclusion? (It seems illogical; I've never header of it and I can't find any relevant discussion). And externally, this is "not even wrong", or at least too imprecise to be useful and meaningless. The whole structure is senseless and undocumented, don't you want to improve the situation. Cdlt, VIGNERON (talk) 15:26, 12 September 2016 (UTC)
    Here to some extent. I also found 2 old ones. -- Jura 11:25, 13 September 2016 (UTC)
    Personally, I think the situation on Q39984&oldid=374196864#P131 is incorrect. Given that at least 20 contributors have looked into it, I wonder how it's being justified.
    --- Jura 15:32, 12 September 2016 (UTC)
    We seems to all agree that located in the administrative territorial entity (P131) is globally misused for french territorial entities, but yet nearly nobody seems to really want to improve the situation... Cdlt, VIGNERON (talk) 15:46, 12 September 2016 (UTC)
    I fixed some 100 entries the other day. Maybe we should start limiting disussions to people who demonstrated an interest in working out a solution.
    --- Jura 22:46, 12 September 2016 (UTC)
  • Symbol oppose vote.svg Oppose The French canton concept doesn't fit the French commune concept so this is useless to try to match these 2 concepts. We have 2 independent structures and so this is not a correct idea to try to link the structures together. Sometimes it is not possible to represent completely the reality and in that case it is best to avoid to use the current structure system in a bad way. The only good solution would be as proposed by Alphos to increase the granularity of the classification system to reach the fraction of communes which can be linked to both commune and canton concepts. Snipre (talk) 12:52, 12 September 2016 (UTC)
    And yet, you won't see a single comprehensive documentation of a commune without a mention of which canton(s) it relates to. You misunderstood me at least partly : granularity is not a good idea, as communal fractions are structures strictly internal to INSEE, and hold no value outside its "walls" : it is merely the way INSEE chose to represent these relations, and it doesn't bear more merit than a direct relation in a generalist database such as Wikidata - not to mention it would require an additional level of complexity and would "hide" the canton-commune relations. Alphos (talk) 13:59, 12 September 2016 (UTC)
    And in the other way round, the territory of a canton is always legally defined by its communes (or subpart of them), see Décret n° 2014-177 du 18 février 2014 portant délimitation des cantons dans le département d'Ille-et-Vilaine for a representative example. We can't say that they are "independent" or "doesn't fit". Maybe fraction of communes can help here but I fell like located in the administrative territorial entity (P131) is the true problem here. Cdlt, VIGNERON (talk) 15:43, 12 September 2016 (UTC)
    @VIGNERON, Alphos: Ce n'est pas parce que l'INSEE fait une grosse approximation en mélangeant le concept de commune dans son intégralité et avec celui de fraction de commune que WD doit faire pareil. WD est une base de données que les humains et les machines doivent pouvoir utiliser. Or avec le genre d'approximation que fait l'INSEE, on ne peut plus appliquer des règles de logique nécessaire à la construction de requêtes. Avec la structure de l'INSEE, comment je fais pour déterminer la population d'un canton ? Je ne peux pas sommer la population de toutes les communes faisant partie d'un canton, car cela n'est pas vrai. Encore une fois, WD utilise des concepts et une donnée est valable pour l'entier du concept. C'est comme Bonnie et Clyde: il y a des données qui correspondent uniquement à Clyde, certaines uniquement à Bonnie et d'autres enfin uniquement au duo de personnes que sont Bonnie et Clyde. WD utilise 3 éléments pour cela. Si le canton ne s'applique qu'à une partie d'une commune, la logique de WD est de créer un élément pour la partie de la commune concernée et un autre pour la commune dans son intégralité. C'est pourquoi je m'oppose à cette propriété: elle crée une relation qui n'est vraie que partiellement et qui demande une information qui n'est pas disponible dans l'élément pour pouvoir interpréter correctement les données présentes. En clair, cette propriété ne permet pas de distinguer si une commune fait entièrement d'un canton ou que partiellement, ce qui change beaucoup de chose dans la manière d'utiliser les données des communes pour pouvoir extrapoler des données pour les cantons ou l'inverse, genre population ou superficie. Snipre (talk) 22:14, 13 September 2016 (UTC)
    @Snipre: Comment, dans l'état actuel des choses, extrapoles-tu la population des cantons de Cannes-1 ou Reims-8 (ou tant d'autres) à partir des populations des communes qu'ils recouvrent partiellement ? Alphos (talk) 06:47, 14 September 2016 (UTC)
    Cette propriété ne cherche qu'à améliorer le signifiant de la relation entre commune et canton, qui à l'heure actuelle ne reflète pas la réalité de la relation, qui n'est pas celle d'une subdivision administrative. Alphos (talk) 06:47, 14 September 2016 (UTC)
    @Alphos: Merci de relire ma première intervention: je ne veux pas extrapoler la population des cantons à partir de celles des communes puisque ma position est de ne créer aucun lien entre les communes et les cantons. C'est ta proposition de conserver ce lien entre commune et canton qui pose problème, car elle crée une relation partiellement vraie et c'est elle qui crée des absurdités du genre de celle que je mentionne concernant la population. Si on voulait être juste, on devrait lier la commune et le canton et indiquer via des qualificatifs dans quelle mesure ce lien est vrai et quelle proportion de la commune est touchée par la relation commune-canton.
    Non, ta proposition n'améliore rien puisqu'elle ne permet pas de dire si la commune est totalement incluse dans le canton et si ce n'est pas le cas, quelle partie de la commune est touchée par la relation que tu as créée. L'absence d'informations est préférable à l'existence d'informations partielles dans le cas present, car l'existence d'informations partielles peut entraîner des conclusions fausses, (genre du celle de la population), alors que l'absence d'information oblige à aller chercher l'information correcte à la bonne place. Snipre (talk) 12:33, 14 September 2016 (UTC)
    @Snipre: La situation actuelle, basée sur located in the administrative territorial entity (P131) / contains administrative territorial entity (P150) cause ce problème, en décrivant des inclusions là où il n'y en a pas. La situation actuelle laisse supposer que :
    • les cantons se chevauchent
    • la population d'un canton est exactement la somme des populations des entités qui "le composent".
    • la population d'une commune est au plus égale à la population du plus petit des cantons dont elle "fait partie".
    La propriété que je propose résoud ce problème, en remplaçant l'implication d'inclusion par une implication d'intersection (aux sens mathématiques des termes).
    Ma propriété :
    • ne laisse pas supposer que les cantons se chevauchent
    • ne laisse pas supposer que la population d'un canton est exactement la somme des populations des entités qui "le composent"
    • ne laisse pas supposer que la population d'une commune est au plus égale à la population du plus petit des cantons auxquels elle est liée
    • permet néanmoins d'assurer que :
      • la population d'une commune est mathématiquement comprise entre 0 et la somme des populations des cantons liés.
      • la population d'un canton est mathématiquement comprise entre 0 et la somme des population des communes liées.
    Comme je l'ai déjà indiqué dans ma première réponse, la mention des cantons est toujours présente sur toutes les documentations de communes que j'ai pu voir (guides touristiques, dictionnaires, encyclopédies). Ne pas l'indiquer serait rendre Wikidata moins complet que possible. Et quite à l'indiquer, pourquoi vouloir faire croire les trois faussetés que laisse entendre le système located in the administrative territorial entity (P131) / contains administrative territorial entity (P150), décrites dans la première des listes ci-dessus ? Autant indiquer qu'il y a un rapport territorial partiel (rien de plus) dénotant une intersection mathématique plutôt qu'une inclusion mathématique, et c'est précisément ce qu'indique cette propriété, qui dérive de la propriété canton français.
    Alphos (talk) 13:46, 14 September 2016 (UTC)
  • Symbol strong support vote.svg Strong support, parce que located in the administrative territorial entity (P131) est une absurdité pour relier une commune à un canton, les cantons n'étant absolument un découpage administratif mais uniquement électoral... :)  – The preceding unsigned comment was added by Hsarrazin (talk • contribs) at 13 septembre 2016 à 20:28‎ (UTC).
    Il n'y a pas besoin de créer cette propriété pour ne pas lier une commune et un canton par located in the administrative territorial entity (P131) See with SQID. author  TomT0m / talk page 18:35, 13 September 2016 (UTC)
  • Pictogram voting comment.svg Comment by the proponent. As it seems lots of people have trouble grasping why we need that property, I'll add this : just because two entities happen to have encompassed a same given piece of territory at some point in their respective existences, does not mean they existed concurrently or had a direct relationship to one another. This property adds that precision to the proposed generic property « territory overlapse » : not only did they encompass a same given piece of land, but :
    • they encompassed a same given piece of land, without one being technically in the other administratively - they just happen to have common ground, which may or may not mean the territory of one is entirely in the other, nor that the territory of the other is entirely in the one.
    • one (the source) is a Tei (Q484710)
    • the other (the destination) a french canton
    • they existed at the same ti-me
    • and there was a meaningful direct correspondance between the two, with the canton determined to be one of the cantons of the commune.
    It is a specific property, derived from a generic one, with a specific set of statements carrying a specific meaning, with more significance than the generic property allows ; and it betters the ontology by allowing consistency among all communes and cantons.
    I hope this clears things out.
    Alphos (talk) 20:54, 13 September 2016 (UTC)
    @Alphos: I think we should think through the timeline and contemporarity-problems before taking an actual decision. Technically I'm inclined to think the generic version should have the same contemporary(ty) constraint to make it actually useful. So I don't remove my opposition yet - I'd rather put this in the other proposition.
    author  TomT0m / talk page 08:46, 14 September 2016 (UTC)
    @TomT0m: It really shouldn't. I can give you the example of the 60 no label (Q16629323), which were replaced by 48 revolutionary section of Paris (Q1255087), themselves replaced by 12 municipal arrondissement (Q702842) (before Paris expanded in 1860 to 20 of them, with a redrawing). Why shouldn't we say which municipal arrondissement (Q702842) a no label (Q16629323)'s territory overlaps ? Does it not bear meaning ? It's even been described in ISBN 2713213452.
    For instance, district 40 (Saint-Jacques-du-Haut-Pas) partially overlaps section 46 (Observatoire), which partially overlaps current arrondissements 5, 13 and 14. But district 40 overlaps neither current arrondissement 5 nor 13 (see pages 14-15, and a good map of today's arrondissements).
    On another note, would you mind waiting for the answer to questions you ask or remarks you raise before doing anything else ? I think it's particularly rude, shows you don't give a darn about getting an answer from people who are trying to explain something to you.
    Alphos (talk) 09:41, 14 September 2016 (UTC)
    @Alphos: Euh, je comprend pas ce que tu me reproches, j'ai jamais dit que ça n'avait pas de sens ???? Et j'ai prévenu que j'allais aussi porter la question ailleurs. author  TomT0m / talk page 09:50, 14 September 2016 (UTC)
  • Symbol support vote.svg Support very useful for mapping French territory. Léna (talk) 10:34, 14 September 2016 (UTC)
  • "and that was only the beginning of a process intended to provide a clean ontology for subdivisions of France - and perhaps offer a showcase ontology for other countries with messed up subdivisions ? " If that's the intended goal, I see no reason to create this property as being specific to France. I would like a property that's more general and can be used in multiple countries. Currently I see no arguments brought forward in this thread that this property needs to be specific to France (my French isn't good enough to understand the French posts). Therefore I Symbol oppose vote.svg Oppose ChristianKl (talk) 21:09, 16 September 2016 (UTC)
    @ChristianKl To all that I know, there is no other country which have a division similar to french canton so it makes sense to have a property specific to france. Xavier Combelle (talk) 20:04, 17 September 2016 (UTC)
    @ChristianKl: Unlike the other property I proposed, this property offers the added meaning that its target has its territory specifically defined with a reference to the territory of its source. An canton that doesn't exist anymore can overlap the territory of a newly created commune, which could be an appropriate use of « territory overlapse » (optionally, but I strongly recommend it, with a duration (P2047) no value qualifier), that doesn't mean it was defined according to part of all of the territory of the newly created commune. On the other hand, a canton defined with a reference to a given commune MUST be linked with a property that not only forbids no value for a duration (P2047) qualifier, but also determines a fairly specific spatial relationship from one to the other (one being a canton of the other, which is a commune). Its use is specific to France territorial subdivisions, so it can prove hard to grasp for people who aren't fully aware of the intricacies of our different kinds of subdivisions and the relationships between two of them. Like any derived property, it's intended to avoid adding specific qualifiers to statements that can be shortened for clarity and specificity. It's for the same reason that we have start time (P580) instead of point in time (P585) with a as (P794) start time (Q24575110) qualifier.
    Also, what Xavier Combelle just said ^^' Alphos (talk) 20:07, 17 September 2016 (UTC)
"Unlike the other property I proposed, this property offers the added meaning that its target has its territory specifically defined with a reference to the territory of its source" to me that doesn't seem to be a requirement that's specific to French Cantons and it should be possible to create a property that includes it. ChristianKl (talk) 21:23, 17 September 2016 (UTC)
@ChristianKl: If we don't define this property, we'll be facing a few issues :
  • it also imparts that the target is defined as a french canton and the origin a french commune ;
  • those two classes only exist in France ;
  • it would be silly to add as (P794) "french canton" (I know I should use a class instead of a string in my sentence, but there's currently an issue with french canton classes : we have two instead of one or three, which is another issue that needs resolving) to more than 40 000 statements ;
  • it would also require documenting the difference between {a new commune and old canton having lapsed over the same bit of territory} and {a commune and canton that existed at the same time, one being defined as overlapping the other} which would dictate when to use as (P794) "french canton" and when not to even if the source is a french commune and the target a french canton, which is a very strenuous distinction ;
  • it's would be an oddly specific distinction to make on a rather unspecific property.
I hope you'll understand. Alphos (talk) 08:34, 18 September 2016 (UTC)
The elements that are the origin should have instance of (P31) "french commune" filled and the items that are the target "french canton". Properties aren't supposed to define instance of (P31).
On the other hand I don't see a property shouldn't both care about existing at the same time and lapsing over the same bit of territory. We can have an additional property for that relationship. ChristianKl (talk) 16:21, 18 September 2016 (UTC)
No, but some properties do have constraints on both the source and target of statements that use them. This property is specifically there to impart a special kind of relationship between entities belonging to two specific sets, relationship that isn't plainly limited to an overlapse, but is an outright definition of one from one set derived from a bunch of portions of territory of one or more from the other set. Look, I'm not saying this is sane, I'm saying it describes the situation aptly. And yes, that means the situation is insane, and that's precisely why we need a specific property for it. Please don't dismiss it by lack of knowledge of it.
Alphos (talk) 19:28, 18 September 2016 (UTC)
Given what's written here in English I don't see the specialness demonstrated. Maybe you want to reformulate the definition to express more clearly what's special of this relationship? Generally properties are supposed to be defined, so that people can easily learn what they are supposed to mean. ChristianKl (talk) 20:35, 20 September 2016 (UTC)
The border of each canton is defined as regards to borders of commune(s) and/or to streets belonging to commune(s). However, they're not (anymore) an administrative territorial subdivision, nor are communes necessarily located in them, as per the examples of Reims, Tours, Cannes.
A property like territory overlaps (P3179) could do the trick, but has a non-negligible inconvenient : it doesn't make the difference between these situations :
  • an extant canton defined using extant communes
  • an old canton defined using still extant communes
  • an extant canton once defined using old communes
  • an old canton defined using old communes
  • an old canton that happened to have a territorial overlap with new communes, without coexistence
  • a new canton that happens to have a territorial overlap with old communes, without coexistence
While the last two could of course use territory overlaps (P3179), the first four would benefit from the property being proposed, which imparts coexistence, definition of one using part or all of the territory of the other(s), the source of the statement being specifically a commune and the target specifically a canton defined "from" it. It is undeniably a property derived from territory overlaps (P3179) (proposed at the same time), but one that adds a modicum of specificity to the relation between two entities that territory overlaps (P3179) alone cannot impart.
I can't make it any simpler than this. I should point out the fact that five people (and me) who know of the situation, some of which are heavily committed to handling french territorial subdivisions feel there is an advantage to a more specific property than territory overlaps (P3179) - maybe it's a sign of something.
Alphos (talk) 12:35, 21 September 2016 (UTC)
I have withdrawn my oppose but I would still like this to be better documented in the description of the property. ChristianKl (talk) 10:17, 22 September 2016 (UTC)
@ChristianKl: Please note that we definitely can restore the generality if we create a generic property with the same constraints about temporality - still unfortunately unexpressed by the proposal as you wrightly note - to a generic "overlap in the period of existence" property. This would make this solution similarly applicable to non-french or french similar administrative mess than new and old cantons. Also note that, after discussions with Alphos on different channels, his objection to do this is mainly the fact that a canton can be recreated later - with the same name. My oppinion is that in such a case this recreated canton should have its own item as it can totally can be considered as a new entity - not the same timespace, and probably not the same rules. author  TomT0m / talk page 17:48, 22 September 2016 (UTC)
@TomT0m: In short : no, my objection to your alternative proposal has nothing to do with canton re-creation, and it never had. Please don't try to lend me opinions I never had, and I promise not to say you oppose this property because of circus animals - obviously also unrelated to your opinion. Please read my above comments for further information on the matter, I'm not about to copy and paste them again. Alphos (talk) 22:53, 22 September 2016 (UTC)
@Alphos: Please don't tease me about my attitude, I feel it really innapropriate here. I'll ask you about examples of the stuffs we can't model with the generic property with contemporary contraint, so that we can discuss them. In short, do the long version. author  TomT0m / talk page 06:20, 23 September 2016 (UTC)

located at street address[edit]

   Under discussion
Description full street address that the subject is located at. Include building number through to post code
Represents street address (Q24574749)
Data type Monolingual text
Example 24 Sussex Drive (Q217304) --> 24 Sussex Drive, Ottawa, Ontario, Canada (English) + 24, promenade Sussex, Ottawa, Ontario, Canada (français)
Motivation

To replace located at street address (P969). The datatype needs to include the language since the "text" for a same street address will be different in different languages. All statements located at street address (P969) should be merged to that new property and the old one deleted once it's done. Thanks, Amqui (talk) 16:46, 19 September 2016 (UTC)

Discussion
  • Symbol support vote.svg Support Seem a good Idea. In multilingual country like Canada, the adresses are generally not labeled the same way in French and English. (ex.. 24 Sussex Drive (Q217304) --> 24 Sussex Drive (English) + 24 promenade Sussex (français)) --Fralambert (talk) 21:50, 19 September 2016 (UTC)
  • Question: Would we also use this for postal addresses which are not street addresses, such as companies who use a PO Box? Also, the examples given do not match the description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 20 September 2016 (UTC)
    Same use as the current located at street address (P969). Amqui (talk) 13:41, 20 September 2016 (UTC)
  • Is it possible to change the datatype of a property without creating a new one? Deryck Chan (talk) 14:07, 20 September 2016 (UTC)
    • no, except for string->external-id --Pasleim (talk) 14:31, 20 September 2016 (UTC)
  • I don't think "Ottawa, Ontario, Canada" is what someone would expect from a street address. I would prefer renaming to postal address if that's included. ChristianKl (talk) 16:00, 21 September 2016 (UTC)
    description says all the way to postal code, it's the same as existing located at street address (P969) which is called located at street address. Amqui (talk) 17:28, 21 September 2016 (UTC)
  • Pictogram voting comment.svg Comment How about using a qualifier for "language" in the cases where this is needed?
    --- Jura 10:59, 26 September 2016 (UTC)
    • Symbol oppose vote.svg Oppose That approach avoids adding lang to all existing statements.
      --- Jura 05:45, 5 October 2016 (UTC)
  • Symbol oppose vote.svg Oppose until it is made clear how this relates to located on street (P669) and street number (P670). --Sebari (Srittau) (talk) 21:49, 29 September 2016 (UTC)
  • Pictogram voting comment.svg Comment these distinctions keep being added for no apparent benefit, and increasing complexity (and annoyance). When adding a street address for a place of death is it really necessary to add this specific detail? For what benefit? Please express how the current component is not sufficient and the added value for users in the proposal.  — billinghurst sDrewth 06:34, 5 November 2016 (UTC)
    To expand … the Dictionary of National Biography often adds street address, or something equivalent to a death place. So these references to older locations should be qualified, but they will not have all the additional detail about postcodes etc., so the schema needs to be able to manage old data not tie us into a 21st century paradigm.

waterbody ID (Germany)[edit]

   Under discussion
Description identifier for bodies of water in Germany
Represents Fließgewässerkennziffer (Q1428658)
Data type External identifier
Template parameter GKZ in de:Vorlage:Infobox Fluss
Domain bodies of water
Allowed values [1-69][0-9]{0,9}
Example Rhine (Q584) → 2, Heusiepen (Q1616544) → 27366462
Source various sources, e.g. http://www.lfu.bayern.de/wasser/gewaesserverzeichnisse/doc/tab_alle.xls, http://www.lanuv.nrw.de/fileadmin/lanuv/wasser/pdf/Gewaesserverzeichnis%20GSK3C.xls
See also SANDRE ID (P1717) (for rivers which flow through both France and Germany)
Motivation

We currently have Gewässerkennzahl (P1183) based on the GKZ parameter of de:Vorlage:Infobox Fluss. As I originally wrote in Property talk:P1183#Is_this_really_a_single_thing.3F, I can find no evidence of this being a single identifier. The format used appears to be an invention by the German Wikipedia to allow multiple unrelated identifiers from different countries to share the same infobox parameter. We already have country-specific properties for some of the IDs. Other countries appear to have more than one set of IDs. I think the right thing to do is to identify the individual systems and split P1183 into separate properties for each one. If people agree that this is the right approach, I'll create more proposals for the other systems I've been able to identify.

This proposal is for the system in Germany described at de:Gewässerkennzahl (Deutschland). I haven't been able to find any central source for these, only various PDFs or spreadsheets from individual states, but the Wikipedia page says it's a country-wide system.

The corresponding tag in OSM is ref:fgkz (while we can't import directly from OSM, maybe we can still use it to find missing OpenStreetMap Relation identifier (P402) statements).

- Nikki (talk) 12:50, 26 October 2016 (UTC)

Discussion
  • Symbol support vote.svg Support ChristianKl (talk) 17:16, 6 November 2016 (UTC)
  • BA candidate.svg Weak oppose I don't see the point - you haven't identified a formatter URL that can be used to link these so this would be an external id without a link. And Gewässerkennzahl (P1183) uses a DE/ prefix for at least the German numbers, it seems, so there shouldn't be ambiguities here. Have you talked to the German wikipedia people about this? ArthurPSmith (talk) 21:53, 7 November 2016 (UTC)
    Responding to the different points:
    • Formatter URLs are useful but they're not required and it's not uncommon to not have one (roughly every 1 in 6 of the external identifier properties does not have one).
    • The point is that we're storing multiple unrelated identifiers as a single property using an invented format to (try to) make them unambiguous and I can't see how that can possibly be a desirable situation. "DE/" is not part of the identifier and if we corrected the identifiers, they would be ambiguous. If P1183 were being proposed today, we would almost certainly reject it because it's not a single identifier, it's not even a coherent set of identifiers, it's just a dumping ground for any identifiers which haven't got their own property and that's not a good approach to structured data.
    • I haven't talked to the German Wikipedia people about it... I'm not sure what you think I should say to them. They don't use our data for this, so it doesn't affect them and even if they did want to use it, they would already need to combine multiple properties together because we don't use P1183 for identifiers which have their own property. We also don't use the exact format the German Wikipedia uses, e.g. the GKZ parameter on de:Rhein is "CH/1/DE/2/FR/A---0000" (which means the Swiss code is "1", the German code is "2" and the French code (SANDRE ID (P1717)) is "A---0000"), but we don't enter "CH/1/DE/2/FR/A---0000" as the value for P1183.
    - Nikki (talk) 16:53, 8 November 2016 (UTC)
  • Ok, I've changed my oppose to a "weak" one. I don't see that this change really brings any benefit (for example just having 3 separate entries for this property for de:Rhein would seem fine to me and essentially match what the German wikipedia people are doing) but if this sort of thing has been done for other id's of this sort I guess I don't strongly object to making this change. ArthurPSmith (talk) 18:46, 14 November 2016 (UTC)
    • I think P1183 looks like a single identifier, but I don't think it is. In the meantime, I think the US identifiers have already been assigned to GNIS. FR and RU already have their own properties --- Jura 19:31, 8 November 2016 (UTC)

coextensive with[edit]

   Under discussion
Description this item has the same boundary as the target item
Data type Item
Domain primarily administrative divisions and geographic features like islands
Example
Motivation

I often come across pairs of items for places which share the same boundary but cannot be merged (even if we wanted to) because both have a sitelink for the same wiki. It is usually different levels of administrative divisions or an administrative division which is the same as an island or island group. We have properties like located in the administrative territorial entity (P131) and located on terrain feature (P706) for saying that one is in the other and said to be the same as (P460) for saying that two things are sometimes considered the same, but none of those mean that they are coextensive.

- Nikki (talk) 18:04, 3 December 2016 (UTC)

Discussion
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:37, 3 December 2016 (UTC)
  • Symbol support vote.svg Support said to be the same as (P460) could maybe be used for this but I think this is a better approach to make explicit the basis for the relationship. ArthurPSmith (talk) 14:12, 5 December 2016 (UTC)
  • Pictogram voting comment.svg Comment What about using
    subject > said to be the same as (P460) See with SQID object or value >
    criterion used (P1013) See with SQID < items share the same boundary >
    ? That's the canonical way to make explicit the basis of a relationship, no? --Azertus (talk) 11:13, 7 December 2016 (UTC)
    • I'm not keen on that because stating that two things share a boundary is not the same as claiming they are actually the same thing - it would not feel right to me to add a reference to a said to be the same as (P460) statement if the source only says that they are coextensive.
      Using a qualifier also makes it harder to work out how to add the data correctly (even if you add "coextensive" as an alias for P460, that doesn't tell you you need to add a qualifier or what the value of the qualifier should be), more work to enter (needs more steps and you have to remember which qualifiers/values to use, versus just writing "coextensive" in the property search box), harder to add constraints (they would have to be complex ones) and harder to query (you would always have to check the qualifiers).
      I don't really see an advantage to using a qualifier here on a vaguely defined property when we could have a simple clearly defined property. :) - Nikki (talk) 12:21, 7 December 2016 (UTC)
Symbol support vote.svg Support That sounds reasonable! --Azertus (talk) 17:35, 7 December 2016 (UTC)

Wilderness.net ID[edit]

   Ready <create>
Description identifier for an American wilderness area in the Wilderness.net database
Represents Wilderness.net (Q16948419)
Data type External identifier
Domain wilderness area (Q2445527) in the United States of America (Q30)
Allowed values \d+
Example
Source http://www.wilderness.net
Formatter URL http://www.wilderness.net/NWPS/wildView?WID=$1
Motivation

Wilderness.net (Q16948419) is the reference database when it comes to wilderness area (Q2445527) in the United States of America (Q30). The proposed property would be a new Wikidata property related to protected areas (Q27642681). The mix'n'match catalogue ID (P2264) would be 301. Thierry Caro (talk) 23:05, 3 December 2016 (UTC)

Discussion

EdouardHue
VIGNERON
Yodaspirine
Thierry Caro

Pictogram voting comment.svg Notified participants of Wikiproject France/Protected areas. @Fralambert: you may also have a look. Thierry Caro (talk) 23:05, 3 December 2016 (UTC)

protected areas of Canada ID[edit]

   Under discussion
Description identifier of a protected area of Canada used by the Canadian Environmental Sustainability Indicators
Data type External identifier
Domain protected area (Q473972) in Canada (Q16)
Allowed values \d{9}
Example
Source http://maps-cartes.ec.gc.ca/indicators-indicateurs/TableView.aspx?ID=10&lang=en
Formatter URL http://maps-cartes.ec.gc.ca/indicators-indicateurs/detailPage.aspx?lang=en&type=pa&objectid=$1
Robot and gadget jobs link them via Mix n' match
See also WDPA id (P809)
Motivation

The database give the land area (terrestrial and marine), the province, the creation date, the UICN category and the ecoregion of a protected area of Canada. There is about 8049 id in the database. The mix'n'match catalogue ID (P2264) will be 302. --Fralambert (talk) 04:18, 4 December 2016 (UTC)

Discussion

Klosterdatenbank[edit]

   Under discussion
Description entry in the Germania Sacra Klosterdatenbank
Represents Klosterdatenbank (Q27960389)
Data type External identifier
Domain monasteries
Allowed values string
Example Marienstift (Q1646116)2077
Format and edit filter validation 2-5 digit number
Source http://klosterdatenbank.germania-sacra.de
Formatter URL http://klosterdatenbank.germania-sacra.de/gsn/$1
Motivation

This 'monastery database' (not an official English name) edited by one of the oldest and most ambitious research projects in church history has information on monasteries (former or still existing) located in the territories of the Holy Roman Empire, from the 8th century until the beginning of the 19th century. It is still being expanded and aims at eventual completeness. But already it the best online authority control for its subject. Jonathan Groß (talk) 10:17, 5 December 2016 (UTC)

Discussion

basic unit of settlement code (Czech/Slovak)[edit]

   Under discussion
Description code given to each basic unit of settlement (smallest administrative entity, below municipality) in the Czech Republic or Slovakia
Represents basic unit of settlement (Q329245)
Data type External identifier
Domain administrative entities in the Czech Republic and Slovakia
Allowed values 1-1000000
Example Chořelice (Q11727381) → 52787
Source official register
Planned use import some of them automatically and allow other Wikipedians to add the rest according to Czech Wikipedia's category system for basic units of settlement
See also Czech neighbourhood ID code (P2788)
Motivation

For cs:základní sídelní jednotka.

This was raised as a key issue in the improvement of Czech template for parts of municipalities. Vojtěch Dostál (talk) 21:31, 6 December 2016 (UTC)

Discussion

National Wildlife Refuge System ID[edit]

   Under discussion
Description identifier for a National Wildlife Refuge on the United States Fish and Wildlife Service website
Represents National Wildlife Refuge System (Q22959610)
Data type External identifier
Domain National Wildlife Refuge (Q1410668)
Allowed values string
Example
Source https://www.fws.gov/refuges
Formatter URL https://www.fws.gov/$1
Motivation

The United States Fish and Wildlife Service (Q674113) has an entry on its website for every National Wildlife Refuge (Q1410668) in the National Wildlife Refuge System (Q22959610). It would be great if we could have a dedicated property for this. Thierry Caro (talk) 06:51, 10 December 2016 (UTC)

Pictogram voting comment.svg Comment. Most of the identifiers have refuge/ at the begnning, but not all are as such. Thierry Caro (talk) 09:31, 10 December 2016 (UTC)
Pictogram voting comment.svg Comment. The mix'n'match catalogue ID (P2264) would be 310. Thierry Caro (talk) 10:35, 10 December 2016 (UTC)
Discussion

EdouardHue
VIGNERON
Yodaspirine
Thierry Caro

Pictogram voting comment.svg Notified participants of Wikiproject France/Protected areas. @Fralambert: you may also have a look. Thierry Caro (talk) 06:51, 10 December 2016 (UTC)

  • About 50, or 9% of the total. Thierry Caro (talk) 17:54, 10 December 2016 (UTC)