An address string-type property does not allow to link to the item about the street, so we need it to do it another way. One possibility would be to use located in the administrative territorial entity (P131) but we need a street number qualifier, and that would be a bit stretched to do that with P131. The street number needs to be a string, it cannot be a number because of things like 2bis or 21-23, but it can probably be a more general "number" property.
Note that it may be tricky, and perhaps not always possible, to create a standardly formed address using this property, so we may still need a string-type property for the address in addition to it. --Zolo (talk) 19:55, 17 June 2013 (UTC)
Support For the street I beleive we should have a multilingual property and a item property. I don't think non-important street need to be a item. --Fralambert (talk)
I am a bit wary that using two properties for the same relation will make things harder to manage with uncertain benefits. Also, the cutoff between an important an an unimportant street is rather subjective, note that most streets in Paris have an article in fr.wikipedia though many are tiny and unremarkable. --Zolo (talk) 21:45, 1 July 2013 (UTC)
I think the problem is that the address is usually written "51, rue Sherbrooke ouest" but "ouest" is not really part of the street name, so we cannot really guess the usual way of writing the address with just the street name (item) + street number (string). I doubt we can really overcome this issue any other way than by complementing the whole thing with an "address" property with string datatype. --Zolo (talk) 21:45, 1 July 2013 (UTC)
For use as a qualifier for Property:P577 (date of publication) in video games, where it is not uncommon for a game to have different release dates for Japan, North America, Europe, and Australia.
I think better to keep qualifiers and regular properties separate to simplify constrains violation checking. character role (P453) is already used for aviation related topics what is contradictory with its purpose. --EugeneZelenko (talk) 02:57, 24 May 2013 (UTC)
Support This property is different than character role (P453). "Role" describes the relationship actor->character, while "character" represents the relationship between work->character. Better to make the distinction instead of mixing concepts and overstretching properties.--Micru (talk) 18:21, 12 June 2013 (UTC)
Comment The domain should cover musicals (i.e. musical theatre) as well. In this field, it is common for the lyrics of the musical numbers to be written by somebody different from the spoken text (the 'book'): the latter should be a different property. --ColinFine (talk) 23:08, 6 June 2013 (UTC)
Comment This property's inverse -- encodes (P688) -- was created several days ago. This property has unanimous support. Is there anything specific holding back the creation of this property? Emw (talk) 02:47, 17 July 2013 (UTC)
The name seems kind of ambiguous. I suspect that the property might be misused. Perhaps "is time" would be better? --Yair rand (talk) 11:42, 6 June 2013 (UTC)
Oppose This property just create a string from the label: a program can easily retrieve the string from the label. No added information. Snipre (talk) 15:31, 8 June 2013 (UTC)
Hmm, good suggestion I hadn't thought of. The only two downsides of having one generic Ensembl ID property are 1) limits possibilities for constraint violations (a point that I recently learned ;) ), and 2) it means we would definitely have to separate genes from the RNAs that they encode. (Recall that our tentative plan was to just combine those items except for the rare cases where the distinction matters. I know, not a perfect situation, so I'm not married to this choice...) Cheers, Andrew Su (talk) 22:09, 17 July 2013 (UTC)
located on the specified landform or body of water. Should not be used when the value is only political/administrative (towns, cities, provinces, states, countries, etc.).
Oppose weak: how do you define the limits of a geographical entity in order to define if an element is located on it or not ? I don't like properties which dependent on the judgement of contributors and in that case external sources can be very partial. The best solution woulb be an automatic definition based on the geo data of the geographical entity and the geo data of the element. Better work on an automatic tool which gives that informations instead of doing that manually. Snipre (talk) 11:25, 16 July 2013 (UTC)
Support Yes, I have been looking for this one! This allows me to state that a city is on an island (which is not an adm. unit) and that the island is in that sea. --Denny (talk) 22:50, 22 July 2013 (UTC)
Comment Can somebody add another example for this. Even with the translation program I don't understand what this is about. --Tobias1984 (talk) 21:27, 20 May 2013 (UTC)
Support - Seems useful. But we might want to think through how we ought to handle, in a standardized way, satellites for which their is no satellite bus, and the satellite is merely a one-off, a unique design being built and flown only once. Cheers. N2e (talk) 02:41, 10 June 2013 (UTC)
field in which the term is used (en) / champ d'utilisation du terme (fr)
Not done
Description
The subject is a technical term in the field of the object. (the idea is to have a property that groups technical terms that are used in a given field)
the term "cut" means different things in civil engineering, archaeology, jewellery and clothing. So we'd have cut is a term used in civil engineering. Similarly, Cut is a term used in archaeology and so on.
shouldn't be needed as the item is usually its own source for the statement and the statement is common knowledge in any case
Robot and gadget jobs
gadgets, why not. It's not so clear how bots can help although perhaps they could extract that information starting with glossary articles such as en:Glossary of tennis terms
Point taken about Wiktionary. But I don't see why translation would be a problem: surely the translation of a technical term in, say, cricket is still a technical term in cricket. Pichpich (talk) 15:32, 19 June 2013 (UTC)
After mulling it over, I'll make a couple of extra comments. First, why should Wikidata absolutely avoid doing something that Wiktionary does? After all, Wikipedia keeps a record of people's occupation and that's not stopping us from recording it in Wikidata. Second, my motivation for this is that there are items for which no statements seem to be available. For instance, take Q814254. Once we've added the statement that its GND type is "term", I can't see what other statements would make sense. If there existed an item for "Glossary of archaeology" (there is one for Glossary of architecture) it would make perfect sense to add the statement "is part of the glossary of archaeology". The property I'm proposing would allow an equivalent to that. Pichpich (talk) 17:47, 19 June 2013 (UTC)
The create the item is also a general solution which do not require a property. Then <Glossary of X> would be instances of <Glossaries> or <Domain specific Glossary>, and we could have something like a domain relation which states that the domain of this glossary is X. Why should we be so shy about creating an item ? Plus there already exists items of this kind, so we multiply the ways of expressing and modeling the same things. (see my proposition to centralize and document that to check easily if somebody already thought on something for this). TomT0m (talk) 18:16, 19 June 2013 (UTC)
OpposeThe problem is that each wikidata page groups together pages on the same concept in various wikipedias. Even though all the pages are about the same concept that does not guarantee that all of them are named after the technical term for that concept. The wikipedia or wikidata page name in some languages may be a simplified description instead (Simple English Wikipedia is specifically dedicated to avoiding technical terms). Maybe if this property was renamed 'field of which this concept (or 'item') is part or something like that. Filceolaire (talk) 19:34, 19 June 2013 (UTC)
Maybe we should name the property ammunition instead. I can see now that cartridge might imply that it is the casing of many bullets (I changed the proposal below). --Tobias1984 (talk) 09:20, 28 May 2013 (UTC)
This is more complicated than I thought :). Have you looked at en:Cartridge_(firearms)? The article also uses shell and round as synonyms of something you fire with a weapon. If you have time could you make some sort of weapons classification tree going from gun to projectile? I would like to see what you have in mind ;) --Tobias1984 (talk) 12:44, 28 May 2013 (UTC)
It is a good thing that "Coat of arms image" has been added, but many countries' heraldic emblems have several variants, any one of which could be defined as "the coat of arms image". Belgium, for example:
The escutcheon is generally the only one that allows for an orderly illustration of entities – e.g. in lists of countries, regions, cities or persons – by means of coats of arms, due to its uniformity with other coats of arms. This is explained in the description of en:Template:Coat of arms: "The omission of all elements of achievement save the quintessential escutcheon is a conventional heraldic practice that ensures the distinctiveness of the motifs even at low resolutions (20px is default). This also provides a meaningful degree of uniformity." (I've added links to examples above.)
I propose a new mediavalue named "Escutheon image". The use of heraldry as a means to identify geographical entities is a centuries-old tradition, preceding flags. So especially for historical articles (historical countries that had no flag), and in lists of cities/states, an escutheon database on Wikidata would be extremely valuable. Some coats of arms do of course not have variants, save the escutcheon. It would however be perfectly correct to have for instance File:Coat of Arms of Germany.svg written into both "coat of arms image" and "escutcheon image" on Germany's page.
(A more extensive proposal could be to introduce media values for "escutcheon", "lesser", "middle" and "greater" etc. coats of arms. It would also be possible to introduce for the en:blazons of each of these. But since the division into "lesser", "middle" and "greater" isn't universally applicable, I'm currently only proposing a media value for escutcheons, with the aforementioned reasons, and also because this variant exists for all the world's coats of arms.)
All types of symbols (logos, seals, flags, coats of arms, etc.) can apply to entity types person, organization, geographical feature, and some terms such as products and services. Danrok (talk) 17:31, 26 February 2013 (UTC)
Comment Such a solution could be ideal, but considering that this option isn't currently available, and we don't know when it will be introduced, I'm not sure if we should impede this (escutcheon image) property. I would presume that it would be possible to turn the values of this property into an additional value of the "coat of arms image" property, with an "escutcheon" qualifier. - Ssolbergj (talk) 15:05, 28 February 2013 (UTC)
Oppose if escutcheon is considered a variant of the coat of arms, then I would oppose the 'escutcheon' property and instead propose a 'variant' property to be used as a qualifier with values such as 'escutcheon', 'lesser version', etc. This also applies to flags and other insignia: either we can create properties for every different defined type of coat-of-arms, flag, logo, etc., or we can have a qualifier 'variant' to allow this to be defined on an as-needed basis. I would propose the later. Joshbaumgartner (talk)
Oppose. There is a property 'shares borders with'. What we need is an general property we can use as qualifier to state how two places are separated. Something like 'separated/divided by' or 'border type'. Example <New York> <shares border with> <New Jersey> -> (qualifier) <separated by> <river (or water)>. Sorry I didn't have an example for ocean, but I hope you know what I mean. Otherwise we would have several properties like "Borders ocean", "Borders river", "Borders land". I will make the proposal later for this. --Nightwish62 (talk) 15:38, 31 March 2013 (UTC)
Oppose in the present concept. A proposal specifing all type of border (river, ocean, mountain rang,...) is necessary. Snipre (talk) 19:13, 10 June 2013 (UTC)
Oppose derivable properties like this (the value for the 'population' property divided by the value for the 'area' property) seem like a plausible use case for Wikidata queries. In that case, I think properties like this one would be unnecessary. Emw (talk) 17:47, 31 March 2013 (UTC)
Comment or the infobox can calculate this when it imports the area and population into wikipedia (making sure we get a up to date value). Filceolaire (talk) 20:32, 6 April 2013 (UTC)
Regarding sporting events, the property can also be equipped with a qualifier to express the round or place that the participant reached. Properties like "champion", "runner-up", etc are used in many infoboxes for sporting events. For the Olympics, there are group items like Canada at the 2012 Summer Olympics (Q140982), so you don't have to list all 11,000+ athletes under one item; in order to be fully accurate, you would arguably need to introduce similar items for events like 2010 FIFA World Cup (Q176883), to list the actual squad members that participated.--Kompakt (talk) 08:15, 30 May 2013 (UTC)
Comment Maybe it would be better to have only the reverse property, "participated in", because otherwise there will be too many properties (imagine how many athletes participate in the Olympic games).--Micru (talk) 01:50, 8 July 2013 (UTC)
I proposed above to have group items for events with a lot of participants, like the Olympics. As a matter of fact, we do have such items already, e.g. Canada at the 2008 Summer Olympics (Q140854). So 2008 Summer Olympics (Q8567) would have "participants": Canada at the 2008 Summer Olympics (Q140854)", and within Canada at the 2008 Summer Olympics (Q140854), all members of that team would be listed using has part(s) (P527). Still you're right, this property could have a hundred values in some occasions, so another grouping level could be necessary (e.g. "Canadian archers at the 2008 Olympics"). But on a closer look, your proposal of creating such a property on the participants' side actually bears the just same problem: professional sportspeople usually take part in hundreds of events within their career.
But that's not my main point. What is the mains idea behind this property? Using a qualifier like "ranking", it will make it possible to describe the result of a sports event; we are then able to tell who won the event, who was second, etc. Taking the example above, we could use this for archery at the 2008 Summer Olympics (Q223519) to tell who got the gold medal, who was second, etc. As mentioned above, this is an infobox property for sport events in wikipedia, but could also be used to create result lists or even complete draws at some later point. All of this would hardly be possible when we have this information distributed at the participants - although you could arguably create queries to fetch such information, I don't think that's the best way to do it. The winner, the runner-up as well as other participants should be stored along with the event itself.
A final remark: Note that the Olympics are the most complicated case by far. Take an ordinary single-sport event like the Soccer World Cup instead: for 2022 FIFA World Cup (Q284163) you'd use "participant" to list all teams with single items like "Icelandic team at the 2022 FIFA World Cup", and then list all team members within these team items using has part(s) (P527). Then none of these properties would have more than (roughly) 30 values.--Kompakt (talk) 08:49, 16 July 2013 (UTC)
I will delete this proposition because it is a redundant one: don't mix source and property. A property is valid for different sources. Snipre (talk) 08:57, 20 April 2013 (UTC)
I'm not sure I fully understand what you mean. There is only one main source for this kind of classification. Not sure that that is mixing source and statement. Isn't this just the same case as ICD10 that is published by the WHO. There is no second organization that came to the same conclusion and the same ICD-10 codes. --Tobias1984 (talk) 09:55, 20 April 2013 (UTC)
Why not an unique property Strunz ? What is not good is the creation of property dependent on the edition number of the source. Here you mix data of source level at the level of the property. For each property use there will be a source defined in the source claim of the data structure. So put the information of the edition number in the source section not in the property. Snipre (talk) 10:02, 20 April 2013 (UTC)
Ok I think I understand the problem: it is the edition number of method not of the source. But even in that case qualifier can be a better solution and you can already use the property edition in the qualifier section. Snipre (talk) 10:11, 20 April 2013 (UTC)
That sounds reasonable. Would you group all mineral classifications together into one property and then make qualifiers for Strunz 8, 9, 10, Dana and some others? Or would you divide for example Strunz and Dana into separate properties? We (mineralogy task force) are also discussing another classification that divides silicates into different structural groups. --Tobias1984 (talk) 10:20, 20 April 2013 (UTC)
No, Dana and Strunz are different and as Strunz will be subdivided better into 3 distinctions better to avoid to mix different things. Just to explain my position: I assume that the different edition of Strunz are quite similar or if not the more recent will be used. That means that most of the time you will have only one data for that property. Snipre (talk) 11:20, 20 April 2013 (UTC)
Well Strunz 8 ed had less than 3,000 valid minerals, Strunz 9 ed had more than 4,000 minerals, the grandfathered minerals are even older. The newer minerals are less important, on average. This is a publication, it gets cited, so this data is a search tool. Strunz and Dana are like the IMA mineral list, it is the reference "telefone book" of their time. --Chris.urs-o (talk) 11:35, 20 April 2013 (UTC)
@Snipre: different Strunz editions are quite different: for example actinolite Strunz 8th edition ID is: 8/F.10-20, Strunz 9th edition ID is: 9.DE.10. From 8th to 9th edition there are many changes, from 9th to 10th there are only minor changes (10th edition, that is still a work in progress, reports also new approved minerals). --Sbisolo (talk) 08:22, 22 April 2013 (UTC)
These are telefone books. The important minerals are old, so they are already listed on Strunz 8 ed (nice for sorting). Nickel–Strunz 9 ed is used by de.wikipedia because it is the last published edition. 'Nickel–Strunz 10 ed' is kept updated by mindat.org. We need Nickel–Strunz 9 ed first. Strunz 8 ed classification used roman numerals too. --Chris.urs-o (talk) 06:06, 24 May 2013 (UTC)
E.g.: arsenuranospathite had Strunz 8 ed ID 7/E.04-20 or VII/E.04-20 and chemical formula HAl(UO2)4(AsO4)4·40H2O. The chemical formula was revised (Al(UO2)2(AsO4)2F·20H2O) and 'Nickel–Strunz 10 ed' ID is 8.EB.25 now. --Chris.urs-o (talk) 06:22, 24 May 2013 (UTC)
I was observing recent property creations, and it looks like most people think it is better to create more string properties that can be edit filtered than introduce qualifiers for different classifications. If nobody objects I will just create 3 string properties for strunz 8, 9 and dana. --Tobias1984 (talk) 16:19, 1 June 2013 (UTC)
I will delete this proposition because it is a redundant one: don't mix source and property. A property is valid for different sources. Snipre (talk) 08:57, 20 April 2013 (UTC)
not included in any infobox yet, usually in the text of all articles
Domain
items about geologic ages and stratigraphic units
Allowed values
fossils, magnetic stages, angular-, erosional unconformity, special beds (e.g. volcanic ashes)
Example
Fortunian = Treptichnus pedum (qualifier = first appearance of the species) Ionian = Brunhes-Matuyama magnetic reversal Tapeats Sandstone = Erosional unconformity & angular unconformity (see picture on the right) Muav limestone = conformable.
I think I know what your hinting at. We could say for example that the lower boundary can be either: a fossil, magnetic or lithologic. The qualifiers could then have the species name, the magnetic anomaly name or the name of the special lithology. For formations the character of unconformity might be better suited as a qualifier for underlies/overlies. --Tobias1984 (talk) 14:26, 28 April 2013 (UTC)
Wait I am voting wait on my own proposal because I still have to think about this property for a while. Might be better to handle this with qualifiers ;) --Tobias1984 (talk) 10:26, 2 May 2013 (UTC)
ID in the Royal Commission on the Ancient and Historical Monuments of Scotland's Canmore database (buildings, sites, and ancient monuments of archaeological, architectural and historical interest in Scotland)
Question Why very different definition than the one given in , according to which datatype item seems to be possible? – The preceding unsigned comment was added by? (talk • contribs).
Type of terrain feature - mountain, island, body of water etc.. Should not be used when the value is only political/administrative (towns, cities, provinces, states, countries, etc.).
a link to a notable incident involving that item. Intended for use with Airlines and also buildings such as the Chernobyl Nuclear Power plant. Note that it should be used on the power plant in this example, not on the town of Chernobyl. Criteria to determine its notability would include, naturally, that it has a Wikdata item and one or more of the following:
Resulted in loss of life
Resulted in significant injury to multiple persons
Resulted in an excess of a certain amount of financial damages
Causes significant environmental, economic, cultural and/or political damage (i.e Deepwater Horizon)
Comment This property seems useful. However, the criteria outlined in the proposal really describes a disaster, not merely an incident. The word "incident" often has a neutral connotation or implies a minor negative event. (In "diplomatic" terms, however, "incident" often implies something serious, but not of the nature described in the proposal.) Given that, I would suggest changing the label to 'disaster affecting'. Emw (talk) 14:32, 20 April 2013 (UTC)
Weak oppose Each node in a taxon's classification is deducible through the parent taxon (P171) property, or, as I argue at that property's RFD, the preferable subclass of (P279) property. In my opinion the current listing of all taxonomic ranks on many taxon items is redundant and sets a bad precedent. It seems like Lua or Wikidata queries would be a much better approach to get that chain of values, rather than listing them all out explicitly in hundreds of thousands of taxon items. Emw (talk) 23:33, 31 March 2013 (UTC)
Fair enough. It should be consistent though, so if we're not going to have superfamily, we should remove family, etc. My only concern with parent taxon is that it can be unclear until you actually go to the parent. Is it a superfamily or an order (it depends)? I realize this can be inferred (and maybe eventually displayed) automatically if the parent is properly marked, so this isn't a major obstacle. There is a case to be made that the indeterminate number of ranks makes your proposal better. Superm401 (talk) 05:28, 1 April 2013 (UTC)
duplicate, as Tobias1984: a color index property was already approved. Here there is my proposal to a color-index-filter property --Paperoastro (talk) 18:43, 20 July 2013 (UTC)
Asteroid spectral types (en) / Classification spectrale des astéroïdes (fr)/ Classificazione spettrale degli asteroidi (it)/ Tipo espectral des asteroides (es)
Oppose Oppose without a general concept of size definition of object. Because there are plenty of other length parameters which can be used to describe an object and only a general concept can avoid the creation of specialized properties. Why not a property "Dimension" and a qualifier "element" which can be used for screen but other characteristics too ? Snipre (talk) 11:35, 1 July 2013 (UTC)
Oppose. For an individual, I think it's too subjective (birthplace, location of first gig, location of first recording studio?, etc.). For an organization (including but not limited to a band), it should be more definite (where did the group form), but I think we can do a more general property. See below. Superm401 - Talk17:29, 8 April 2013 (UTC)
Support for artist groups, Oppose for individuals. People usually start a group by meeting somewhere (Internet being an exception). --NaBUru38 (talk) 19:10, 18 April 2013 (UTC)
Support. It is an important geographical code that identifies every populated place in Russia. But it also can be used for an administrative divisions too, so I propose to include them to the domain of this property. --Emaus (talk) 21:41, 13 July 2013 (UTC)
Oppose Do you want to create codes for each country? Many countries have codes of administrative divisions and/or places. For example for Russian it is ОКАТО, for Ukraine it is КОАТУУ, for Kazakhstan — КАТО, for PRC — 中华人民共和国行政区划代码, for Kyrgyzstan — СОАТЕ, for Uzbekistan — СОАТО, for USA — FIPS codes etc. So I suggest that we should create general element for all countries, for example: Code of place or administrative division.--Ahonc (talk) 22:05, 13 July 2013 (UTC)
Description: Historic name(s) of the location (possibly tagged by language)
Datatype: Text
Links:
Infobox parameter example:
Comments: I am not sure if this is covered by "Also known as" or not; Q914 has "also known as: Stalingrad", but if we had a property for the name we could say Tsaritsyn 1589-1925, Stalingrad 1925-1961. Andrew Gray (talk) 18:37, 26 February 2013 (UTC)
Support the idea. I tend to think aliases can't replace a property like this. They are not "structured", and moreover their contents serve numerous purposes (abbreviations, variations, ease of lookup within the Wikidata UI); and they can't be qualified for a time period, for example; so yes, support. Espeso (talk) 20:21, 26 February 2013 (UTC)
Weak oppose Wouldn't people without a doubt add the relevant years behind the historic name? That could get messy. In that case, it would perhaps be a better idea to wait until a datatype enabling the combination of time values and text is introduced. Does anyone know if such a feature is being planned? - Ssolbergj (talk) 03:53, 27 February 2013 (UTC)
Support I don't really understand the objection -- there's lots of stuff on the list and proposed that could and probably should be modified by "relevant years." Coaches? Yes. Stadiums of teams? Yup. Headquarters (which I had suggested). Ditto. Mayors. Heads of national governments. And on and on and on. There's a vast past to everything, and a single name change is small potatoes. Shawn in Montreal (talk) 04:00, 27 February 2013 (UTC)
Support Agree it does need qualifiers, i.e. Stalingrad; from 1925 to 1961. But so do many existing properties, so that should not impede this property. Danrok (talk) 04:03, 27 February 2013 (UTC)
Oppose per Ssolbergj. Better do it right from the start that proliferate a bunch of half-cooked values which will all need to be verified/expanded later.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:18 (UTC)
Support Maybe it would have been better not to start with a half-baked system, but that's what we have. The lack of much support for recording sources is a much bigger problem than missing dates would be here. There's still some value to a collection of historic names, even without their associated dates. --Avenue (talk) 08:24, 13 March 2013 (UTC)
Support per usual "there will be qualifiers" argument. However, you could also argue that a historic place is "different from" the current place (e.g. city) and deserves its own item, so that if a person was born in Stalingrad, then it reads that they were born in... Stalingrad. Frankly, that would be a more robust solution, since you could record the history of that entity in other ways as well. Espeso (talk) 18:51, 13 March 2013 (UTC)
Oppose This should be done via the "Official Name" (or maybe "Local Name") properties (See Generic proposals) with date qualifiers. Filceolaire (talk) 20:01, 6 April 2013 (UTC)
Oppose -- as told Filceolaire: this should be done using "Official Name" property, approved with multilingual text datatype, with date qualifiers. --Paperoastro (talk) 11:07, 5 June 2013 (UTC)
Comment I think place names need form a timeline, have explicit language versions and relate to geographic areas the named entities cover in given times. Maybe changes should be explicitly stated: merge, split. etc. with dates. I cannot say if Historic name is the right way. --Susannaanas (talk) 13:53, 7 June 2013 (UTC)
Geography / Géographie / Geographie / Geografia (pt)
Description: geography of the place (country, state, town, ...)
Datatype: Item
Links:
Infobox parameter example:
Comments:It can link to the geography article about the place. Like Portugal --» Geography of Portugal. It can also be created to other topics. I don't think that this could be used in a Infobox. It can be useful because it links the topic to the subtopic. - Sarilho1 (talk) 15:43, 24 March 2013 (UTC)
Comment: Do you think we have to do this for every subject? Will we add properties for each subarticle of Wikipedia articles? We have P:P358 for discography of music artists or groups already. I supported it, but now I think this will grow exponentially, and I'm worried. --NaBUru38 (talk) 20:07, 27 March 2013 (UTC)
If you prefer we can rename to Subtopics. I don't know! I was just trying to create a property that seams useful to me. - Sarilho1 (talk) 12:19, 28 March 2013 (UTC)
I understand your view, it does help to list subarticles. But we must find a reasonable way to do it, and I'm not sure which is. --NaBUru38 (talk) 18:53, 18 April 2013 (UTC)
(Sorry for putting in this in German at the moment, will translate later. I've taken this from the German Infobox which appearantly is the most developped river infobox I am aware of.)
GKZ Zahl Gewässerkennzahlen des Flusses in der Form ISO-3166-1-Code/ID1[/ISO-3166-1-Code/ID1...] (Beispiel: DE/2/CH/5 ergibt DE: 2, CH: 5). Implementiert sind derzeit die ISO-Kodes AT, BE, CH, CZ, DE, FI, FR, LU, RU, US.
FLUSSSYSTEM Text Es wird nur der Fluss angegeben, der für das Gesamtflusssystem namensgebend ist. Die Eingabe erfolgt nach EBNF-Syntax:
ABFLUSSWEG Text Mit diesem Parameter wird der Abflussweg bis zum Flussende (in der Regel das aufnehmende Meer) spezifiziert, d.h. es werden alle Flüsse angegeben, die den Abflussweg bilden. Wenn der Fluss in ein Meer mündet, dann wird dieses auch angegeben werden. Es werden maximal 10 Angaben in der Infobox dargestellt.
ABFLUSSWEG = { Lemma "/" [ Darstellung ] "/" } ("/" am Ende können entfallen)
FLUSSGEBIETSEINHEIT Text Flussgebietseinheit der europäischen Wasserwirtschaftrichtlinie, falls abweichend vom Flusssystem.
BEZEICHNUNG-QUELLE Text Anders lautende Bezeichnung für Quelle (z.B. Ursprung) (optional)
QUELLE Text Quelle des Flusses, auch für die Quellflüsse (siehe dazu Beispiel unten) und Ausfluss aus Seen (Wartungsseite). Fehlt diese Angabe, dann werden keine Quellkoordinaten angezeigt.
QUELLE_LAT_GRAD Text Angabe der Geographischen Breite (Gradangabe). Eine Angabe gemäß Vorlage:Coordinate, also etwa 45/10/10/N, ist möglich. Die anderen Angaben zum Breitengrad müssen dann entfallen.
QUELLE_LONG_GRAD Text Angabe der Geographischen Länge (Gradangabe). Eine Angabe gemäß Vorlage:Coordinate, also etwa 10/10/10/E, ist möglich. Die anderen Angaben zum Längengrad müssen dann entfallen.
QUELLE_REGION Text Angabe von Land und Region nach ISO-3166-1 und ISO 3166-2.
QUELLE_AUFLÖSUNG Zahl Angabe der Größe in Meter
QUELLHÖHE-PREFIX Text Prefix zur Quellhöhe (optional)
QUELLHÖHE Zahl Höhenlage des Quellortes in Metern ohne Einheit
HÖHENBEZUG-QUELLE Text Höhenbezug der Quelle (gemäß Vorlage:Höhe)
QUELLHÖHE-SUFFIX Text Suffix zur Quellhöhe. (optional)
NACHWEIS-QUELLHÖHE Text Einzelnachweis für die Quellhöhe.
QUELLSCHÜTTUNG Text Angabe der Messwerte. Die Eingabe erfolgt nach EBNF-Syntax:
Die Bedeutung der einzelnen Angaben:
NNQ - niedrigste, gemessene Abflussmenge (in m³/s)
NNQ-Datum - Datum des NNQ
MNQ - Mittlerer Abfluss bei Nierigwasser (in m³/s)
MQ - Mittlerer Abfluss (in m³/s)
MHQ - Mittlerer Abfluss bei Hochwasser (in m³/s)
HHQ - höchste, gemessene Abflussmenge (in m³/s)
HHQ-Datum - Datum des HHQ
QUELLSCHÜTTUNG-REIHE Text Messreihe für die Quellschüttung (Beispiel: "1960/2005").
NACHWEIS-QUELLSCHÜTTUNG Text Einzelnachweis für die Quellschüttung.
BEZEICHNUNG-MÜNDUNG Text Anders lautende Bezeichnung für Mündung (z.B. Zusammenfluss) (optional)
MÜNDUNG Text Mündung des Flusses. Fehlt diese Angabe, dann werden keine Mündungskoordinaten angezeigt. (Wartungsseite)
MÜNDUNG_LAT_GRAD Text Angabe der Geographischen Breite (Gradangabe)
MÜNDUNG_LONG_GRAD Text Angabe der Geographischen Länge (Gradangabe) (Wartungsseite)
MÜNDUNG_REGION Text Angabe von Land und Region nach ISO-3166-1 und ISO 3166-2.
MÜNDUNG_AUFLÖSUNG Zahl Angabe der Größe in Meter. Dieser Parameter beeinflusst den Anfangsmaßstab einer externen Kartenansicht (Siehe Parameter dim in der Vorlage:Coordinate)
MÜNDUNGSHÖHE-PREFIX Text Prefix zur Mündungshöhe (optional)
MÜNDUNGSHÖHE Zahl Höhenlage der Flussmündung in Metern ohne Einheit (Wartungsseite)
HÖHENBEZUG-MÜNDUNG Text Höhenbezug der Mündung (gemäß Vorlage:Höhe) (Wartungsseite)
MÜNDUNGSHÖHE-SUFFIX Text Suffix zur Mündungshöhe. (optional)
NACHWEIS-MÜNDUNGSHÖHE Text Einzelnachweis für die Mündungshöhe.
HÖHENUNTERSCHIED Zahl Höhenunterschied zwischen Quellhöhe und Mündungshöhe (Wartungsseite)
LÄNGE Zahl Die Länge des Flusses (Wartungsseite)
NACHWEIS-LÄNGE Text Einzelnachweis der Länge als Referenzangabe (Wartungsseite)
LÄNGE-PREFIX Text Präfix für die Längenangabe. (optional)
LÄNGE-SUFFIX Text Suffix für die Längenangabe (optional). Die Angabe wird nach dem Nachweis dargestellt. Für die Darstellung weiterer Längenangaben kann hier die Vorlage:Infobox Fluss/LÄNGE eingesetzt werden (Beschreibung siehe Vorlage).
EINZUGSGEBIET Zahl Größe des Einzugsgebiets des Flusses im km² (Wartungsseite)
EINZUGSGEBIET-PREFIX Zahl Präfix für die Angabe des Einzugsgebietes. (optional)
NACHWEIS-EINZUGSGEBIET Text Einzelnachweis für das Einzugsgebiet als Referenzangabe (Wartungsseite)
EINZUGSGEBIET-SUFFIX Text Suffix für die Angabe des Einzugsgebietes (optional). Die Angabe wird nach dem Nachweis dargestellt.
PEGEL1 Text Angabe der Pegelhauptwerte. Die Eingabe erfolgt nach EBNF-Syntax:
Die Bedeutung der einzelnen Angaben:
NAME - Name des Pegels
LoM - Lage oberhalb der Mündung (in km)
EZG - Größe des Einzugsgebietes (in km²)
NNQ - niedrigste, gemessene Abflussmenge (in m³/s)
NNQ-Datum - Datum des NNQ
MNQ - Mittlerer Abfluss bei Nierigwasser (in m³/s)
MQ - Mittlerer Abfluss (in m³/s)
MHQ - Mittlerer Abfluss bei Hochwasser (in m³/s)
HHQ - höchste, gemessene Abflussmenge (in m³/s)
HHQ-Datum - Datum des HHQ
PEGEL1-REIHE Text Messreihe für die Pegelwerte (Beispiel: "1960/2005").
NACHWEIS-PEGEL1 Text Einzelnachweis für die Pegelwerte.
PEGEL2 Text Angabe der Pegelhauptwerte. Siehe PEGEL1
PEGEL2-REIHE Text Messreihe für die Pegelwerte (Beispiel: "1960/2005").
NACHWEIS-PEGEL2 Text Einzelnachweis für die Pegelwerte.
PEGEL3 Text Angabe der Pegelhauptwerte. Siehe PEGEL1
PEGEL3-REIHE Text Messreihe für die Pegelwerte (Beispiel: "1960/2005").
NACHWEIS-PEGEL3 Text Einzelnachweis für die Pegelwerte.
ABFLUSS-NNQ Niedrigster je gemessener Abfluss in m³/s (Wartungsseite)
ABFLUSS-NNQ-JAHR Jahr des niedrigsten Abflusses
ABFLUSS-MNQ Mittlerer Abfluss bei Niedrigwasser in m³/s (Wartungsseite)
ABFLUSS-MQ Mittlerer Abfluss in m³/s (Wartungsseite)
ABFLUSS-MHQ Mittlerer Abfluss bei Hochwasser in m³/s (Wartungsseite)
ABFLUSS-HHQ Höchster je gemessener Abfluss in m³/s (Wartungsseite)
ABFLUSS-HHQ-JAHR Jahr des höchsten Abflusses
ABFLUSS-PEGEL Messstelle des Abflusses
NACHWEIS-ABFLUSS Nachweis für die Abflusswerte
LINKE NEBENFLÜSSE Linke Nebenflüsse
RECHTE NEBENFLÜSSE Rechte Nebenflüsse
SEEN Text Durchflossene natürliche Seen
STAUSEEN Text Durchflossene Stauseen
These two should probably be grouped into one and whether a lake is natural or artificial could be derived from the lake item. Nikola (talk) 04:42, 8 March 2013 (UTC)
GROSSSTÄDTE Städte über 100.000 Einwohner am Fluss. Gemeint ist die Ortschaft, nicht die Gemarkung.
MITTELSTÄDTE Städte zwischen 20.000 und 100.000 Einwohner am Fluss. Gemeint ist die Ortschaft, nicht die Gemarkung.
KLEINSTÄDTE Wichtige Städte unter 20.000 Einwohner am Fluss. Gemeint ist die Ortschaft, nicht die Gemarkung.
These three should probably be grouped in on property, "cities", "flows through", "passes through" and cities' sizes could be derived from the city item. But the cities should probably be ordered in the order the river flows, and I don't see any reasonable way of including this information. Nikola (talk) 04:42, 8 March 2013 (UTC)
GEMEINDEN Gemeinden entlang des Flusses (bei kleineren Flüssen). Gemeint ist die Ortschaft, nicht die Gemarkung.
EINWOHNER IM EINZUGSGEBIET Einwohnerzahl des Einzugsgebiets des Flusses
HÄFEN Binnenhäfen am Fluss
Comments Comment I suggest you put the full list of parameters on the Wikidata:Infoboxes task force/places instead, and do the mapping to any current properties there. (Would it be possible to map these parameters to the corresponding English template parameter names?) At this page, please state the datatype of each parameter, and only include parameters that use the three currently defined parameters (monolingual text, item, media). Mange01 (talk) 19:38, 11 March 2013 (UTC)
A general question: do we want to have more general properties or less general properties? For example, for rivers, should we use "is in" to denote the watershed? Another example, should we have "passes through" (cities) that could be applied to roads and rivers? Nikola (talk) 16:46, 7 March 2013 (UTC)
Actually at least DE:WP is treating rivers and catchment areas differently; the Donau is not a river in Italy but its catchment area comprises parts of upper Italy. --Matthiasb (talk) 10:58, 8 March 2013 (UTC)
There are three more below. Your properties have a problem that the altitude can be measured in meters, and can be measured in feet, and we do not yet have a property which switches between the two.--Ymblanter (talk) 15:31, 8 April 2013 (UTC)
Note: The German Infobox expects numeric values for parameter QUELLHÖHE and MÜNDUNGSHÖHE (altitude) and a defined string for the height reference system (parameter HÖHENBEZUG-QUELLE and HÖHENBEZUG-MÜNDUNG). The altitude difference is calculate by the IB.--SteveK (talk) 18:03, 8 April 2013 (UTC)
Information regarding the churches and other religious organizations where the person was designated the minister or other religious ministerial office. Often there is no named office for which you could use Property:P39. Jfhutson (talk) 02:07, 9 May 2013 (UTC)
This field links to an official external website with more information about Dutch language authors, and is currently used on many writers on the Dutch Wikipedia. Edoderoo (talk) 13:34, 30 June 2013 (UTC)
Oppose Better do the inverse: add in each airbase item the name of the army using the base. Think of property like a characterization of the item: the US Air Force is not defined by its airbases. So the use of property "part of" for all airbases will be enough. Snipre (talk) 09:24, 12 May 2013 (UTC)
Oppose I don't like the idea of using property to do the categorization work of wikipedias: this assumes an uniform categorization among the wikipedias and as we can see it for the articles there is not an unique way to divide and categorize the topics. Snipre (talk) 23:02, 10 June 2013 (UTC)
Comment Before we can create something like this we should decide whether the Portal namespace should be even linked to the content namespace. Or in general which namespaces to consider. I think User was already declined. But in general I think that centralizing categories would be a good idea. --Tobias1984 (talk) 09:51, 11 June 2013 (UTC)
As Property:P39 but describing the position held in a church hierarchy. For example _Walter Kasper Q44100 is classified "office held: cardinal of the Roman Curia" but in German it is "Politisches Amt:Kurienkardinal" or just a bad translation?--Giftzwerg 88 (talk) 14:20, 21 March 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Weak oppose unless I'm overlooking a lot of "free" album covers. Fair use images won't be available for linking, since they're not on Commons... Espeso (talk) 15:53, 27 February 2013 (UTC)
Oppose I don't know any album articles, where the cover is from Commons... there is not many, so I think that this is not so useful. --Stryn (talk) 17:18, 26 March 2013 (UTC)
What's in situation when P18 is used more than once for an album, not all showing the album cover? E.g. one showing a picture while the record session or the building of the record studio, or a picture from the release event, notes from a song, sales charts, etc.? --Nightwish62 (talk) 09:44, 6 April 2013 (UTC)
A property like that should only be used if its really and directly related to the article. A photo like you described has "nothing" to do with the album itself and should generally not be linked here on Wikidata, thats would be the job of Commons and its categories. --#Reaper (talk) 21:33, 30 April 2013 (UTC)
I agree with Nightwish62. It's good to be specific that we mean the album cover. Other images can apply, particularly photos of them while recording. Superm401 - Talk19:35, 7 April 2013 (UTC)
Support Non-free images are available for linking, and we'd need this to associate them with their respective albums (or singles, etc). This is an example of an item of an album cover: Q10772612. We need this and another property to make the link back. — ΛΧΣ2107:22, 9 April 2013 (UTC)
Oppose I think too, Property:P18 is good for that. Picture of an album is pretty clear. Never saw a picture of recordiung an album or something like that on Commons.--CENNOXX (talk) 18:49, 9 April 2013 (UTC)
I've developed en:Module:ImportProtein that can create graphics from these text files. An example is presented inen:Src (gene). Wikipedia won't process these directly from NCBI, so if they are ever to be used, these lengthy files should be copied in full to Wikimedia somewhere. Logically Wikidata should handle this centrally, and they can then be transcluded into the #invoke from here. (I know little of Wikidata, so feel free to point out if I've missed something obvious!) Wnt (talk) 16:48, 16 April 2013 (UTC)
I was thinking of the whole file as the data, and the references mentioned in that file are part of it. You could subparse it into a hundred different features, but I don't even know how you edit a whole Wikidata entry at one time, so dealing with that kind of input as a hundred different properties/tags would be a nightmare. Wikidata already seems too organized to be useful when I can't just dump this data in without proposing one property for discussion. Wnt (talk) 01:30, 22 April 2013 (UTC)
Comment Which fields from the file do you actually need to create the graphics? Dumping entire structured files into simple strings is pretty much the antithesis of Wikidata which is about structured, linked data. Plus, there could be the issue of licensing depending on how much is copied and where from. Silver hr (talk) 19:08, 26 April 2013 (UTC)
I'm not happy with this response - to me, these files (which are US government works and PD) should best be used as intact properties. You'd have to break them up into all the individual fields otherwise, as many different properties - anything less than a full dissociation into all components would be an imperfect copy, and also more trouble to make. I guess I was under the wrong impression that Wikidata was a common repository of data to use, but from this, it seems to be a collaborative enterprise in creating some kind of limited association database I don't really understand, don't see how to practically edit, and don't know what to do with. Though there is one application I know of (the interlanguage links) it is clear that any idea how to use Wikidata needs to start here - I'm going to abandon any attempt to make use of it in writing modules. Wnt(talk) 01:07, 10 May 2013 (UTC)
The problem of your proposition is its dependency on the source format: if another source is providing data in another format (like in different files or using different annotations for identifying data parts) your proposition won't be able to manage the data. The correct procedure is to list all properties which can be found in your raw data file then find the appropriate properties in wikidata anf if you can't find one, you propose a new property, then parse the raw data in order to extract values for the properties and then fill item with the strutured data. Wikidata is not a simple data storage but wants to propose a data structure which avoid the need of data parsing each each time you do a query: with a structured data format you can directly match the data with your query. Snipre (talk) 08:26, 11 May 2013 (UTC)
@Wnt: If I understand this problem correctly you just have to split your program into two pieces. Right now your taking data and a program structures it and outputs a picture. The part of the program that structures the information would have to be the part that imports the data into Wikidata in a structured form. Your output function would then take the already structured data and only generate a picture from it. I hope you don't give up your problem, and I would suggest you talk to some of the people at Wikidata:Molecular_biology_task_force who are working (I think) on similar problems. --Tobias1984(talk) 13:01, 4 June 2013 (UTC)
This proposal will be deleted: This proposal will be deleted without modification in order to fit the wikidata structure (property.value instead of raw data, separation of data and sources,...) Snipre (talk) 11:47, 2 July 2013 (UTC)
I veto the deletion of this proposal. We can move it to "property proposal/term". The proposal is just a little ahead of its time. We need to work out a couple of other things until something like this can be handled properly. --Tobias1984 (talk) 12:01, 2 July 2013 (UTC)
It seems that some reformulation is needed: better delete the proposal until a better formulation is done. This will clear this page. Snipre (talk) 09:43, 29 July 2013 (UTC)
A complement to P132 (type of administrative division), for non-administrativ settlements like urban areas/CDP/hamlets/villages etc who has no administrative function.
I will not forbid the use of P132 and this in the same item, they should complement each other, not exclude. -- Lavallen (block) 12:55, 6 April 2013 (UTC)
Comment. If we do it this way, we may also need properties for electoral circonsriptions, military divisions and various other things. I think it would be very relevant to merge them all in instance of. Instance of is supposed to tell what precisely the item is. In the case of an administrative division, its value should be equal to that of P132 anyway, so that no information will be lost. That will avoid questions like "is X and administrative division or not ?", and that would make the overall structure simpler, more scalable, and more flexible. --Zolo (talk) 13:21, 6 April 2013 (UTC)
I do not like the nature of "instance of", it's used for everything. If we can define a better usefull property for frequent cases, I think we should. I cannot even find a well-defined translation for "instance of" that makes sense for all the things it is used for. I do not propose "instance of" to be deleted, but that we should use it only when there is nothing better. -- Lavallen (block) 17:34, 6 April 2013 (UTC)
I was first skeptical of "instance of" too. That is a technical words, which means it is rather obscure, but also technically correct. The point of "instance of" is precisely that it can be used for everything. What harm is there in that ? We cannot have "type of" for everything, and maintaining a mix of two systems does not seem very clear nor convenient. For Wikipedias infoboxes, there would be no real benefit over querying instance of. For Wikidatians, it would still be easier to learn how to use a few "membership properties" than having to cope with dozens of potentially overlapping "instance of" properties (type of administrative division, type electoral circonscription, type of zone defined for statistical purpose, type of place with no administrative status, type of special economic zone, type of protected natural area, type of school district, etc, etc.) --Zolo (talk) 18:25, 6 April 2013 (UTC)
How do you use "instance of" in an infobox? Under which label? You will have a mixture of not-well-defined and well-defined properties, which will be hard to use in many cases. -- Lavallen (block) 19:19, 6 April 2013 (UTC)
I do not understand what you mean. If you want a general term, I suppose you can use "type" or "nature", but what would you use that for ? Labels are defined in infobox templates. What difference does it make whether the data you use come from P31 or from P132 ? --Zolo (talk) 19:53, 6 April 2013 (UTC)
When you make templates, it is easier to use properties with a wel-defined purpose, than inside P31 who today contain almost anything. And an urban area is not administrative (P132), it is a wel-defined type of settlement, defined by the Nordic statistical organisations. -- Lavallen (block) 08:33, 15 April 2013 (UTC)
The problem could be if there are several values for "instance of" and we wouldn't know which value to show as a type of settlement. --DixonD (talk) 09:26, 15 April 2013 (UTC)
Yes, use in templates is something we have to think about, but I do not think that multiplying subproperties is the best solution for that. We should rather have better guidelines for P31. At some point, we are supposed to be able to mark some statements as preferred, and I think it would help solve the problem. The preferred P31 for London should be "city" or whatever its administrative status. "City with more than 1 million people", "Host of the Summer Olympics", or even "capital" do not seem very relevant in P31. --Zolo (talk) 09:43, 15 April 2013 (UTC)
One part of the Swedish settlement-template has no label, and that is "category" in sv:Mall:Geobox, it defines the whole infobox. It can have multipurpose, like "city" and "urban area" and others, but as long as "instance of" is used for everything its more or less useless. I would not be suprised to find "a place where the sun don't shine" in P31 today. "Instance of Capital" would be better to replace with a binary version of P36. Stockholm is capital of at least Sweden, one County and two Municipalities (Landsting and Kommun). "Instance of Capital" with several qualifiers is another solution. -- Lavallen (block) 10:37, 15 April 2013 (UTC)
Then just a "status" property that that would not accept values like "a place where the sun don't shine", but would not impose the needless topical constraint of "admninistrative-divisionness" either ? That would be useful for other cases as well. For instance, the Musée d'Orsay is an instance of museum, but from a legal point of view, it is an instance of "établissement public à caractère administratif". A "status" property may solve that as well. --Zolo (talk) 07:38, 19 April 2013 (UTC)
An individual does not have to belong to only one class, so I don't see why the Musée d'Orsay can't be an instance of museum as well as an instance of "établissement public à caractère administratif". The problem is when an individual is described as an instance of a class and its sub/superclass, which is redundant. Silver hr (talk) 22:26, 26 April 2013 (UTC)
If I understand you correctly, you want this property to have a list of allowed values, and you don't want to use "instance of" because it couldn't have such a list? If so, where would these values come from? Nordic statistical offices in the case of Nordic countries? You could still use "instance of" and get the official settlement type to display in the infobox. Let me give an example. Suppose Swedishtown is a settlement in Sweden, and its type as defined by the Swedish statistical office is "cool town". You want Template:Geobox to display "cool town" as the value for the category field. First, you create the item "cool town", and you add to it the statement "instance of: type of settlement". Then you add the statement "instance of: cool town" to Swedishtown. Now, because Swedishtown can have other "instance of" statements, the Geobox template needs to look at all of Swedishtown's "instance of" statements and their values. Suppose those values are the items I1 and I2. Which of them is "cool town"? The template needs to query I1 and I2 and get their "instance of" statements. Then, whichever of I1 and I2 has "instance of: type of settlement" is the "cool town" item, and is the one to display. Would this solve your problem? Silver hr (talk) 22:26, 26 April 2013 (UTC)
I guess it would. A possiblility would also be to allow a limited number of values in the categories, and not everything that can be put into "instance of". -- Lavallen (block) 06:12, 27 April 2013 (UTC)
Oppose: We should be very careful about using '... of xyz' as part of a property name. By naming it 'type of settlement', we are presuming that it will only be used for settlements, for it would be rather illogical to have an item that is not a settlement of some type be a 'type of settlement'. But if the property 'type of settlement' is only used for items that are a settlements, then the '...of settlement' portion seems a bit superfluous. Wouldn't 'type' suffice? If the concern is to account for an official standardized type classification, then that should have its own property ('Nordic settlement classification' or whatever it is that makes it exclusive to an official designation). Joshbaumgartner (talk)
You can look at Q934689 to see an experiment with the use of "instance of" in an item. It would have been easier to use a "type of settlement"-property like the way "type of administrative division" is used. -- Lavallen (block) 19:17, 5 May 2013 (UTC)
Why would it have been easier? Having a proliferation of "type of" properties is unsustainable. It implies that we'll need new properties whenever we want to apply 'instance of' or 'subclass of' to a specific domain (set of valid subjects). There are thousands and thousands of different types on Wikidata. Instead of creating new "type of foo" properties for each of those many, many types and requiring people and automated reasoners to handle each of them, I think it would be far easier to use two generic properties based on W3C standards (rdf:type with 'instance of' and rdfs:subClassOf with 'subclass of') to capture that kind of information. Emw (talk) 20:17, 5 May 2013 (UTC)
Comments: maybe useful for different items than places too.
Exists in all EU countries for any administrative level, but should rather obtained by original sources (EU Statistical Office) than by fetching it from Wikipedia. --Matthiasb (talk) 13:34, 7 March 2013 (UTC)
Question. The description says it can be a NUTS/LAU/any other code. If supplied, how are we to know exactly which type of code was used?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:35 (UTC)
Not necessarily. We can still have one code field with a qualifier (whenever those are implemented). However, it's unclear whether such solution is the intent of the proposal (and whether having just one code would be enough) or something else was meant.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 12, 2013; 20:11 (UTC)
I think we need to have one entry for each level, because some countries don't have all the levels and the ISO matching is not the same, so you can't derive everything from a single entry. For instance, Romania has:
NUTS-3: județ, which is the same level as ISO 3166-2, but has different codes:
Eurostat: ROxxx
ISO 3166-2: RO-yy
Romanian Statistics Administration: SIRUTA, but also another code (the latter can be skipped/inferred from SIRUTA, but would be necessary in order to have a complete database)
Car registration: yy (this is the same as the yy from ISO)
NUTS-2/NUTS-1: Development regions and Macroregions - don't have a code in Romania, only NUTS code.
AFAIK, Germany or France have a totally different system, so we do need a code for each level.
That being said, I thing we shouldn't oppose the proposal for that technicality, but rather change and implement it :)--Strainu (talk) 07:55, 17 April 2013 (UTC)
Support --Nightwish62 (talk) 09:47, 19 April 2013 (UTC)
Comment This property seems useful. However, the criteria outlined in the proposal really describes a disaster, not merely an incident. The word "incident" often has a neutral connotation or implies a minor negative event. (In "diplomatic" terms, however, "incident" often implies something serious, but not of the nature described in the proposal.) Given that, I would suggest changing the label to 'disaster affecting'. Emw (talk) 14:32, 20 April 2013 (UTC)
Oppose per Fralambert. --Rschen7754 04:27, 27 June 2013 (UTC)
Done - both created by User:Zolo on 3. July 2013. --Nightwish62 (talk) 22:06, 1 August 2013 (UTC)
Not done - archived by --Nightwish62 (talk) 16:56, 6 July 2013 (UTC)
Wait
crowned version
.svg)
Question Why very different definition than the one given in , according to which datatype item seems to be possible? – The preceding unsigned comment was added by ? (talk • contribs).
Weak oppose Each node in a taxon's classification is deducible through the parent taxon (P171) property, or, as I argue at that property's RFD, the preferable subclass of (P279) property. In my opinion the current listing of all taxonomic ranks on many taxon items is redundant and sets a bad precedent. It seems like Lua or Wikidata queries would be a much better approach to get that chain of values, rather than listing them all out explicitly in hundreds of thousands of taxon items. Emw (talk) 23:33, 31 March 2013 (UTC)