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 Sports 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 2017/05.

Place[edit]

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 Quantity
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)
    • +1 Climate data is needed on Wikidata. The RedBurn (ϕ) 11:53, 15 February 2017 (UTC)
  • @Abián, Thryduulf, ChristianKl, Jura1: Commons now has tabular data; I strongly suggest that instead of this proposal we propose a "temperature dataset" property with datatype "Commons media" to allow for whatever temperature data is available to be linked to a location. ArthurPSmith (talk) 16:15, 10 January 2017 (UTC)
    • Pictogram voting comment.svg Comment Obviously, this is only marginally related to average yearly temperature, but I don't quite see the difference between gifs at Commons and Commons datasets. Neither allow us currently to do comparisons with other locations. Given that quantity datatype has gotten more efficient in terms of resources, we might try a single property for temperatures.
      --- Jura 16:42, 10 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose use tabular data on Commons. Average yearly temperature is only single quantity out of many relevant ones for climate data. Average/min/max yearly/monthly/daily temperature/precipitation are others. We should find a solution which works for all these quantities. Here it should become clear that Wikidata is not the right place for it. Climate data are tabular data and the developers decided to store tabular data on Commons and not on Wikidata, so let's use Commons. A demo is already online: en:User:Yurik/WeatherDemo using the data stored on commons:Data:Ncei.noaa.gov/weather/New York City.tab. --Pasleim (talk) 16:54, 11 January 2017 (UTC)
Pictogram voting comment.svg Comment How many dimensions data should have when we call it "tabular"? Geographic dimension represented using items.
Census data have 3 dimensions right now: location, point in time, sex.
It is possible to get 50+ dimensions from census information, we need only selection of dimensions on Wikidata, not complete 1-to-1 dumps.
Pictogram voting comment.svg Comment If we use .csv / .tabs on commons, then I would like to have a property about "tabular data available on commons"; and with qualifier about topic ("Climate data"). d1g (talk) 03:19, 14 January 2017 (UTC)
That is far too generic. It would be like having a property called "string" that we use for all strings. - Nikki (talk) 18:19, 31 January 2017 (UTC)
  • Pictogram voting comment.svg Comment this is my first time at the property proposals page, so I'm going to keep things to a comment for now. I was just editing Q21726404, and I was looking for a property for annual temperature. There are tons of bot-generated pages on the Swedish Wikipedia, for example the bot generated page for the item I just mentioned. The bot found structured data to make that page, so I feel that Wikidata could have a viable property for this. Icebob99 (talk) 14:53, 16 February 2017 (UTC)

coordinate reference system[edit]

   Under discussion
Description coordinate (or spatial) reference system used to determine the coordinates of a location on Earth (default: WGS84) or some other globe
Represents spatial reference system (Q161779)
Data type Item
Domain coordinates on earth or any planet or natural satellite
Allowed values instances of spatial reference system (Q161779)
Example
Motivation

I thought we had a property for this for use a qualifier with coordinate location (P625), but it seems that we do not. Strictly speaking, coordinates - even on Earth - are meaningless without knowing the coordinates referencing system (CRS, also known as "spatial reference system" or "reference frame", see also geodetic reference system (Q1502887)) used - the usual one for coordinates on Earth is World Geodetic System 1984 (Q11902211) but one or more versions of each of International Terrestrial Reference System (Q74561), North American Datum (Q993433) and European Terrestrial Reference System 1989 (Q1378197) also exist, for example. The importance of specifying the reference system can be seen from [2], which gives several coordinates on the moon, and says "Differing results come from different models with different solutions. Currently, the lunar geoid is being redefined with Clementine data, so the location (latitude, longitude, and elevation) of everything will change again very soon. In short, we know where each of the [Lunar Modules] is located is relation to local landmarks; but assignment of latitude and longitudes to those locations is an evolving process.". Geo URI (Q5533943), for example, incudes a parameter for the CRS, see en:Geo URI scheme#Coordinate reference systems.

It may be assumed that, where not stated, the CRS for coordinates on Earth is WGS84, as that is used by most online mapping systems, GPS devices, and by the various WMF projects' mapping services. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:37, 9 January 2017 (UTC)

Discussion
  • Symbol oppose vote.svg Oppose redundant to existing qualifier for other property and unstructured when used in conjunction with P625.
    --- Jura 08:38, 10 January 2017 (UTC)
  • Pictogram voting comment.svg Comment This is a similar problem like with elevation above sea level (P2044) which is basically also meaningless without knowing the reference point. There it was decided to use determination method (P459) which seems to work quite well. --Pasleim (talk) 10:17, 10 January 2017 (UTC)
    • If we start adding values in P625 for places on Earth that are not using the default this just gets messy. I'm not sure why Pigs changed their mind on this. The earlier suggestion to use separate properties seems much more sensible.
      --- Jura 10:36, 10 January 2017 (UTC)

Happy to agree to this proposal. I understand that this will provide a link to an existing standard. Well done. Thanks, GerardM (talk) 14:22, 10 January 2017 (UTC)

I support the proposal and offer Washington Monument (Q178114) as an example. The most accurate value may not be stated in WGS84. The most desirable outcome would be to transform the coordinates into WGS84, or the nearly identical ITRF. The available qualifiers to specify that this was done, and how it was done, are sparse. The determination method property could be used to specify that a transformation was performed, and the proposed property could be used to state what coordinate system the value was transformed into. The untransformed value, of course, would be found in the referenced source. (An editor who won't be bothered referencing the source has no business transforming coordinates.) Jc3s5h (talk) 18:10, 10 January 2017 (UTC)

On further reflection, I think the user interface should be corrected to permit entry of the globe, and display whatever globe was chosen. Ideally editors would transform the value as necessary to ITRF or WGS84 and specify one of those as the globe, but if the editor didn't now how, they could specify whatever globe was used and leave it for a subsequent editor to do the transformation. It could also allow the entry of coordinates for features on other planets to be made through the user interface. Jc3s5h (talk) 18:29, 10 January 2017 (UTC)

Is there a Phabricator ticket for this proposed change to the interface? And an ETA for delivery? How does the later compare to the potential for having the proposed proerty in place in seven days or so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:48, 10 January 2017 (UTC)
If the property is approved, what would your plan be to undo all the non-Earth globe fields that already exist, and remove globe from the data model (which, in the case of JSON, itself requires a Phabricator ticket)? Jc3s5h (talk) 22:09, 10 January 2017 (UTC)
I would do neither. For several globes, as well as Earth (e.g. Moon, Mars) there is more than one CRS. For each, we can assume or declare a default, but this proposal allows the specification of another. This proposal is not mutually exclusive with yours, and yours is not a reason not to do this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:14, 10 January 2017 (UTC)
I have created a Phabricator ticket in line with my response above, but it turns out there was already a Phabricator on the issue. Jc3s5h (talk) 22:30, 10 January 2017 (UTC) updated 11:48 11 January 2017 (UTC)
  • Pictogram voting comment.svg Comment, not sure if it should be a property or not… Embedding the coordinate system in the coordinnates, like it's done for the globe, would probably be better but as the globe is still not implemented in the interface right now (and it's causing several problems, like people adding earthly coordinate outside of Earth), I'm reluctant and hesitant. Cdlt, VIGNERON (talk) 10:58, 11 January 2017 (UTC)
  • Pictogram voting comment.svg Comment The more I think about it, the less happy I am with this proposal. For much of the 20th century, latitudes and longitudes in the UK were stated with reference to OSGB36 -- typically this gives a point on the ground about 100 to 150 metres away from where WGS84 would indicate. I am not at all happy with the thought of OSGB36 coordinates being used with P625, even when marked with a qualifier. I think we should maintain an insistence that all terrestial coordinates are converted to WGS84, so that this is the only scheme for terrestial coordinates that is acceptable as an argument for P625. Otherwise we are demanding that any use of P625 data must check the qualifiers and must be prepared to do coordinate conversions. As well as being a complete millstone, it's simply not realistic to expect this of data users. Most SPARQL searches don't even check qualifiers at all.
Instead I could see value in a qualifying the data with a qualifier "originally stated as" + a qualifier "original coordinate system", if we want to record how the data may have been originally presented in a given source. Jheald (talk) 21:56, 22 January 2017 (UTC)

SIMC ID[edit]

   Under discussion
Description identifer for places in Poland, in the System identyfikatorów i nazw miejscowości
Represents System for IDs and names of places (Q9326104)
Data type External identifier
Template parameter SIMC at pl:Szablon:Wieś infobox
Allowed values \d+
Example Gruszczyce (Q1834225) → 0697900
Robot and gadget jobs Import from Wikipedia
Motivation

(Add your motivation for this property here.) GZWDer (talk) 17:22, 16 January 2017 (UTC)

Discussion

river code in Romania[edit]

   Under discussion
Description official identifier for a river in Romania
Data type External identifier
Template parameter |cod-râu= in ro:Format:Infocaseta Râu
Domain river in Romania
Allowed values unclear
Example Scărișoara River (Q4713663) → VI.2.3
Source Wikipedia
Robot and gadget jobs Probably
Motivation

(Add your motivation for this property here.) GZWDer (talk) 19:03, 16 January 2017 (UTC)

Discussion
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:11, 16 January 2017 (UTC)
  • Pictogram voting comment.svg Comment We have an existing catch-all property for codes for rivers: Gewässerkennzahl (P1183). The code for Scărișoara River (Q4713663) can already be entered by adding "RO/VI.2.3" as the value for Gewässerkennzahl (P1183). If you think that that is the wrong thing to do, please consider supporting my proposal to start splitting that property into separate identifiers. - Nikki (talk) 18:15, 22 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose until this has been more clearly identified. We don't know what the IDs look like, we don't know who assigns them nor do we have any external sources we can use to verify them, so how can we know when this property is the right one to use? I do support adding properties for individual identifiers (see the proposal I linked above) but adding properties for template parameters without understanding what the parameter contains is how we ended up with Gewässerkennzahl (P1183) in the first place. - Nikki (talk) 18:15, 22 January 2017 (UTC)

Golf course rating[edit]

   Under discussion
Description The course rating of a particular course is a number generally between 67 and 77 that is used to measure the average "good score" by a scratch golfer on that course
Data type Number (not available yet)
Template parameter course1 at en:Template:Infobox Golf Facility
Domain golf course
Allowed values number
Example Riviera Country Club (Q7338863) → 75.6
Robot and gadget jobs probably
Motivation

(Add your motivation for this property here.) GZWDer (talk) 09:33, 17 January 2017 (UTC)

Discussion
Pictogram voting comment.svg Comment probably should be "golf course rating"? Wouldn't want to confuse this with university courses for instance. ArthurPSmith (talk) 17:37, 18 January 2017 (UTC)
Agreed.--GZWDer (talk) 15:40, 24 January 2017 (UTC)
I changed the name to "Gold course rating". ChristianKl (talk) 12:29, 5 February 2017 (UTC)
  • BA candidate.svg Weak oppose with current proposal due to ambiguity. What is the intended determination method (P459) to be used with this property? "scratch rating", "slope rating" and/or something else? Are ratings calculated the same on golf courses around the world? How is the subjective nature of these ratings recorded in Wikidata? (i.e. who and how did an organisation or person decide what the rating would be). Dhx1 (talk) 17:18, 8 February 2017 (UTC)

TC LID[edit]

   Under discussion
Description Transport Canada assigns two, three, and four character identifiers, including three letter identifiers beginning with letters Y and Z, for its areas of jurisdiction
Data type External identifier
Template parameter |TC= in en:Template:Infobox airport
Domain places in Canada
Allowed values [A-Z0-9]{2,4}
Example Fort Macleod Airport (Q3914377) → CEY3
Robot and gadget jobs probably
Motivation

(Add your motivation for this property here.) GZWDer (talk) 09:47, 17 January 2017 (UTC)

Discussion
  • The name isn't descriptive enough. ChristianKl (talk) 12:30, 6 February 2017 (UTC)

hydraulic head[edit]

   Under discussion
Description hydraulic head of a dam
Represents hydraulic head (Q369743)
Data type Number (not available yet)
Template parameter |plant_hydraulic_head= in en:Template:Infobox dam
Domain dam
Allowed values <1000m
Allowed units metre (Q11573), foot (Q3710)
Example Grand Coulee Dam (Q930391) → 380ft
Robot and gadget jobs probably
Motivation

(Add your motivation for this property here.) GZWDer (talk) 18:51, 17 January 2017 (UTC)

Discussion
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 17 January 2017 (UTC)
  • Symbol support vote.svg Support --Fralambert (talk) 23:27, 17 January 2017 (UTC)
  • BA candidate.svg Weak oppose What kind of determination method (P459) would need to exist to specify how the head was measured? Is it the "effective head" (factoring in losses)? In a hydroelectric dam, is the head determined to be the mid-height of the top of the penstock (Q1260995) minus the mid-height of the mill race (Q736691) outlet? Perhaps it's measured down to the top of the Draft tube (Q12050991)? Without this level of engineering specification, values of this property could mean many different things to different people. I agree in principle with the need for a property such as this one proposed, and will change my vote to one of support if further clarification is provided on the expected determination method (P459) which are proposed to be used as mandatory qualifiers to this property. Dhx1 (talk) 16:46, 8 February 2017 (UTC)

height above average terrain[edit]

   Under discussion
Description a measure of how high an antenna site is above the surrounding landscape
Represents height above average terrain (Q1295906)
Data type Number (not available yet)
Template parameter HAAT at en:Template:Infobox broadcast
Domain transmitter (Q190157)
Allowed units m
Example MISSING
Robot and gadget jobs From Wikipedia
Motivation

(Add your motivation for this property here.) GZWDer (talk) 18:12, 16 January 2017 (UTC)

Discussion

delimits/marks out[edit]

   Under discussion
Description The element is on the border/limit of another.
Represents delimitation (Q27555163)
Data type Item
Domain geographic location (Q2221906)
Example
Motivation

This property could say that a mount, a mountain pass... is on the limit of a valley. For example,

< Pic de la Fossa del Gegant (Q3382408) View with Reasonator View with SQID > located on terrain feature (P706) View with SQID < Carança valley (Q28380499) View with Reasonator View with SQID >

is not satisfying (is the mountain part of the valley?) nor precise enough. You may want to know that an object lies just on the border of the valley, not in the middle. If many items had this property, a simple query on wikidata could create an approximate map of the shape of valley. El Caro (talk) 14:40, 18 January 2017 (UTC)

Discussion
  • Symbol support vote.svg Support Me semble être une bonne idée. Faudrait peut être aller dans le sens inverse? soit Trois‐Rivières (Q44012) --> Saint Lawrence River (Q134750) Il me semble que ¸a va éviter de surcharger les rivière et les lacs. --Fralambert (talk)
  • Symbol support vote.svg Support. Thryduulf (talk) 22:04, 14 April 2017 (UTC)
  • This seems to be a pretty basic property and therefore it's worth to spend some effort to get it right. What the prior art of how this relationship is called and described in other ontologies? ChristianKl (talk) 17:17, 18 April 2017 (UTC)

designation[edit]

   Under discussion
Description less formal names, where "official name" is less appropriate
Data type Monolingual text
Domain place
Example Norra Visby (Q2061978):sv:Gustavsvik+Annelund
See also official name (P1448)
Motivation

When I work with småort (Q14839548) in Sweden. I use data from Statistics Sweden (SCB). SCB has never given these entities any real names. In the first report from 1990: Småorter 1990 (Q20087097) it is described that the official authorities who usually gives names to places never thought it was a good idea to set names to these entities. (SCB is not that authority.) Therefor SCB gave them "beteckningar", designations which are more of descriptions than real names. Those could look like "Gustavsvik+Annelund", "Uppsala:5", "Skärted + Sprängsviken + del av Nänsjö" or "Malnbaden (västra delen)". As you see, combinations of village names, municipality names, lake names, order number and such things as "parts of" or "northern part" can be found in these designations. This far, I have used official name (P1448) here, but it often looks very awkward, since they neither are "official" or real "names". As you can see in the latest SCB-report: no label (Q28048805), SCB have stopped adding these designations to these entities. We now have to find other sources to name these entities.

My first interest here are our småort (Q14839548), but I would not oppose this property to be used in other places. My use of P1448 can be relocated to a new property by a good botoperator. They all have the same group of source, and most of them has as (P794):Q14839548 as qualifier. -- Innocent bystander (talk) 20:10, 18 January 2017 (UTC)

Discussion
  • Comment: "Designation" can mean "heritage stats", in British English (and others?). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 27 January 2017 (UTC)
    @Pigsonthewing: You can feel free to rename the proposal to something better in English. The Swedish word here is "beteckning", a word that can describe that a "name" is more of a serial number or description than a real name protected by the cultural heritage authorities. -- Innocent bystander (talk) 18:35, 27 January 2017 (UTC)
  • Pictogram voting comment.svg Options Maybe "name" or simply "quote" could work.
    --- Jura 07:33, 28 January 2017 (UTC)
    Place names (in Swedish, Finnish and a few other languages) are protected by the Swedish cultural heritage laws and authorities. These are not "names" in that sense. But it is definitely an option. -- Innocent bystander (talk) 11:48, 28 January 2017 (UTC)
    @Innocent bystander, Pigsonthewing, Jura1: would "designated name" work? Thryduulf (talk) 22:06, 14 April 2017 (UTC)
    @Thryduulf: I think it would! -- Innocent bystander (talk) 08:10, 15 April 2017 (UTC)

OSM admin level[edit]

   Under discussion
Description level of administrative layer in OSM
Data type String
Domain subclass of administrative units or single instance that constitutes the level (notably for level 2)
Allowed values 2-11 (in theory 1-12). Generally, there would be one item with a specific level for each country, unless two (or more) different types of administrative units without a commons class get the same level
Allowed units none
Example
Source http://wiki.openstreetmap.org/wiki/Key:admin_level
Motivation

Should help improve integration with OSM. I would be glad to get some feedback from OSM before this is created.
--- Jura 08:23, 28 January 2017 (UTC)

Discussion
  • Pictogram voting comment.svg Comment datatype should be integer, but string is probably easier to convert than "quantity".
    --- Jura 08:23, 28 January 2017 (UTC)
    • I'm not sure that the quantity datatype is the best choice because OSM values are always strings. While the existing documented values can be represented as integers, there are no restrictions on the values (as you can see from the existing values for the admin_level key) and while it's probably rather unlikely, there is nothing to stop OSM introducing levels which can't be represented using the quantity datatype in the future. - Nikki (talk) 15:40, 31 January 2017 (UTC)
      • @Nikki: Ok. I changed it to string.
        --- Jura 06:14, 27 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose This is unnecessary. Either use "higher"/"lower", as proposed elsewhere, or series ordinal (P1545), qualified with an item for, e.g. "hierarchy of places in USA". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:24, 28 January 2017 (UTC)
    • Pictogram voting comment.svg Comment To help people check if this could work, would you do two of the samples from the proposal with your alternate tentative suggestion?
      --- Jura 23:53, 28 January 2017 (UTC)
      • How do you suggest I "do" a sample, using a proposed property? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:46, 30 January 2017 (UTC)
        • Add Sandbox-String (P370) to a couple of items and use query.wikidata.org ?
          --- Jura 06:14, 27 February 2017 (UTC)
          • I guess Pigsonthewing suggest something like : . Indeed I think it's more than enough. Cdlt, VIGNERON (talk) 13:05, 7 March 2017 (UTC)
            • Well, we can just guess, but we don't really know if it works. So you'd drop the "qualifier only"-constraint on P1545? Not really convincing.
              --- Jura 13:22, 7 March 2017 (UTC)
              • The guessing was related to Andy suggestion not to the practicability/workability. But I think my suggestion works quit well, can you give a counter-example (even just a basic example first). Did you look at the state of the documentation (in general) and "qualifier only"-constraint (in particular) on P1545? Cdlt, VIGNERON (talk) 14:08, 7 March 2017 (UTC)
                • Sure. Why do you ask that? Why do you want to change it?
                  --- Jura 14:16, 7 March 2017 (UTC)
                  • So you did see that it as inconsistent, contradictory (the examples given violating the only constraints) and nearly inexistent (only one constraint, seriously...). I don't *want* to change it but it's *needed* as impossible rules could not be followed. Anyway, that's a minor point, other (and maybe better) properties could probably be used and you didn't point anything wrong in the structure I proposed. Cdlt, VIGNERON (talk) 11:20, 9 March 2017 (UTC)
                    • I don't quite see how your thing could work out, but if the two of you think it works for you, you probably want to go ahead with it. Supposedly you could list your constraint violations as exceptions .. In case the outcome would work for me as well, I'd withdraw this proposal.
                      --- Jura 21:08, 9 March 2017 (UTC)
  • Pictogram voting comment.svg Comment how would it help to improve integration with OSM? Isn't the documentation page you gave on the wikiOSM more than enough? Cdlt, VIGNERON (talk) 13:05, 7 March 2017 (UTC)
    • Make it possible to identify the layers and query them on Wikidata? Maybe overpass could do that, but somehow I doubt that.
      --- Jura 13:22, 7 March 2017 (UTC)
    • Sorry but I fail to see what you want and why you want it. What are you calling layer here? (I can only assume you're not talking about Key:layer). If you can ask a clear question, I can try to translate it in the overpass language. Cdlt, VIGNERON (talk) 14:08, 7 March 2017 (UTC)
      • Determine the OSM admin level for a given item.
        --- Jura 14:16, 7 March 2017 (UTC)
        • Obviously, but could you give some details or a concrete example. By the way, on your 4 examples, the third seems a bit off (at least, Poland (Q36) is not an administrative level/layer/whatever) and what don't you gave an item for the fourth (osiedle (Q2277441) I imagine but maybe there is a trick or a trap). Cdlt VIGNERON (talk) 11:20, 9 March 2017 (UTC)

PASE Domesday place[edit]

Description Identifier for a settlement in 1066 or 1087 on the PASE Domesday website
Data type External identifier
Domain settlements in England and Wales
Example Axminster (Q792596)vill=Axminster
Devon (Q23156)shire=Devon
Compton (Q5157132)vill=Compton&shire=Surrey
Format and edit filter validation (vill|shire)=.+
Source http://domesday.pase.ac.uk/
Formatter URL http://domesday.pase.ac.uk/Domesday?op=6&$1
See also PASE Domesday person ID (proposed), OpenDomesday settlement ID (P3118)
Motivation

To link places to the standardised form needed to retrieve records for them on the PASE Domesday website.

See the PASE Domesday person ID proposal for more about the PASE Domesday project, and comparison with Open Domesday. Jheald (talk) 16:52, 8 February 2017 (UTC)

Discussion

https://www.wikidata.org/wiki/Wikidata:Property_proposal/PASE_Domesday_person_ID

Building name[edit]

   Under discussion
Description Building name
Represents no label (geographic location (Q2221906))
Data type Monolingual text
Domain Place
Example Q1141267, Q5476713
Planned use should be an identifier of address location
Motivation

The goal is to define the name (or surname) of a building or a place. By example headquarters location for Thomson Reuters is 3 Times Square but it's also the name of the building itself en:3 Times Square. The same thing for the new Apple Park Gdgourou (talk) 11:04, 24 February 2017 (UTC)

Discussion
  • @Gdgourou:If I misunderstand what you want to do with the property, how about providing a clear example in the usual format that we have examples in property proposals? ChristianKl (talk) 23:33, 2 March 2017 (UTC)
I think the existing property official name (P1448) would be suited for this. Best to use a generic property, if one exists. Also, "official name" is the label used by the Skyscraper Center website, see http://www.skyscrapercenter.com/building/reuters-building/2809 Danrok (talk) 15:55, 28 February 2017 (UTC)
@ Danrok, yes but official name (P1448) could not be a link to a qualifier --Gdgourou (talk) 16:26, 2 March 2017 (UTC)
I don't understand what "could not be a link to a qualifier" means. Danrok (talk) 23:09, 2 March 2017 (UTC)
Sorry, not enough familiar with Wikidta. I try to have a dedicated field in which the value could be a Qxxxx link (like 3 Times Square (Q4636552)) in the Headquarter block of data (exemple Thomson Reuters). --Gdgourou (talk) 05:59, 3 March 2017 (UTC)

@Gdgourou: The thing is you can replace New York City (Q60) with 3 Times Square (Q4636552) as a value for headquarters location (P159). It's completely fine, and you don't need to use qualifiers. Yarl ✉️️  08:35, 3 March 2017 (UTC)

@Yarl: yes but in this case, it will genreate conflict in some infoboxes as the P159 is often a city (or local place) like in the fr:Modèle:Infobox Société --Gdgourou (talk) 09:33, 3 March 2017 (UTC)
@Gdgourou: I understand your point, but please take a look here, we should link to most specific item possible. It should be possible to extract city/country from entry about building. Yarl ✉️️  09:47, 3 March 2017 (UTC)

District[edit]

   Under discussion
Represents Thanjavur (Q41496)
Data type Item
Template parameter en:Thanjavur
Domain Administrative division
Example Thanjavur (Q41496) or Pattukkottai (Q7148673)
See also Again for assembly constituency too we need to add district in [3]

qualifier electoral district (P768); property located in the administrative territorial entity (P131)

Wikidata:Property proposal/french canton
Motivation

Currently we use property located in the administrative territorial entity (P131) but this often confusing. Should have seperate property to identify the place by its division. Thanks -- Mdmahir (talk) 09:11, 12 March 2017 (UTC)

Discussion
  • Symbol support vote.svg Support as "electoral district of place". It would have the same values as the qualifier electoral district (P768), but be applied to places in countries where located in the administrative territorial entity (P131) aren't of much use, due to Gerrymandering and other issues.
    --- Jura 10:19, 18 March 2017 (UTC)
  • Symbol oppose vote.svg Oppose No evidence is given as to why located in the administrative territorial entity (P131) and/ or electoral district (P768) are not adequate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 19 March 2017 (UTC)
  • Currently, the suggested datatype "string" doesn't seem to make sense to me. As far as the example goes, an example is supposed to say which items is supposed to be mapped to which other item. I also share Pigsonthewing's concerns that no reasoning is given why the existing properties don't do the job, so BA candidate.svg Weak oppose. ChristianKl (talk) 19:03, 25 March 2017 (UTC)
    • Yeah, string makes no sense. I changed it to item.
      --- Jura 19:08, 25 March 2017 (UTC)
  • @Mdmahir: Please can you respond to the query above regarding why the existing properties don't work and also provide an example of how the property will be used (not just examples of items it will be used on). Thryduulf (talk) 21:09, 14 April 2017 (UTC)

SSB urban settlement number[edit]

Description Numeric ID for urban settlements in Norway assigned by Statistics Norways (SSB)
Data type External identifier
Template parameter population in no:mal:tettsted
Domain populations in urban settlements in Norway
Allowed values numbers
Example Sagvåg (Q1890945) - 5056
Format and edit filter validation 4 digit number with leading zeros (\d{4})
Source http://www.ssb.no/286024/tettsteder.folkemengde-og-areal-etter-kommune.1.januar-2016
Planned use Collect the settlement number from Wikidata instead of typing it into manually into the template


Motivation

The 4 digit number is used in the template tettsted, which again is used in the tempate infoboks tettsted. This value could be collected from Wikidata if this property is created. Cavernia (talk) 19:08, 12 March 2017 (UTC)

Discussion
  • Comment: @Cavernia: The example ({{tettsted|5056}}) is not clear. To which Wikidata item does "5056" relate? {{tettsted|5056}} renders, on no.Wikipedia, as 3 472. From where is that figure derived, and what does it represent? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:49, 19 March 2017 (UTC)
  • Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 20 March 2017 (UTC)
  • The property currently lacks a description and thus is not ready. What's the authority for the ID? ChristianKl (talk) 12:50, 22 March 2017 (UTC)
The authority is Statistisk Sentralbyrå, the official Norwegian bureau of statistics. --Cavernia (talk) 08:26, 29 March 2017 (UTC)

number of houses[edit]

   Under discussion
Description number of houses in given territorial entity
Data type Quantity
Template parameter |počet domů= in cs:Šablona:Infobox - česká obec and similar templates
Domain human settlement (Q486972) and its subclasses
Allowed values \d+
Example Dubská Lhota (Q11834492) → 23 (+point in time (P585) → 2011)
Source Infoboxes, external references (census)
Planned use Use in infoboxes
See also population (P1082), number of households (P1538)
Motivation

Currently these data are inserted using has part (P527) + house (Q3947) and quantity (P1114), but that seems to me overcomplicated and hard to use by infoboxes. Jklamo (talk) 16:36, 21 April 2017 (UTC)

Discussion

Good idea!Frettie (talk) 16:45, 21 April 2017 (UTC)

Symbol support vote.svg Support Matěj Suchánek (talk) 17:14, 21 April 2017 (UTC)

Vitaskrá ID[edit]

Description identifier of an Icelandic lighthouse or beacon in Vitaskrá, a list of lights by the Icelandic Coast Guard
Represents Vitaskrá (Q29562346)
Data type External identifier
Domain sea mark (Q7321258)
Allowed values [1-9]\d*
Example Kópasker Lighthouse (Q3378290) → 184
Source http://www.lhg.is/media/sjomaelingar_islands/Vitaskra_010616_vefutg.pdf
Motivation

This List of lights (Q843152) contains the Icelandic lighthouses and beacons with additional info such as light characteristic, range, focal height, structure height and coordinates. It is used/mentioned in enwiki as "country number" in Template:Infobox lighthouse (Q13384512) for Icelandic lighthouses (with prefix "VIT-"), although not many times. A better idea of potential use is seen at Wikidata:WikiProject Lighthouses/lists/lighthouses by country/Iceland - I intend to eventually add the codes to all of those lighthouse items. Lymantria (talk) 08:39, 24 April 2017 (UTC)

Susannaanas

Jura
Lymantria


Pictogram voting comment.svg Notified participants of WikiProject Lighthouses

Discussion

shield image[edit]

   Under discussion
Description Official shield (Q131559) image. See also flag image (P41), seal image (P158) and coat of arms image (P94).
Data type Commons media file
Template parameter "image_shield " in en:template:infobox settlement
Domain Various places and persons
Allowed values Image files for commons.
Example GivatiBrigade.svgGivati Brigade (Q1528778), Escudo de Moca, Puerto Rico (Estados Unidos).jpgMoca (Q2288079)
Source external reference, Wikipedia list article
Motivation

Like flag image (P41), seal image (P158) and coat of arms image (P94). We will also need a description property like flag (P163), seal description (P418) and coat of arms (P237). Xaris333 (talk) 13:59, 19 April 2017 (UTC)

Discussion

INSPIRE ID[edit]

   Ready <create>
Description universal identifier from Infrastructure for Spatial Information in the European Community (INSPIRE), used across EU databases
Data type External identifier
Domain places in European Union
Allowed values [^\s\/]+
Example
See also Natura 2000 site ID (P3425) (this identifier is included in INSPIRE ID for Natura 2000 sites, see example above)
Motivation

This is universal identifier introduced as a part of INSPIRE directive in the EU. There is no central repository for it but it is unique, standardized ID used across EU databases. Sorry for Polish examples only, but they are the easiest to find for me.

I see that right now it's used for sure in two areas: heritage monuments and Natura 2000. For N2K you can see more examples here. For INSPIRE implementations per country you can take a look here. Yarl 💭  14:54, 6 May 2017 (UTC)

Discussion
Symbol support vote.svg Support sounds like a good idea, but the name should be a little more descriptive as there are other things called "INSPIRE" - maybe "INSPIRE spatial infornation ID"? ArthurPSmith (talk) 18:15, 8 May 2017 (UTC)
Symbol support vote.svg Support I fully support. I have not got round to proposing it, mainly because I have not looked into the complexity of INSPIRE things. So I also support changing the name slightly to more descriptive. This is a very useful feature for Wiki Loves Monuments items, a major part unless all of them have INSPIRE IDs. – Susanna Ånäs (Susannaanas) (talk) 06:41, 14 May 2017 (UTC)
On a second thought, I think INSPIRE ID will work just fine! Could it be possible to create the property. I would need it today :) Cheers, Susanna Ånäs (Susannaanas) (talk) 11:38, 18 May 2017 (UTC)
Symbol support vote.svg Support Yes please. --John Cummings (talk) 19:08, 18 May 2017 (UTC)
Symbol support vote.svg Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:29, 18 May 2017 (UTC)
Symbol support vote.svg Support Halibutt (talk) 06:49, 19 May 2017 (UTC)
@Yarl: For me the domain of the property isn't clear. Can you fill out that field? ChristianKl (talk) 18:03, 19 May 2017 (UTC)
  • Added, but happy to see more detailed domain, because I not quite sure of scope of INSPIRE ID. Yarl 💭  10:13, 20 May 2017 (UTC)
  • Looking into the docs: INSPIRE has 34 themes/categories, of which protected sites is one. See documentation. The data requirements may vary so much that probably it would be best to scope with protected sites. – Susanna Ånäs (Susannaanas) (talk) 08:58, 21 May 2017 (UTC)
  • I also found this presentation to verify that "protected site" is the theme to choose. I did not find documentation about how the IDs are constructed across themes, whether it would be necessary to have 34 different INSPIRE IDs. – Susanna Ånäs (Susannaanas) (talk) 09:32, 21 May 2017 (UTC)

Pictogram voting comment.svg Comment The INSPIRE IDs are transitioning to a URI schema instead of the above described "old format". The INSPIRE URI seems pretty generic and suitable for all themes, it includes a section for the theme and a class. I have national recommendations at hand, still need to find proper English/international documentation. Basically, briefly referenced here, the format is http:/{domain name}/{URI type}/{dataset id}/{theme}/{class}/{local id}/[{version id}] and consists of:

  • URI type = "id" for a geographic feature, "so" for spatial object, "def" for concept/definition and "doc" for documentation.
  • dataset id = locally, on national level, assigned repository id
  • theme and class from INSPIRE classifications
  • local id = mandatory local id for the geographic item
  • versionId (not mandatory) = the version identifier of the geographic feature 
Susanna Ånäs (Susannaanas) (talk) 04:44, 23 May 2017 (UTC)

Racon signal[edit]

Description signal that a radar beacon responds in morse code, when triggered by radar
Represents Racon (Q568424)
Data type String
Template parameter |racon= in en:Template:Infobox lighthouse (Template:Infobox lighthouse (Q13384512))
Domain mark (Q17852731)
Allowed values [A-Z]
Example Bjørnsund Lighthouse (Q879885) → B
Motivation

Several buoys and lighthouses have a Racon (radar beacon) that is transmitting a single letter code in morse, when triggered by a (ship's) radar. This letter would be a helpful addition to wikidata-items on these. It is mentioned in infoboxes at e.g. enwiki (see above) and nlwiki. Lymantria (talk) 07:19, 14 May 2017 (UTC)

Susannaanas

Jura
Lymantria


Pictogram voting comment.svg Notified participants of WikiProject Lighthouses

Discussion

Symbol support vote.svg Support Susanna Ånäs (Susannaanas) (talk) 14:31, 14 May 2017 (UTC)

average age[edit]

   Under discussion
Description average age in a given place; qualify with P585
Represents average age (Q29975002)
Data type Number (not available yet)
Template parameter none
Domain countries, municipalities, settlements, ...
Allowed values 0-150
Allowed units year (Q577)
Example Prague (Q1085) → 42.0
Source various databases, eg. Czech Statistical Bureau
Planned use import values for all Czech municipalities
Motivation

I'd like to import values for average age in Czech municipalites. This is a blank spot in Wikidata; maybe similar properties such as median age or average age - men / average age - women should also be proposed Vojtěch Dostál (talk) 19:46, 18 May 2017 (UTC)

Discussion
Pictogram voting comment.svg Comment Hmm, I think it would be better to propose a property for demographic information (number of people of a given age) using the new "tabular data" format where the table is stored in Commons. We don't have a lot of tools for that yet (or any properties using it I think so far?) but in principle that would allow determination of average, median, or any other statistical property and this seems like a great test case for it. ArthurPSmith (talk) 17:49, 19 May 2017 (UTC)
Pictogram voting comment.svg Comment Interesting, but what if such detailed information is not available for our country? --Vojtěch Dostál (talk) 08:14, 20 May 2017 (UTC)
  • Symbol support vote.svg Support I think it's good to host this kind of data directly on Wikidata because that makes it easier to query it with SPARQL. ChristianKl (talk) 10:37, 21 May 2017 (UTC)

Australian Statistical Geography 2011 ID[edit]

   Under discussion
Description Identifier of a geographic region defined in the Australian Statistical Geography Standard 2011
Data type External identifier
Template parameter "ID" in en:template:Census 2011 AUS
Domain geographic regions
Allowed values \d or POA\d{4} or SSC\d or NRMR\d or D\d or SED\d or CED\d or ILOC\d or UCL\d or RA\d or IARE\d or SOSR\d or IREG\d or SOS\d or \d{1}G[A-Z]{3} or LGA\d or SUA\d or \d{1}R\d or \dR[A-Z]{2-3} or GL_[A-Z]{2-3}\d
Example
Source Australian Statistical Geography Standard 2011 (Q29980869) http://www.abs.gov.au/websitedbs/d3310114.nsf/home/australian+statistical+geography+standard+(asgs)
Planned use linking suburbs, local council areas, and states with their census data
Formatter URL http://www.censusdata.abs.gov.au/census_services/getproduct/census/2011/quickstat/$1 (some of the types of ID do not have a URL profile, e.g. the tiny statistical areas, but these are unlikely to be used as properties for wikidata items)
Robot and gadget jobs likely
See also none pre-existent, but we could make similar properties for the 2001 and 2006 census region IDs
Motivation

These are Australian Bureau of Statistics identifiers for formally specified geographic regions. Some defined by them, some approximating regions defined by other government entities. Their URLs provide a quick link to 2011 census information about those regions. Wikipedia often already links to these pages for demographic information. I was in two minds about whether to make a different property for each type of region (see all the types here: http://www.abs.gov.au/websitedbs/d3310114.nsf/4a256353001af3ed4b2562bb00121564/c453c497aadde71cca2576d300026a38/$FILE/ASGS%202011%20Structure%20and%20Summary.pdf) so if others think we should go that way, that's also fine by me. 99of9 (talk) 05:23, 20 May 2017 (UTC)

Discussion
  • Support. Makes a lot of sense. The Drover's Wife (talk) 05:39, 20 May 2017 (UTC)
  • Pictogram voting question.svg Question, have you considered the issues brought up in this discussion over at enwiki concerning the nature of some of the statistical areas, particularly SSCs? Things like states would probably be fine and stable, but I'm less convinced about areas that are purely creations of the ABS. Lankiveil (talk) 09:40, 20 May 2017 (UTC).
  • Thanks for the link - I missed that conversation, but was previously aware that rural SSCs are sometimes bad approximations to the gazetted communities (but for urban areas they are WAY better than the only map link we usually have which is a rough Geonames polygon). If more than one community share the same SSC, they could either all link to the same one (which would make it easier to locate this issue in Wikidata) or could use a more appropriate identifier to their situation (e.g. a GL). Either way, it helps to have a direct link to where statistics can be found. Editors will need to stay careful and vigilant in how they use them. Regarding stability, these codes may change every 5 years, which is why I called this the 2011 ID, because I think it is safest to separate them, and this way we can also have direct links to historic demographic statistics. --99of9 (talk) 12:25, 20 May 2017 (UTC)
  • Support As long as this covers the whole ASGS not just SSC, this should make the whole census import process much easier. If the SSC is not appropriate, then the GL can be applied, which at least will allow it to be linked to other localities in the entity. --Canley (talk) 09:31, 23 May 2017 (UTC)

Bavarikon ID[edit]

   Under discussion
Description ID of a geographical object in the database of places of Bavarikon
Data type String
Domain geographical objects in Bavaria
Allowed values ODB_X00000000, one letter and eight numbers
Example Landshut (Q3974)ODB_A00001426, Danube (Q1653)ODB_N00024251, Jochenstein (Q23891544)ODB_S00027450
Source see no label (Q18018659) ans http://www.bavarikon.de/places
Planned use link all geographical objects in Bavaria with Bavarikon, the central culture an applied geography portal of the Bundesland Bayern in Germany
Formatter URL http://www.bavarikon.de/object/odb:BSB-$1
Motivation

Bavarikon is the biggest place-DB for places in Bavaria, Germany with over 70.000 geographical objects. Balû (talk) 10:12, 22 May 2017 (UTC)

Discussion
  • Symbol support vote.svg Support this looks like a good data source ArthurPSmith (talk) 07:04, 23 May 2017 (UTC)

exists between[edit]

   Under discussion
Description subject item exists between object item(s) physically
Data type Item
Example Shoulder joint (Q1758798)values as qualifiers (Q23766486) (of (P642): scapula (Q16336) & humerus (Q162595))
oval window (Q2301793)values as qualifiers (Q23766486) (of (P642): middle ear (Q501553) & scala vestibuli (Q617973))
synaptic cleft (Q15320191)values as qualifiers (Q23766486) (of (P642): presynaptic membrane (Q14864381) & postsynaptic membrane (Q14864257))
palate (Q172605)values as qualifiers (Q23766486) (of (P642): cavity of mouth (Q27042858) & nasal cavity (Q156104))
Core–mantle boundary (Q1330051)values as qualifiers (Q23766486) (of (P642): Planetary core (Q742129) & mantle (Q101949))
equator (Q23538)values as qualifiers (Q23766486) (of (P642): Northern Hemisphere (Q39061) & Southern Hemisphere (Q41228))
Motivation

This property is useful to describe some anatomical relations (see above examples). And it mey be able to use for general uses.


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Pictogram voting comment.svg Notified participants of WikiProject Medicine --Okkn (talk) 06:32, 23 May 2017 (UTC)

Discussion
  • Why do you think this property will be better than using connects with (P2789)? ChristianKl (talk) 08:47, 23 May 2017 (UTC)
  • I do not know I want to say yes because it is easy to find examples where this is the best way to describe the relationship between things. I want to say no because this is so vague that it would be hard to describe when to use this and when the relationship is trivial to note. Perhaps if the name could be made more specific then using it would be more meaningful. Like for example, should every street be tagged like Seventh Avenue (Q109926) -> exists between Sixth Avenue (Q109873) and Eighth Avenue (Q109951)? This seems like an inefficient way to sort maps, even if the relationship might work for body parts. Blue Rasberry (talk) 14:02, 23 May 2017 (UTC)
@ChristianKl, Bluerasberry: In case both connects with (P2789) and «exists between» can be used, connects with (P2789) should be used. (ex. NOT “stomach «exists between» esophagus and small intestine” but “stomach «connects with» esophagus and small intestine”)
However, some relations such as the above examples is a little different from connects with (P2789) because the subject item and object items are heterogeneous. In my opinion, boundary surface doesn't connect with its surrounding object. This is the same with bone vs joint or cavity vs wall relationships. In addition, if X «exists between» A and B, X usually can't be exist without the existence of A and B.
I feel certain that this property is required. --Okkn (talk) 14:56, 23 May 2017 (UTC)
@Okkn: Okay, that seems reasonable. I am not sure what more I should ask. Would it be fair for me to ask that you write some documentation which says, "If both this and property X can be used, then use only property X, which is more specific"? I do not know how properties get documented here, but it seems like there would be standard text for saying how users should apply the most specific property which could be applied when both a specific one and a vague one are available. Blue Rasberry (talk) 15:05, 23 May 2017 (UTC)
@Bluerasberry: I agree with you. Maybe description field or Wikidata usage instructions (P2559) statement is the place for that use.
And I think that constraints like {{Constraint:Conflicts with|list={{P|2789}} }} or those for other specific properies can be used. --Okkn (talk) 16:11, 23 May 2017 (UTC)
There's another issue, our properties takes one value and not two. When it takes more than one value we usually use qualifiers. ChristianKl (talk) 15:40, 23 May 2017 (UTC)
@ChristianKl: If there is only just one pair of two values, can't it be dealed with in the same manner as connects with (P2789)?--Okkn (talk) 16:11, 23 May 2017 (UTC)
@Okkn: The semantics of our properties are structured in a form that they work even if there's more than one pair of values. ChristianKl (talk) 17:11, 23 May 2017 (UTC)
@ChristianKl: I think this property should have only just one pair of values. Is that still no good? --Okkn (talk) 17:35, 23 May 2017 (UTC)
Unfortunately, no. The semantics of the property shouldn't change when another pair of values gets added. There's also no natural way to determine which is the one-and-only correct value that's between A and B and our usual way to deal with a case where there isn't an absolute truth is to allow different people to make different statements. ChristianKl (talk) 10:26, 24 May 2017 (UTC)
@ChristianKl: OK. Then, whould it be a problem if we use values as qualifiers (Q23766486) and of (P642) to take a pair of values? (I fixed the above examples.) --Okkn (talk) 15:30, 24 May 2017 (UTC)
I'm okay with those semantics. ChristianKl (talk) 15:41, 24 May 2017 (UTC)

surrounds or encloses/surrounded or enclosed by[edit]

   Under discussion
Description something that is physically surrounded by the subject item
Data type Item
Example Endomysium (Q3395843)muscle fiber (Q18891564) = myocyte (Q428914)
Perimysium (Q3543470)Muscle fascicle (Q6321987)
fascia (Q936531)skeletal striated muscle (Q1048687)
bony labyrinth (Q262489)membranous labyrinth (Q6593307)
Myelin (Q187388)axon (Q178999)
Amnion (Q473749)embryo (Q33196) and amniotic fluid (Q901674)
atmosphere of Earth (Q3230)Earth (Q2)
mantle (Q101949)Planetary core (Q742129)
   Under discussion
Description something that surrounds the subject item
Data type Item
Example muscle fiber (Q18891564) = myocyte (Q428914)Endomysium (Q3395843)
Muscle fascicle (Q6321987)Perimysium (Q3543470)
skeletal striated muscle (Q1048687)fascia (Q936531)
membranous labyrinth (Q6593307)bony labyrinth (Q262489)
axon (Q178999)Myelin (Q187388)
embryo (Q33196)Amnion (Q473749) and amniotic fluid (Q901674)
Earth (Q2)atmosphere of Earth (Q3230)
Planetary core (Q742129)mantle (Q101949)
Motivation

This property is useful to describe some anatomical relations (see above examples). And it mey be able to use for general uses.


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Pictogram voting comment.svg Notified participants of WikiProject Medicine --Okkn (talk) 07:15, 23 May 2017 (UTC)

Discussion
  • I do not know I think it would be excessive to have this apply to maps. Like for example, many statues are "surrounded" by parks. Would all monuments in all parks use this? What limits should be on this property? Blue Rasberry (talk) 15:01, 23 May 2017 (UTC)
  • I don't feel strongly about the issue of marks and monuments. ChristianKl (talk) 11:50, 24 May 2017 (UTC)