This is an authority control identifier of the Institut für niederdeutsche Sprache (Institute for the Low German Language). This is in use at the nds.wp project in the template nds:Vörlaag:PBuB. To be fully functional this property will need a string qualifier stating the object class ('' for an author, 'T' for a work, 'K' for a corporation etc). Slomox (talk) 12:03, 11 April 2013 (UTC)
Question, if there are several different sorts of ids for people / places / publishers, wouldn't it make more sense to use separate properties. It seems simpler both to encode and to decode. --Zolo (talk) 19:32, 6 May 2013 (UTC)
I don't know. One property with a qualifier seems easier to me, but I don't exactly know about the benefits or drawbacks of either solution. --Slomox (talk) 07:53, 14 May 2013 (UTC)
Full IMDb IDs are unique so that qualifiers are not necessary. Things are different here: we have several databases with overlapping IDs (eg, author 403 and place 403) so that the value does not really have any meaning without specifying which database we are referring to. Having several properties would make statements more concise and external links easier. It would also simplify the work of bots that check for uniqueness of values. Beside, if at some point we can transform this kind of property into a sitelink, it will not be possible to use qualifiers.--Zolo (talk) 13:00, 20 May 2013 (UTC)
Comment I tried to create this property, but the webpage seems to be broken. I can't even find Gorch Fock and the link form de-wiki doesn't work either. --Tobias1984 (talk) 08:34, 27 July 2013 (UTC)
Comment How about this format of using the statement, I think that we can set the image in both statement and as qualifier. I dont think that it would be redundant because the image are also sometimes written in the Category page also.
Item: Person A
Statement: Date of birth - pending
Qualifier: Place of birth P19
Image: XXX.jpg P18
Statement: Date of death - pending
Qualifier: Place of death P20
Image: YYY.jpg P18
Statement: Date of burial - pending
Qualifier: Place of burial P119
Image: ZZZ.jpg P18
Statement: Image XXX.jpg
: Image YYY.jpg
: Image ZZZ.jpg
Statement: Commons Category P373
In every case ist must be some picture related to the person, the tombstone, mausolem, monument... something personal, not a picture of the graveyard as a whole.--Giftzwerg 88 (talk) 12:01, 11 May 2013 (UTC)
Thanks for your feedback. The various options seem tricky. Shall we go ahead with the initial proposal? -- Docu at 07:47, 19 May 2013 (UTC)
Strong support for the initial proposal. Although I see the benefit of nesting data into qualifiers, but currently, the broad consensus seems to be separate properties. This proposal will probably need a qualifiers itself that further describe the grave. Geocoordinates and maybe things like "artist that designed it" "style of grave", "erected", "moved", "restaurated". Somebody should also request birthhouse image. --Tobias1984 (talk) 07:35, 8 June 2013 (UTC)
Oppose - there are simple to much objects in the world that everything which can be photographed has its own property. --Nightwish62 (talk) 21:06, 1 August 2013 (UTC)
I have removed my support. I think it would be better to find a new solution for image properties. Interest in this is anyway zero, so it can go into the archive. --Tobias1984 (talk) 21:08, 1 August 2013 (UTC)
state or states that recognize or would recognize the subject as their citizen, but are not sovereign themselves (and were not at the time the person lived, either) [not things like Republic of Venice or Prussia]
Comments: We already have P27 "sovereign state or states that recognize the subject as their citizen", but not all (relevant) citizenships are sovereign states, the most notable example (in terms of wars happened) probably being Kurdish people. Some Wikipedias will use (some) of them for categorisation purposes (e.g. w:en:Category:Kurdish people, or w:en:Category:Chechen people used on en.wiki but not it.wiki) etc., but it's not correct to mix them with P27. Creating this property is probably needed, unless some other simple way to make this distinction within P27 is found: it's not a way to encourage nationalist discussions but to confine them to a clearly labelled place; and existing policy-conforming usage on Wikipedia exists (see it.wiki person data template). --Nemo10:03, 1 March 2013 (UTC)
"Country of citizenship" implies that the "country" recognizes some rights to the item based on the item, so it means that country of Citizenship: Kurdistan does not just mean that the person is of Kurdic ethincity (which could probably be a separate property). It means that there is a de facto or de jure Kurdistan entity that explicitly recognizes her as a citizen.
I do not think it is very convenient to distinguish between recognized and unrecognized countries (is Palestine recognized?). Wikidata is about claim made in the outside World, not about the truth. It means that if an external source claims that someone is a citizen of Sealand, we can add that here without tricky internal debates. Of course, in some contexts, it can be useful to know whether this citizenship is recongized by the UN or by a particular country, but it sounds simpler and more flexible to do it client-side. --Zolo (talk) 10:23, 1 March 2013 (UTC)
I don't understand how this relates to the proposal here. If you're speaking of P27, you're currently incorrect because the list of properties explicitly requires the country to be a sovereign state. Are you proposing to change this? Current status is that citizenships from unrecognized countries are forbidden/ignored by Wikidata, which brings us to point 2.
This is not a problem of truth. There are two distinct problems and only one is being discussed here:
whether the citizenship is relevant and verifiable for the person: this is decided by sources on the person and doesn't depend on the status of the country or our way to call the property;
whether the citizenship comes from a sovereign state: if it doesn't, should it replace the official/other citizenship (e.g. Turk) of the person in P27, be added next to it in P27, be stored elsewhere?
I am fine with the description of P27, but I do not think it can be more than a guideline ensuring that we do not add "California". Sovereignty is not the same thing as recognition. We could decide to restrict P27 to "recognized states", but I do not sure that would be feasible. There is no universally accepted list of "recognized states". Even "recognized by the United Nations may not be practical. Is Palestine recognized by the UN ? We could perhaps decide that it has been since November 2012. Would that mean that the value of a P27-claim can be set to P27 only with the qualifier "since November 2012" ? Few countries recognize Taiwan, does that mean we cannot use Taiwan (or Republic of China) in P27 ? I do not know much about Kurdish politics and I doubt there is such a thing as an organized Kurdistan political entity recognizing people as its citizens, but if there is, yes, I think it should go to P27. I do not see any problem with having several values in P27. --Zolo (talk) 15:47, 1 March 2013 (UTC)
I simply don't understand how it is supposed to work (yes I have clicked on the weblink and know that _some_ articles on :it contain an item Cittadinanza in their infobox). Can you give an example of an item where you would use this property, and the "source" you would call to assert it ? I don't really see how you know that if a state existed it "would recognize the subject as its citizen". If Austria existed, would it recognize Reinhold Messner as its citizen ? We know that the answer is "no" since it happens that Austria exists, but how can you know for non-existent countries ? If Kurdistan existed, would it be located on the territory of today's Iran, of today's Irak, of today's Turkey ? How can you know ? Touriste (talk) 12:05, 2 March 2013 (UTC)
I keep trying to understand and visited w:it:Template:Bio. On this page, there is a definition of Cittadinanza quite different from the tricky one given above which left me so perplexed. I quote the Italian template page : "Cittadinanza = da usare nei casi di nazionalità culturale differente dalla nazionalità anagrafica (es. Curdi di Turchia)". This is clearer but badly tricky. What kind of sources can be admitted ? Is it sufficient that any book (even with a strong nationalist bias) asserts that "X" is "Y" to admit the use of the property ? Let's take an example : after a few tries in Google I find a sentence in a book from Jon Krakauer that reads as follows : "the famed Tyrolean alpinist Reinhold Messner". Am I allowed to put "Tyrol" as the value of this property for Reinhold Messner ? If I find a second source that asserts that Tyrol is part of Austria, am I allowed to use "Austria" ? If I find a third source that asserts that Austria is an artificial creation and that Austrians are culturally south Germans, am I allowed to use "Germany" ? If I find a source asserting that nowadays a common culture is being born throughout the European Union, am I allowed to use "European Union" ? Am I allowed to use "Corsica" for a French citizen born and living in this island ? "Sardinia" for an Italian citizen born and living in this island ? "Piedmont" for an Italian citizen born and living in Turin ? This seems quite nightmarish. Touriste (talk) 12:25, 2 March 2013 (UTC)
Support expanding the scope of P27 and editing "sovereign state" to "country". The problem doesn't just apply to disputed territories like Kurdistan and Palestine, but also non-sovereign territories like Gibraltar, Falklands, Hong Kong, and American Samoa etc. whose citizens have an explicitly different citizenship classification than their parent nation. Putting "object is a sovereign state" in the description was a mistake in the first place. Deryck Chan (talk) 20:10, 5 March 2013 (UTC)
Oppose Touriste already described how subjective and prone to nationalism this property would be. What makes a person a Kurdish citizen, or a Tyrolean? These countries don't exist let alone do they have citizens. It's pure speculation.--Kompakt (talk) 07:11, 14 June 2013 (UTC)
Not done No response to the question of Tobias1984 since month. For me it's also not clear what exactly the property is meant to be for. However, labeled it "number of..." seems it can be queried if every season has it's own item. --Nightwish62 (talk) 09:13, 2 August 2013 (UTC)
Comment Is it with QuantityValue possible to use more than one quantity, like minutes or metres for it? That would be useful for silent movies. The property should be named "length", so that you can give a length or a time.--CENNOXX (talk) 13:24, 28 March 2013 (UTC)
Comment Yes, sure, I saw this property, so I want to discuss here whether it is possible to use it both for movies and albums. Enzet (talk) 14:26, 28 March 2013 (UTC)
I agree that a bottom-up structure would be better, if that is not possible, I support this property.--Micru (talk) 20:27, 10 June 2013 (UTC)
Support In this particular case I think an inverse link will be useful.Filceolaire (talk) 18:00, 10 June 2013 (UTC) Oppose Now I prefer edition (2) below.Filceolaire (talk) 20:40, 11 June 2013 (UTC). I have changed my mind again - see comment om edition (2) below. Support In this particular case I think an inverse link will be useful. Filceolaire (talk) 08:07, 13 June 2013 (UTC)
The image show a possible structure of what i suggest about players statistics (sorry about the quality :) ). For every team with can have the same data (team 2, team 3, ... by chronological order). The same for national teams. (Now we have the general item member of sports team). Xaris333 (talk) 00:51, 6 May 2013 (UTC)
Not done not a proper property proposal. This sites is designed for single properties, but this is a whole concept. Would be better to start a taskforce for it. Besides this: some of the values can be retrieved out of queries in my opinion. --Nightwish62 (talk) 11:55, 2 August 2013 (UTC)
I support as long as you are not limiting it to only persons. In Sweden governors are appointed by the goverment, not by the prime minister for example. -- Lavallen (block) 05:30, 1 August 2013 (UTC)
Needed, but I think that we should have a more general discussion about names (several properties vs qualifiers, and perhaps item vs string). --Zolo (talk) 07:07, 1 June 2013 (UTC)
I wonder if this should be a multilingual text to open up for transliteration. That said, the multilingual text needs a source language and I don't think thats in the model. Jeblad (talk) 11:51, 9 June 2013 (UTC)
Oppose When we get monolingual-text we can input the first and last name for Chinese without the need for another property. --Tobias1984 (talk) 08:56, 30 July 2013 (UTC)
Support as parent organization which differs from owned by, can be used to indicate the parent agency or department of government organizations. They do not own their child agencies. See Met Office infobox. Danrok (talk) 13:38, 17 May 2013 (UTC)
Support As Danrok, "owned by" and "parent" are not always the same thing. Because of "Competition-rules" some companies are not allowed to "parent" their children because they would dominate the market if they did. The relation between Sandvik (Q1753718) and Seco Tools (Q10664977) where like that until recently. Today Sandvik both parent and own all of the other company. And the "parent" and "ownership" in organisations like IKEA (Q54078) is very difficult to understand since it has a offshore-foundation in the top. The parent/ownership-structure is designed to be difficult to understand, to minimize the amount of tax they have to pay. -- Lavallen (block) 06:49, 18 May 2013 (UTC)
Comment Seems to be important, because this term is defined in law. See Parent company. But, I think it should be used for all organization parents, i.e. including government agencies. Danrok (talk) 21:15, 24 May 2013 (UTC)
I'm not really sure how it's used in enwp. It seems to be for "former developers", so it is the same as the developer property and could be done using qualifiers. I only post it here to clarify this. --#Reaper (talk) 14:17, 14 April 2013 (UTC)
Comment I think your interpretation is correct. We should do it rigorously with qualifiers (X Company developed it from May 1999-November 2003), rather than the author/developer distinction we use on English Wikipedia (which is less flexible). Superm401 - Talk03:10, 27 May 2013 (UTC)
Could be imported from English Wikipedia, maybe others.
Discussion
Template:Infobox film has both studio ("company that produced the film") and distributor ("the company name(s) of the distributor(s)). For studio, we have Property:P272, but I don't think there's a clear separate property for distributor yet. I'm leaning on this being specific to film, like screenwriter, but I'm open to other viewpoints. Superm401 - Talk02:27, 4 April 2013 (UTC)
What about renaming it to simply "distributor"? So it could be used also for other things like video games. But btw one question at this point: I don't know (I've never really understood) the difference or why there is a difference between a publisher and a distributor..? Respectively who does what.
I think the publisher is more concerned with the promotional side of it, whereas a distributor organises the operational and logistical part. Danrok (talk) 14:58, 16 May 2013 (UTC)
I'm fine with using it for all mediums. Amended accordingly. Reaper35's Counter-Strike link provides a good illustration of the difference between publisher and distributor (there is often more than one distributor, as there is there) in a non-film area. Superm401 - Talk03:16, 27 May 2013 (UTC)
I don't agree with that. It's the same old discussion and as far as I know there is no conclusion. Therefore this still remain opened. --Nightwish62 (talk) 19:06, 8 April 2013 (UTC)
I would recommend that anyone interested in this topic read through a discussion Nightwish and I have been having here and here (the latter starts with "I hear this argument"). Emw (talk) 03:27, 10 April 2013 (UTC)
Nightwish, the way you can capture this information with instance of and subclass of is the following. "studio album" subclass of "album", "EP" subclass of "album", "compilation" subclass of "album", "single" subclass of "album", (particular album 1) instance of "studio album", (particular album 2) instance of "EP", etc. Silver hr (talk) 23:49, 12 April 2013 (UTC)
Yeah, we don't will find an agreement. But the point is, at moment there are more pro than cons and therefore definitely nothing to mark as 'not done'. --Nightwish62 (talk) 00:01, 20 April 2013 (UTC)
Answer If the item has a standard license (from all licenses' items on Wikidata), then the property is not required, since it can be obtained easily; else, if the item has a custom license by its own, then it should have this property. --Ricordisamoa10:30, 23 March 2013 (UTC)
Question What would you like to tag with this property, whole items or properties themselves (in latter case, I think it would be more a qualifier, than a property)? --Faux (talk) 12:18, 24 March 2013 (UTC)
For some reason there was an error in the proposal's template call, so the example was not shown. It's fixed now. Now I understand the idea. --Faux (talk) 13:28, 27 March 2013 (UTC)
Comment Can this question always be answered with yes or no? Maybe there are situations where a more specific answer is required (e.g. yes, if the source code is published, no otherwise). --Faux (talk) 13:28, 27 March 2013 (UTC)
Strongly Oppose This is a proposal that we provide Legal Advice based on Original Research. Not just that but the legal advice is a yes/no answer with no qualifiers! We should never give legal advice. We should list the licence which applies and if a reuser wants to know if reuse for commercial purposes is allowed then the reuser should employ his or her own lawyer to advise him or her. Filceolaire (talk) 14:05, 2 April 2013 (UTC)
If you still want to have this property then the allowed values should be limited to 'No' = Commercial redistribution not allowed. If we think commercial redistribution is allowed then we should say nothing. You should change the property name to match. That is still Legal Advice but its hard to see how we could get sued over it. Better not to have it at all though. Filceolaire (talk) 19:18, 3 April 2013 (UTC)
It could potentially work provided that it was required (and enforced) that a reliable source be cited. Then again, in corner cases, it could vary by jurisdiction, so maybe there would need to be a source and jurisdiction qualifier. Superm401 - Talk22:12, 3 April 2013 (UTC)
Any reliable source will have their legal advice hedged around with qualifiers. if we leave any of that out then we are at risk. We should not give legal advice on Wikidata. Leave that to Wikipedia where they have room to expand and say "Creative Commons have advised that their CC-0, CC-BY and CC-BY-SA licenses are compatible with commercial redistribution provided the other conditions of those licenses are complied with." 26 words and not one that can be safely omitted in my opinion. Even if something similar could be cobbled together with a bunch of qualifiers it would be too easy to get wrong. We should just stick to the principal that Wikidata doesn't give legal advice. Filceolaire (talk) 08:33, 4 April 2013 (UTC)
Oppose I assume this proposal is to add data to wikidata somehow so disambiguation pages can be created using some sort of query. This won't work because disambiguation pages are language specific. The disambiguation page targets in one language can be different from the targets of the same disambiguation page in other languages. Filceolaire (talk) 11:28, 14 June 2013 (UTC)
if the disambiguation page targets in one language is different from the targets of the same disambiguation page in other languages, It should split to 2 items. Or a qualifier can be used.--GZWDer (talk) 15:07, 14 June 2013 (UTC)
See how your example looks to me: Тест (Q224615) => Контрольная работа (Q27318), Test (Q257491), test (Q3519023). Infovarius (talk) 20:09, 16 June 2013 (UTC)
It's difficult. Most words have slightly different meanings in different languages even if they are closely related. I don't want to remove language links from pages like en:System (disambiguation) just because of one mismatch. —★PοωερZtalk00:54, 17 June 2013 (UTC)
Comment - This proposal is for two new properties ("introduced feature" and "removed feature"), not a single one ("introduced feature / removed feature") - --Nightwish62 (talk) 21:09, 30 June 2013 (UTC)
Comment not sure why this have to be 'string' and not numbers? Ok, I found one element which contains characters ([2]). Are there more than this one? If so, are those also '...rev' or are there other characters? --Nightwish62 (talk) 23:32, 24 July 2013 (UTC)
Support we only use number-datatype for numbers that could be used for calculations. String datatype is appropriate here. --Tobias1984 (talk) 06:40, 31 July 2013 (UTC)
Unique ID number used by Riksantikvaren (the Norwegian Directorate for Cultural Heritage) for their kulturminnesøk database. The ID number refers to a single cultural heritage site.
Q755010 - Borgund Stavechurch which has Kulturminne ID 83933
Format and edit filter validation
1321237
Robot and gadget jobs
Importing IDs from municipality based lists of cultural heritage sites, for example: nb:Liste over kulturminner i Drangedal, as well as creating and syncing such list in multiple languages.
I'm currently engaged as a Wikipedian in Residence with Riksantikvaren. This property would make it a lot easier promote the use of wikipedia in collaboration with the Kulturminnesøk database and the two Norwegian language and one sami language wikipedia. Profoss (talk) 12:43, 24 June 2013 (UTC)
Support Each of 125 000 cultural heritage sites within Norway have this unique ID. Adding the ID to Wikidata may enable syncing between wikiprojects and The Norwegian Directorate for Cultural Heritage H@r@ld (talk) 09:18, 28 June 2013 (UTC)
Comment I think this at some point should be coordinated with Europeana (local version Norwegiana), they will probably need geographical object ids at some point. For now it is more important to get the present projects with Riksantikvaren going, so I say use the available ids and set up a property to handle this unless we should take the work to define generalized location ids. Problem is that some items will need several mutually exclusive locations. There is at least the position itself, then artefacts on that location (that would be Riksantikvarens ids), then also different names for that location in space-time (can have directionality and language constraints - two sides of a mountain with different names), and possibly different roles with separate names (island, city, municipality, etc). I'm tempted to say take the whole id discussion later and use a specialized id for now. Jeblad (talk) 04:36, 6 July 2013 (UTC)
Support Even in the future these IDs will be valuable for historical reasons. And currently they can be of great practical value for maintaining lists of Norwegian cultural heritage sites etc. related to the cultural heritage wikiproject. Danmichaelo (talk) 19:28, 2 August 2013 (UTC)
length as a measured dimension (m) of an object, that can also include: railways, metro lines, highways, trunk roads. SI base unit for length is metre (m), although "km" would be a recommended unit for roads, railways, etc.
a great number of railways and important roads, in many Wikipedias, are provided with infoboxes, including "length" (in km). A bot should parse them without trouble. It is easier to find information of regional/less relevant lines in the relative national Wikipedias.
We should also try to formally define how "length" differs from the related idea of "height", which has a somewhat ambiguous meaning but would be another very useful property. Emw (talk) 14:50, 20 July 2013 (UTC)
Height can go with width in an (at least) two dimensional and depth (the third dimension, used in common language to denote how deep we are under water but do not seem relevant here), and is usually related to verticality. Lenght seems dimension independant, for example a distance in a 3D space is a length. TomT0m (talk) 14:59, 20 July 2013 (UTC)
Also in common language, size is similar and related. Anyway in french we got taille, longueur, largeur, profondeur, distance ... TomT0m (talk) 15:08, 20 July 2013 (UTC)
We have specific properties for many things, why would political parties be excluded? Why swap the word leader with headed, when leader is the word in common use? Danrok (talk) 22:41, 17 May 2013 (UTC)
I do not care very much about the "name" of any property, since the title of the "leader" depends on which parti. The leader of Green Party (Q213451) has the title "språkrör" in Swedish and they are two. Feminist Initiative (Q388981) has (today) three leaders with the title "talesperson". Other parties prefer the title "partiordförande" or "partiledare". -- Lavallen (block) 06:28, 18 May 2013 (UTC)
I think a specific property makes sense only if it makes the statement more precise. chief executive officer (P169) arguably does that (a CEO is not a chairman), but I do not see how "Conservative Party: party leader: David Cameron" is better than "conservative party: leader: David Cameron". That said there are some properties that I would definitely support deleting. --Zolo (talk) 06:58, 18 May 2013 (UTC)
Parties do have more than one type of leader, e.g. the elected political leader(s), a chief executive, chairpersons, as well as board members. See for example: [3]. But, I have no objection to a generic "leader" property provided we are able to qualify the persons with roles, CEO, party leader, etc. Danrok (talk) 01:25, 17 June 2013 (UTC)
DPLA (Digital Public Library of America) is an internet portal that acts as an interface to millions of books, paintings, films, museum objects and archival records that have been digitised throughout United States. This id will be used to link with online resource available through that site.
Support I agree with the property, I'm just not sure about the filter definition. Most of the examples on the linked page content also slash signs, while others are just 6-digit numbers. Looks more like [0-9/\-]{1-12}, but it's worth a second look from someone more familiar with the system.--Shlomo (talk) 16:56, 30 June 2013 (UTC)
There are multiple official classifiers in Russia. It is possible that ОКТМО will replace ОКАТО in the future ([6]). But currently they are exists in parallel. There was no ОКТМО codes for populated places in the past. — Ivan A. Krestinin (talk) 18:08, 30 July 2013 (UTC)
I'm thinking of tennis tournaments at the moment, but it certainly has use beyond that. Basically for all types of sports that are played on different surfaces.--Kompakt (talk) 06:16, 27 May 2013 (UTC)
We need a more general property to define in which matter the istem is made not only for sport surface. Snipre (talk) 19:05, 10 June 2013 (UTC)
Support - label should be "surface played on". Solutions with existing properties don't really capture what needs to be said. Simple queries about materials will otherwise result in things like "Wimbledon" being returned. --Tobias1984 (talk) 11:41, 3 August 2013 (UTC)
Support if the label is changed to 'surface played on'. This property should probably be used to describe the venue rather than the event but either way the property is needed. Filceolaire (talk) 13:44, 3 August 2013 (UTC)
It would take a long time still we can clearly assign every coordinate to the corresponding administrative unit (like city), so we can't make queries like 'get all disasters which occurred in Italy'.
This is maybe best applied to Contries who does not have one person per electoral district in the parlament. The Swedish Riksdag for example has 349 seats, but only 29 electoral districts, and svwp has articles for every electoral district, also historical. Lavallen (block) 12:25, 28 July 2013 (UTC)
Support Even in one member constituencies the electoral district boundaries are usually different from Administrative divisions and need their own property. Filceolaire (talk) 12:28, 5 August 2013 (UTC)
Correct, it's true even in Sweden. The Electoral districts in Sweden are not corresponding to the administrative division, even if it is true in some cases. We have articles about all the Swedish districts on svwp, they are mainly used as lists of MP's. -- Lavallen (block) 12:53, 5 August 2013 (UTC)
Most properties mentioned bellow (average_depth, maximum_depth, volume, etc) can be fetched and added automatically from VISS webserver-interface using this property as a key.
Swedish National Water Administration is an important source for information for most lakes, watercourses and fjards in Sweden. Esquilo (talk) 11:10, 23 May 2013 (UTC)
Wait Can we create an unique property for the different national classifications instead of different properties for each natioanl code ? See above for Russia Snipre (talk) 12:50, 29 July 2013 (UTC)
If it is feasable, but the discussion above indicate such solution to be very complicated and awkvard to use. /Esquilo (talk) 14:09, 30 July 2013 (UTC)
If your code can handle different properties in the same code, it can handle different qualifiers too. Snipre (talk) 15:47, 30 July 2013 (UTC)
We need a system here on Wikidata that is easy to use both for ordinary users and for the code in our templates on Wikipedia. Otherwise will this place only be a place for your own entertainment. It's also hard to explain for external data-users why they have to scan through all of Russia, when they are searching for a lake in Sweden. -- Lavallen (block) 13:35, 1 August 2013 (UTC)
a clinically significant interaction between two pharmacologically active substances (i.e., drugs and/or active metabolites) where one substance (so-called 'precipitant') alters the pharmacokinetics or pharmacodynamics of another substance (so-called, 'object'). The property should be used in this direction: <object> <drug action altered by> <precipitant>
There should be bots automatically updating drug interaction information from public datasets (depending on what we want to include, there can be hundreds or even thousands of such interactions)
Comment I support the addition of a data element like this but wonder if it should be more specifically called "drug-drug interaction" to distinguish it from drug-food, drug-allergy, and drug-condition interactions. Does the direction of the arrow specify the precipitant and object drugs involved in the interaction? User:Boycer
My intention was to make this property useful for both drug-drug and drug-food interactions (see description). I see no need to create distinct properties at this stage. --Matthiassamwald (talk) 20:15, 31 July 2013 (UTC)
One of the of the goals of introducing this term is to integrate drug-drug interaction data into wikipedia. My opinion is that it will be better to keep the term very specific because the mechanisms, epistimology, and approach to managing the various kinds interactions in clinical settings patients vary significantly. Also, I see that there might already be a term Drug InteractionUser:Boycer
I am not sure about the 'directedness' of the interaction. Originally I thought I would simply introduce this as a symmetric property. On the other hand, sources like http://www.crediblemeds.org/healthcare-providers/drug-drug-interaction make a clear distinction between object and precipitant... Do you suggest to make this distinction clear in the property definition? If so, could you suggest an improved (yet still somewhat short) description? --Matthiassamwald (talk) 20:16, 31 July 2013 (UTC)
I think that clarifying the direction of the interaction is important. Here is a suggested description based on work forthcoming from the 2013 AHRQ DDI Conference: "a clinically significant interaction between two pharmacologically active substances (i.e., drugs and/or active metabolites) where one substance (i.e., precipitant) alters the pharmacokinetics or pharmacodynamics of another substance (i.e., object)."
If the description I offer in the previous line is acceptable, I think we should also clarify somewhere that a clinically relevant interaction is defined as an interaction that is associated with a clinical outcome serious enough to warrant the attention of clinicians and/or systems involved in the medication therapy process. Depending on the context, the “attention” that a clinically significant potential DDI warrants might include a change in therapy, monitoring, and/or patient education. This will help avoid publishing large lists of DDIs of questionable or unknown clinical relevance under the suggested term. Boycer
To incorporate these suggestions, I changed the label from "drug interaction / Arzneimittelwechselwirkung" to "drug action altered by (en) / Wirkung beeinflusst durch (de)". I changed the description from "interaction of a drug with a substance (usually another drug) that affects drug activity when both are administered together" to "a clinically significant interaction between two pharmacologically active substances (i.e., drugs and/or active metabolites) where one substance (so-called 'precipitant') alters the pharmacokinetics or pharmacodynamics of another substance (so-called, 'object'). The property should be used in this direction: <object> <drug action altered by> <precipitant>"..... The label and description should certainly not become any longer than that! --Matthiassamwald (talk) 11:01, 2 August 2013 (UTC)
Support I think this approach will be quite satisfactory. Boycer
Ideally, we could use this property to represent interactions of different severity and clinical significance, and differentiate between different severity/significance levels using Wikidata qualifiers (we are not limited to simple triples in Wikidata). Tobias1984 -- Do you have suggestions for this? In Wikipedia, will we be able to create queries to only list interactions with a specific significance level and exclude others? This would help to not clutter the UI with interactions that are only mildly relevant to most users. --Matthiassamwald (talk) 11:01, 2 August 2013 (UTC)
Support - And a qualifier could say something like "interaction = strong" or "interaction = reduces effectiveness". If we keep the number of items we link to low then we can make some really intelligent queries. --Tobias1984 (talk) 23:19, 4 August 2013 (UTC)
One could use qualifiers to add further information about the nature of the interaction. physically interacts with (P129) is a wholly different kind of property. In a drug interaction, the drugs are not interacting directly/physically. So I think the property I proposed is entirely novel. --Matthiassamwald (talk) 20:15, 31 July 2013 (UTC)
I agree that the proposed term represents a distinct concept from physically interacts with (P129) but disagree with the comment that drugs do not interact directly. While most interactions involve some indirect mechanism, adsorption and chelation drug-drug interactions are in fact physical interactions. So, I would distinguish the proposed term from physically interacts with (P129) by stating that its both broader and of a different focus. Its broader in the since that some drug-drug interactions be of type physically interacts with (P129), and broader in the since that we are about the clinical implication of the interaction. User:Boycer
I know that there are few cases where drug interactions also can be caused by direct interactions. Usually, this is not the case. Still, they are clearly distinct properties, and one cannot substituted for the other. Any other, more subtle relationships are completely out of scope for Wikidata purposes. --Matthiassamwald (talk) 11:01, 2 August 2013 (UTC)
Support I think the proposal is mature and ready for inclusion into Wikidata now, thanks to the feedback from Boycer and Tobias1984. --Matthiassamwald (talk) 08:50, 5 August 2013 (UTC)
Support I agree and look forward to the discussion of the qualifier(s) Boycer
There are many cases where I wished we could express cause, and I would suggest a generic property to be used as a qualifier. In this case, I guess it could qualify "key event: destruction" (or "destruction date: 226 BC" depending on the format we choose). --Zolo (talk) 16:55, 17 June 2013 (UTC)
Sounds like destructive force would be more appropriate, things like flood, fire, earthquake and explosion would fit. Cause of destruction is quite ambiguous. Danrok (talk) 19:34, 23 June 2013 (UTC)
Support this is currently the best solution to store this information. It can be used both on its own e.g. the Hindenburg or as a qualifier or for cities that were destructed multiple times in their history. We should link to the specific natural disaster if it has an own item 1906 San Francisco earthquake (Q211386) --Tobias1984 (talk) 11:32, 2 August 2013 (UTC)
Right. Beside this: The problem how to link exist in most other properties to. Should we list all mayors or a city individual or create a item 'mayors of city xyz' and put this into city xyz? Same for sport contest (link individual players or the 'English football team of WM 2006'), movies (individual cast members or outsource the cast members to it's own item and linking this), and so on and so forth. So this is a big question which concern many properties, therefore we should discuss this outside this proposal.
Comment - Although the string is only composed of numbers we are not going to do any calculations with it. Plus we don't want it to convert into other number formats. I think datatype string would be more appropriate. --Tobias1984 (talk) 15:14, 29 July 2013 (UTC)
I asked at Property talk:P605 if the NUTS code (P605) could be used for LAU codes as well, since they are an extension of NUTS 1-3 and a direct continuation of NUTS 4-5. I was asked to move the discussion here in order to attract more contributors. Please make your opinion whether we should rename/redefine NUTS code (P605) to NUTS/LAU or we should create a new LAU property. I personally prefer the first variant, but both of them are acceptable for me. Shlomo (talk) 10:17, 12 June 2013 (UTC)
I don't think we need special properties for LAU1 and LAU2. Particular levels and versions of LAU can be described by qualifiers. (Actually, I don't think we need special properties for LAU and NUTS either, but I can live with this).--Shlomo (talk) 06:59, 30 July 2013 (UTC)
Yes, I agree. My link was to point out that this new property would indeed be very useful, among other things, to substitute many other current properties used to identify municipalities by a code number. --Albertvillanovadelmoral (talk) 09:20, 30 July 2013 (UTC)
Better used directly the offical document of Eurostat here and put Eurostat as source. It's time to use offical document instead of infobox data. Snipre (talk) 09:11, 30 July 2013 (UTC)
This is part of the ISO 3166 standard published by the International Organization for Standardization (ISO). It defines codes for country names which have been deleted from ISO 3166-1 since its first publication in 1974. The official name of the standard is Codes for the representation of names of countries and their subdivisions – Part 3: Code for formerly used names of countries. It was first published in 1999. Each former country name in ISO 3166-3 is assigned a four-letter alphabetic code.
1. Any subject must not have both ISO 3166-3 and ISO 3166-1 codes.
2. There must not be two subjects with the same ISO 3166-3 code. (The code is unique.)
3. After releasing an update of ISO 3166‑3 [9] the new values could be imported.
4. More complex rules for value checking of a code abcd (could change in the future):
a) cd value: "HH" or "XX", ab value any
b) cd value: "AA", ab value is one of ISO 3166-1 Alpha-2 codes
c) cd value: one of ISO 3166-1 Alpha-2 codes, ab value any
Comment Datatype should be String. The future of this property is seemingly limited as the US gov't is phasing out FIPS codes in favor of GNIS IDs. Mrwojo (talk) 16:50, 26 March 2013 (UTC)
Having the data around might still be useful. There may be applications of FIPS codes beyond that of the government, that may continue using those codes after the government stops, or someone may need the codes for some historical reason, etc. —Scott5114↗[EXACT CHANGE ONLY]18:53, 15 April 2013 (UTC)
That is "Alby, Ånge kommun". "Alby, Botkyrka kommun" is missing in that list, since it ended to exist as an independent urban area in the 1970's. But there is an object for it. --- Lavallen (block) 14:49, 1 August 2013 (UTC)
tätortskod in sv:Mall:Ortsfakta Sverige. Observe that this code sometimes is written with an "T" in the beginning, and sometimes not. Today I and Statistics Sweden prefer a "T" in the beginning, but it is not mandatory. -- Lavallen (block) 14:49, 1 August 2013 (UTC)
But be carefull with botimport to Wikidata. Many articles are about 2 or 3 three urban areas. Many articles have no code in the infobox yet, and many articles on NLWP and SVWP are not identified yet. We will do an inventory of this set of articles very soon. -- Lavallen (block) 15:28, 1 August 2013 (UTC)
Pastoratkod" (not been able to translate it, it's an administrative level between Parish and Diocese for the Church of Sweden, the Church of Sweden is still not completly separated from the administrative division of the nation, but it will shortly in the future)
Support Looks okay too me. I think both Pastoratkod and Församlingskod translate to "parish code" in English. —Ruud13:55, 1 August 2013 (UTC)
Most likely, but they are two different kinds of Parishes on two levels. Every församling is inside a pastorat, and sometimes, like in the example, there is only one församling in one pastorat. -- Lavallen (block) 15:31, 1 August 2013 (UTC)
I also plan to create a bot for automatically porting data from ontologies/linked data sources into Wikidata (in this case, from drug interaction data from NDF-RT and DrugBank). Maybe there could be some synergies with this suggested import from HPO? --Matthiassamwald (talk) 18:56, 5 August 2013 (UTC)
oppose datatype - items can be created for those limited number of shapes, plus the term need to be translatable. --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
oppose datatype - items can be created for those limited number of types, plus the term need to be translatable. NA could probably be NoValue? --Tobias1984 (talk) 15:38, 5 August 2013 (UTC)
Comment I think this should be generalized to all foods, substances,... and should get the species qualifier to distinguish humans from other animal. Example:
chocolate
edibility = palatable / edible
species = human
edibility = may be poisoneous
species = dog
In the case of poisenous foods we should try to add another qualifier that links to the item about the poison and the concentration that would be lethal. --Tobias1984 (talk) 11:03, 2 August 2013 (UTC)
In my opinion we need a certain amount of basic language properties in order to make semantic relations between items. Owning, maintaining and approving something would never get mixed up in a day-to-day conversation. So I don't see a point in combining them on Wikidata. This proposal will also get rid of two boolean-datatype proposals (See approved by OSI). I also don't see the connection with "executing authority/power of decision". Having something and doing something are just too far apart to be combined in one property. --Tobias1984 (talk) 18:08, 7 August 2013 (UTC)
Oppose – We already have proposals for qualifiers until and as of which are waiting for the time datatype. If any of these two is used, it automatically implies "former", so a more unprecise former qualifier is not needed. Byrial (talk) 23:36, 13 May 2013 (UTC)
Dear Byrial and Yair rand, for historical items the as of and/or the until dates are often unknown. How would you then be able to record that the property is not currently valid anymore? How could you tell for example that a lake is a former lake and not a current lake?, that a building was an Royal Airforce station, but not anymore? The until qualifier will only allow dates, so it doesn't allow "unknown, but definitely before today", which is what former would mean. --NormanB (talk) 10:08, 14 May 2013 (UTC)
Yes, it allows unknown. For unknown dates, you can always use "until somevalue". "somevalue" is a special value indicating that a value do exist but it is unknown. Alternatively, I think you will also be able to use a time value with a very little precision, like for instance a 1000 year range. Byrial (talk) 13:42, 14 May 2013 (UTC)
Support, because this qualifier will let us handle situations that "until" and "as of" won't handle well. I disagree with one of Byrial's points in particular. To say something is true "as of" a certain date does not necessarily mean that it is no longer true. If I have a source saying that the Mayor of London on 30 July 2012 was Boris Johnson, that doesn't mean he is no longer the Mayor.
I also think "until" "somevalue" doesn't clearly imply former status. Why can't "somevalue" refer to an unknown date in the future? And using a very imprecise time value is an ugly kludge. How would people know what value to search for, for example? It's much better to add a clear "former" qualifier.
My one concern about the proposed "former" qualifier is that it is possible for "former" statuses to become true again (e.g. if a former Mayor is elected Mayor again later), so I think the qualifier should take an (optional) time value to specify when the statement was made. --Avenue (talk) 00:43, 16 May 2013 (UTC)
1) I think that it would be abuse of "as of" to mark a point somewhere in a time range, but even if that is deemed acceptable you can still also use "until somevalue" in addition to that. 2) How could "somevalue" be a future date? That would mean that you would be able to predict the future. Well no immortal person can be Mayor of London forever, but there would be no point in stating that with a "until somevalue" qualifier. 3) If a former mayor (statement using "until" or "former" qualifier) becomes mayor again, then you create another statement for this fact with a new "from" qualifier" Byrial (talk) 06:28, 16 May 2013 (UTC)
1) The natural English meaning for "as of" doesn't seem so restrictive to me. For example, see the asof template on enwiki. If the qualifier was called "as at", I would be more likely to agree with you.
2) I see this as mainly being a matter of good style. Even if "until somevalue" was equivalent to "former", it's much less intuitive, and I think the readability of data is especially important on an open wiki like this. I'm also still unconvinced that future dates make no sense, even for "until", although a good example escapes me at present.
3) My point was that an undated "former" qualifier runs the risk of later becoming incorrect, and that adding the date the statement was made would avoid this risk. I don't see any way of avoiding this problem with the "until somevalue" approach. Yes, adding a new statement with a new "from" qualifier could fix the problem (once someone gets around to doing that), but I think we should try to avoid making statements that may become inaccurate until someone gets around to fixing them. --Avenue (talk) 08:45, 16 May 2013 (UTC)
Ad 2) When Boris Johnson would announce his resignation per 2014-01-01, the until date would lie in the future.
Ad 3) Avenue, I agree with you that there is a chance that an undated 'former' qualifier later becomes incorrect. But this is basically true for all information on Wikidata. Do you really feel we should record a 'per'-date on every 'former'-qualifier to prevent this in this case? --NormanB (talk) 23:03, 16 May 2013 (UTC)
2) I was looking for an example where the date was in the future, but still unknown. Maybe something like deprecated software features, or a situation like the cheating husbands puzzle.
3) No, I think most "former" qualifiers wouldn't need a date, because that status is unlikely to change. I do think it could be useful in some situations though. I did propose the date should be optional. --Avenue (talk) 23:39, 16 May 2013 (UTC)
Comment @Byrial: "Former" means "until some date, which for sure lies in the past". So, even if the until date is unknown, it is still certain that it lies in the past. This is clearly not the same as "until somevalue", which means that the until date is not known at all. When we stick with the example of Boris Johnson, the following statement is currenly valid, while he is still mayor, which shows that "until somevalue" is not the same as 'former': <since>='2008-05-04' and <until> = 'somevalue'. --NormanB (talk) 23:03, 16 May 2013 (UTC)
NormanB and Avenue: Please give a concrete example of a still valid statement where it would make sense to use "until somevalue". If "somevalue" is the future, how can you know that it will happen: 1) if it because everyone eventually dies, and thus cannot hold an office forever, it makes no sense to state that for every use of position held (P39) and other properties. 2) if it is because there is a planned or announced date for something to end, you can enter that date as value instead of somevalue. Byrial (talk) 08:13, 17 May 2013 (UTC)
Dear Byrial, I already gave the example of Boris Johnson with <since>='2008-05-04' and <until> = 'somevalue'. It may be wrong or useless in your opinion to use 'until somevalue' this way, but that doesn't make the statement invalid. So people could use 'until' like this, without the intention of implying 'former'. 'Until somevalue' simply means something else then 'former', so I don't think we should try to see if we can use it as an equivalent when it is not. This can only cause trouble. 'Former' is equal to 'until somedate in the past', but such value for 'until' will not be possible, or will it? --NormanB (talk) 11:55, 17 May 2013 (UTC)
Yes, it is not technically false to say that Boris Johnson will stop being Mayor of London some unknown date, and I admit that it may be a source of errors to demand that "somevalue" must be in the past, so I regret that I proposed that. However I still feel that it is unnecessary to have both "until" and "former" qualifiers, as you will always be able to use "until" with some given past date to indicate "fomer". For the examples in the proposal, it could be: RAF Abbots Bromley (Q7275121) instance of Royal Air Force station (Q7373622) until 31 March 1949, Aalst (Q2661558) instance of municipality of the Netherlands (Q2039348) until 1923, Lake Agassiz (Q390804) instance of lake (Q23397) until 6200 BC precision 250 years (or whatever precision the sources for the claim say). You will even be able to specify different precisions backwards and forwards in time according to meta:Wikidata/Data_model#Dates and times. Byrial (talk) 13:09, 17 May 2013 (UTC)
I am glad that you agree that 'until somevalue' is not equal to 'former'. But I have to disagree when you say that "you will always be able to use "until" with some given past date to indicate "fomer"". Cleopatra IV of Egypt is the former wife of Antiochus IX Cyzicenus. The from and until dates of their marriage however are unknown. I don't see which 'until' date could validly be used here. --NormanB (talk) 15:30, 17 May 2013 (UTC)
For someone who is not able to speak Norwegian or who simply isn't aware of the impact when the "until date" is filled with "unknown" and therefor doesn't search the entire internet for it, so in most practical situations, the "until date" in this example is unknown. Can we agree on that? --NormanB (talk) 00:50, 18 May 2013 (UTC)
And even if such a date could be conceived, please consider practical use. A list like this could be automatically generated from Wikidata data. This would be easy if all relevant former Royal Air Force stations can be recognised by a 'former' qualifier. If such qualifier does not exists and the 'until'-date would have to be used, the query will become much more complex, since Royal Air Force stations can then only be included in the list when 1. an until-date qualifier is available, 2. the value of that is not empty or equal to 'somevalue', 3. the value is a date in the past. And getting a Royal Air Force stations on the list would be difficult as well. In stead of just adding a 'former'-qualifier, one would have to come up with some "until-date". If the until-date is not clearly known, this can be a lot of work or lead to the use of made-up dates. --NormanB (talk) 15:46, 17 May 2013 (UTC)
I don't know how difficult it will be to make the query as the query entity does not yet exist, but it is something you only have to do once to make the list. And yes, it may be more work to enter an until qualifier with a date value, than just a former qualifier without a date, but you should enter the until date anyway, and then nothing is saved on that account. And if somebody deliberately enter made-up dates not supported by a source, they should be kicked out of Wikidata. Byrial (talk) 17:54, 17 May 2013 (UTC)
Why should you enter an until date anyway? When someone can't find the until date, they could add the 'former' qualifier, and that would be correct in itself. --NormanB (talk) 01:01, 18 May 2013 (UTC)
Support, if you have several sources writing about a person being a former mayor who is now retired, but it is unclear in what year/date he stepped down, the until-property cannot be used. If you have sources that confirm an old airfield is closed, but you cannot find a source for the year it was closed, the until-property cannot be used. In those kind of situations 'former' can be useful I think. - Robotje (talk) 05:19, 18 May 2013 (UTC)
The point is that you don't have to state an exact date/year. You will be able to add a "precision"-parameter to a time-value that allows you to specify a range of time. As to your example of airfields, this would probably be the 20th century (if you have no idea when the airfield was established), or "from 1900 to 2013" or something similar. The same is true with the mayor whose retirement date is unknown - still you'll be able to specify this date with a precision of years, decades or at least centuries. A "former"-qualifier doesn't have this more precise information, for it can't tell whether something ended yesterday or 5 million years ago.--Kompakt (talk) 09:07, 18 May 2013 (UTC)
Support, specification of a start/end date is not sufficient. For many object (buildings, castles) the exact dates of a change of function maybe unknown so the qualifier 'former' will help. Michiel1972 (talk) 22:28, 5 June 2013 (UTC)
Support I'm not sure we can have a property with no object like this. Maybe it has to be "former"->true.
I had thought a from date range and an until date range would do this but we have to follow what sources say so I've come around to this property. Filceolaire (talk) 20:40, 6 June 2013 (UTC)
Oppose If each statement has to be sourced then you will get a date for the end of a characteristic or at least an interval. This qualifier is dangerous because it will be mainly used by people knowing that something is not more valid but without knowing exactly when this applies. Wikidata need sources and even if the sources are not providing an accurate date, with a source you can define the "until date" from the publication date of the source. Snipre (talk) 13:29, 28 June 2013 (UTC)
Dear Snipre, specifiying an until date from the publication date of the souce would be really wrong. Take for example an article dated march 2nd 2013 about a former army base. If it is unknown until when the base was in use, using march 2nd 2013 would be nonsense. That would be entering wrong info into Wikidata. --NormanB (talk) 00:46, 4 August 2013 (UTC)
Dear Littledogboy, I sorry to say that 'until:somevalue' does NOT do exactly this, since 'somevalue' could be any date and former implies a date in the past. Former means the same as 'until:someday in the past'. If you prefer creating a value 'somedate in the past' for 'until' I could live with that, but I still feel it is much more usefull to use the term 'former' in stead. --NormanB (talk) 00:46, 4 August 2013 (UTC)
Oppose - boolean datatype is not on the roadmap and contrary to the semantic framework of Wikidata. Either this has to be changed to "former instance of", "former subclass of" (both item datatype) or handled with qualifiers. Example:
I chose "abnonded site" because there are still some buildings left that can be identified as airforce infrastructure. After that would be eroded or demolished I would add:
instance of (P31) = Abandoned site (or "abandoned air force base" if it needs to be more specific)
Oppose. Tobias1984's example above looks fine to me, we don't need another property to complicate things. For most things, start and end dates are known. Even if they are not known precisely, the time datatype allows things like "in the 1940s" or "in the 20th century". Mushroom (talk) 16:36, 7 August 2013 (UTC)
Ah, didn't see that, thanks for the pointer. Would still be nice to have something for buildings and other objects. And if a number datatype's going to be available in the future, all the better! Schneelocke (talk) 21:04, 10 August 2013 (UTC)
Yeah, we will have to see how the different height measurements of buildings can be handled, but until then we are not going to run out of work that could be done :) --Tobias1984 (talk) 14:07, 11 August 2013 (UTC)
Support Redundancy is underrated. It's useful for checking for errors, among other things. And sometimes you might not even know the page number. Anyway, when citing something in a compilation of chapters by different authors, chapter titles (while perhaps technically redundant) are often seen as a necessary part of a complete citation. --Avenue (talk) 09:11, 27 March 2013 (UTC)
Support - I support chapter name, but chapter number should be a value/number and not a string. I would go for "chapter name" and "section number". "section number" would be also useful for law-related items that could link to the paragraph in which the law is stated. --Tobias1984 (talk) 11:36, 8 May 2013 (UTC)
Comment - We need to clearly distinguish a cited reference work from the citation of that work. Page numbers etc belong in the citation of the work, they reflect the way the work is used by the citing editor. One work may be cited many times in many places and for many purposes. LeadSongDog (talk) 21:02, 5 June 2013 (UTC)
Support I Agree, i proposed these 2 properties but i prefer your idea: "#Emigrated on date" must be a qualifiers for "emigrated to"! ...Should i change the property proposal? Thanks LucaBiondi (talk) 14:33, 3 August 2013 (UTC)
Support Hi Nightwish62, i proposed these 2 properties but i Agree with you! "#Emigrated on date" will be a qualifiers named 'related date' for "emigrated to"! I just wanted to ask if it was necessary to modify and unify the two property proposal?
Oppose Use point in time (P585) as qualifier to 'Emigrated to'. Some people might emigrate twice over the course of their life and it needs to be clear which data parameter applies to which migration. Filceolaire (talk) 20:13, 5 August 2013 (UTC)
Support Hi Filceolaire, I proposed these 2 properties and i agree with you: "emigrated to" will use point in time (P585) as qualifier for the related date'.
Comment Consensus seems to be to use existing time-properties. I'm going to archive this unless somebody would like to add something. --Tobias1984 (talk) 18:22, 7 August 2013 (UTC)
Support However, it should be used for particular versions of a license, such as GNU GPLv3 (not all versions of the license are necessarily approved). These version entities may need to be created. Superm401 - Talk21:09, 2 April 2013 (UTC)
Whether the license has been approved the Free Software Foundation as a free license. Not to be confused with whether they consider it copyleft, or whether it is compatible with the GPL.
Comment FSF doesn't require freedom for opinion and non-utility artistic works. It uses CC BY-ND for articles at its sites, but doesn't consider it free. So the description probably needs to be very clear on that; maybe make the main label more detailed. --AVRS (talk) 10:34, 25 April 2013 (UTC)
Comment What about a qualifier for "instance of: free software license"? Something general like "according to". --AVRS (talk) 10:39, 25 April 2013 (UTC)
But GNU FDL is accepted (though not endorsed) by Debian only when used without invariant sections. --AVRS (talk) 11:43, 25 April 2013 (UTC)
significant events associated with the subject, opening date, premiere date for a movie, in service (aircraft), production started (manufacturing), ship naming and launching, etc.
Strong support. To respond to the comments from JFLewis above:
The only Oppose above is from Nightwish who follows it up with "you're right" which sounds like he is withdrawing the Oppose. How does no Oppose votes turn into 50% Oppose?
'More direct' time (and location) properties means a special time (and location) property for every type of event. Hundreds of them. With users having to try and find the right one. This is not better.
I think I will create this property. I am afraid I do not understand the reasons given by John F Lewis. What does "redundant to itself" mean, and why is it ambiguous ? --Zolo (talk) 16:48, 12 August 2013 (UTC)
Done with two more supporting votes the property has majority support. Further discussion should give the property some development time and then take the route of an RfC if needed. --Tobias1984 (talk) 16:59, 13 August 2013 (UTC)
Property: residence
Value: country A (say, this is the place the person was born and lived for the first years)
qualifier: start date
Value: XX.YY.ZZZZ
qualifier: end date
Value: XX.YY.ZZZZ
Property: residence
Value: country B (say, he makes here a longer stay for several years, e.g. for education)
qualifier: start date
Value: XX.YY.ZZZZ
qualifier: end date
Value: XX.YY.ZZZZ
Property: residence
Value: country A (say, he came back to the country he has born)
qualifier: start date
Value: XX.YY.ZZZZ
qualifier: end date
Value: XX.YY.ZZZZ
Property: residence
Value: country B (say, this is the country he has emigrated to)
qualifier: start date
Value: XX.YY.ZZZZ
qualifier: end date
Value: XX.YY.ZZZZ
qualifier: asvalue: emigrant
I think "AS" generic qualifiers is needed, also for other statements. It is a very generic qualifier which can be used for many claims. We could make the example above why such a qualifier is needed.
LucaBiondi (talk) 11:25, 7 August 2013 (UTC)
Support for the proposal, but against use it instead of character role (P453). Let me explain why: Three month ago we had two properties: one 'starring' and one 'support actor/actress'. It was me how made a request to one property 'cast member' (Wikidata:Requests_for_deletions/Archive/2013/Properties/1#Property:P482), which was agreed. Since then, we didn't have any information anymore to distinguish between starring and support roles. As also told in the deletion request, the idea was to make this distinction by a 'as' qualifier. Now let's show what's happen when we merge 'role' and 'as':
Item: The Lord of the Rings: The Fellowship of the Ring
Property: cast members
Value: Elijah Wood
qualifier: as (formally 'role')
Value: Frodo Baggins
qualifier: as
Value: starring role
So the as would be used for the role as well as to describe the role type. I think this isn't good, therefore I suggest we remain the 'role' property. --Nightwish62 (talk) 22:43, 7 August 2013 (UTC)
Any useful information which cannot be described semantically. Will be replaced by a "Comment" Property with multilingual text datatype once this datatype is available.
Support as nom. There are many cases where there is additional information which cannot be described using the properties and datatypes available at the moment or which won't ever be described semantically. This property can be used to store that information as free text.
Ideally this property should have the multilingual text datatype but that doesn't exist yet so the property name is "Comment (string)" leaving the name "Comment" available for use when that datatype is ready. Filceolaire (talk) 18:53, 11 July 2013 (UTC)
Comment This is really very unspecific and I can't see a use for this property (beside being a temporary workaround in order to save urls, which I wouldn't support). Could you name an example (item + value) to explain where you would use this property, and why it wouldn't be possible or a good idea to have a new, own property for this specific type of data in your example.--Kompakt (talk) 09:36, 16 July 2013 (UTC)
Oppose If there is no way to classifiy some informations this is not the goal of wikidata to store it for 2 reasons: 1) wikidata is a structured database 2) data are imported in the client meaning that the client has to know the content of the data in order to call it. If you have data which can't be described nobody will call it because nobody knows its existence and nobody will call the data just to see what kind of data we have in that property. This is not the goal to have everything even the small details in wikidata. Snipre (talk) 11:16, 16 July 2013 (UTC)
Support I think that this is a very useful addition -- not necessarily for term properties, but for adding comments in qualifiers of statements!! A usecase I currently have are pharmaceutical drug-drug interactions. We recently got the property "drug action altered by" approved. If we have a relationship of <Drug A> <drug action altered by> <Drug B>, we would like to add as a a qualifier a short description about the exact nature of how they interact. I think that this need will arise for several other properties as well, and having a generic property to add short comments seems like the ideal solution.--Matthiassamwald (talk) 10:14, 6 August 2013 (UTC)
Comment There probably could be a way to describe that interaction using an item that corresponds to the nature of the interaction. Do you have an example ? TomT0m (talk) 15:21, 6 August 2013 (UTC)
oppose datatype - This is something that needs to be translatable. If the datatype is changed one can merge it with the proposal below. --Tobias1984 (talk) 15:14, 6 August 2013 (UTC)
Support The examples are really all items about the various claims. How about calling the qualifier "item about"? Emw (talk) 21:41, 5 May 2013 (UTC)
That seems more like it's saying the claim is an item about the item, instead of the other way around (the item is an item about the claim), no? --Yair rand (talk) 21:58, 5 May 2013 (UTC)
Good point. My concern is that "related" is very broad: the article "presidency" and "election" are related to "Presidency of Barack Obama", but they aren't directly about it. Perhaps "subject of" would be better? The claim is the subject of the item, i.e. the value of the qualifier. Emw (talk) 22:39, 5 May 2013 (UTC)
Oppose Subjective relation: without a clear relationship everybody can add this property and link to topic he wants. Property have to characterize item, relation between topics will be performed by search algorithms not by data management. Snipre (talk) 23:09, 8 May 2013 (UTC)
How could this be "subjective"? It seems pretty objective to me. Could you give an example of where it could be ambiguous whether this qualifier should be used or not? --Yair rand (talk) 23:27, 8 May 2013 (UTC)
If I take the example I can link Death of Osama bin Laden with Barack Obama or with Navy Seal: this is a relation between these different items but how can we fix a limit ? Snipre (talk) 23:55, 8 May 2013 (UTC)*:: If I take the example I can link Death of Osama bin Laden with Barack Obama or with Navy Seal: this is a relation between these different items but how can we fix a limit ? I can even provide sources for that. the problem is to distinguish between item characterization with properties and connection between items. The first is data management and the second is data use. What you are proposing is categorization with the help of property. Don't do in wikidata what wikipedia is doing connection based on text or links. Snipre (talk) 23:55, 8 May 2013 (UTC)
This proposal is in the "Qualifiers" section. The proposed property would not be used directly on items at all. Please see the examples given in the box above. --Yair rand (talk) 00:00, 9 May 2013 (UTC)
If you ensure that this property will be used only as qualifier we can discuss but you can't. I can already bet that in 3 months this property will be used in a different manner and nobody will be able to check its correct use. Again what you are doing is connection between wikipedia articles in wikidata. Snipre (talk) 00:13, 9 May 2013 (UTC)
First of all, I really disagree with the idea that properties shouldn't be created when some editors might use it incorrectly. Second, I've implemented Emw's proposal above to change the name to "subject of". Does that remedy your concerns? --Yair rand (talk) 00:23, 9 May 2013 (UTC)
Oppose I also think that the use of this property will be too subjective and adds very little content. Barack Obama, President of the United States and Presidency of Barack Obama would already be connected through other properties anyways (maybe you have to jump over one node in the graph, so what?). I think that because of the subjectiveness and the redundancy with existing information, this property would add confusion and would not be put to good use. --Matthiassamwald (talk) 10:23, 6 August 2013 (UTC)
I don't think you understand what the proposal is. The property would be used exclusively as a qualifier, to link to an item completely dedicated to the subject of the statement. I don't see how that could be subjective at all. --Yair rand (talk) 18:29, 6 August 2013 (UTC)
Support. Very useful. What about a really clumsy but unambiguous name like "topic of the following item". We dont want it to be used for "James Cameron is a subject of her Majesty the Queen", and can use aliases as shortcuts. --Zolo (talk) 06:31, 9 May 2013 (UTC). Or "dedicated item" ? --Zolo (talk) 10:32, 9 May 2013 (UTC)
Oppose are you suggest that Obama is the subject of the Death of bin Laden, or that bin Laden is the subject of Obama? Neither are correct. They are topics related in a large number of different ways, of which being the subject of is not one. Nor does it match Zolo's suggestion of topic of the following item. bin Laden or the death of bib Laden is not the topic of Obama, or vice-versa. If you want some sort of relator here, you need to think of all the actually appropriate relators. This is being used in the meaning of "might have an appropriate wikilink to" , which is a very broad concept indeed. Possibly the relationship you are thinking of is "sub-topic of" in the sense that Death of bin Laden is a subtopic of Bin Laden. that might be useful, because articles in WP are in fact organized in this fashion. DGG (talk) 23:13, 17 May 2013 (UTC)
Comment – There is no suggestion in this proposal about a connection between Obama and bin Laden. Example 1 in the proposal is about Obama's Presidency, example 2 is about bin Laden's death, and example 3 is about the US-Canada border. These examples are independent of each other. Byrial (talk) 00:19, 18 May 2013 (UTC)
Comment Surely most subject relationships can be found by following the connections of existing properties? Danrok (talk) 00:00, 24 May 2013 (UTC)
Comment It seems there is much confusion about what this property is all about. I'll try to explain it in detail. There is a major problem this property is able to solve: Statements themselves can be items. To use one of the examples above: death of Osama bin Laden (Q19085) is an item describing an event that is also described by the statement | Osama bin Laden (Q1317) died: May 2, 2011 |. The proposed property shows this relation by adding the describing item as a qualifier to the statement it describes. —★PοωερZtalk11:39, 24 May 2013 (UTC)
Comment Unless there are new objections, I'll create this one as "dedicated item", as I think it is the clearest label. --Zolo (talk) 13:12, 24 May 2013 (UTC)
Comment, an annoying point is that the property does not apply to an "item - property - value" but just to an "item - property". For instance "death of Osama bin Laden: dedicated Death of Osama bin Laden" applies to Osama bin Laden (Q1317) - cause of death (P509) but to no particular value of P509. So where should we put it when the property has several values ? --Zolo (talk) 13:25, 24 May 2013 (UTC)
Sure, better to have one statement for one event. I'd say time of death should be the basic property, but this is not the place to discuss that in detail. —★PοωερZtalk02:40, 25 May 2013 (UTC)
I would prefer 'Dedicated article' instead of 'Dedicated item'. in most cases a sub-page is about the same item as the main page but it is a separate article. Filceolaire (talk) 21:02, 6 June 2013 (UTC)
Done After being asked to review this decision and looking in the opposes more, while they do exist they are purely misunderstanding of the proposal therefore carry little or no weight. John F. Lewis (talk) 11:03, 14 August 2013 (UTC)
subsequence of (en) / série incluse dans (fr)
Not done
Description
The sequence is a subsequence of a larger sequence represented by the item object
instances of sequences of items of the same type than the object sequence type
Allowed values
sequences of items of the same type than the subject sequence type
Example
a TV series season is a subsequence of the whole TV series. Suggested qualifiers : preceeded by and followed by to qualify which subsequence follows in the sequence)
Comment (from proposer) Maybe the part-of could do the job but I think it is more a kind of unordered composition, whether sequences ordering is important. TomT0m (talk) 17:14, 21 July 2013 (UTC)
Like I said, composition, which part of seems supposed to represent, is related to unordered stuff, whereas in a sequence the ordering of subsequence is important. This justifies another property imho, or we would have to infer that from other properties. For example maybe a compilation from the best episode from a TV serial is possible. It is a part of the whole also, but it might not respect the ordering. TomT0m (talk) 11:59, 5 August 2013 (UTC)
As a matter of fact I used follows (P155) and followed by (P156) of course, but directly on the item, not in the part-of qualifier (it seems natural to say that a TV series season is preceded by the previous directly). But the qualifier solution allows to be subsequence of several series ... I don't know what is best. If a serie is a sequence of episodes, It seems that a part of a serie is an episode, not a season which is a subsequence. On the other hand an episode is also followed by and preceded by another, and part of the serie, so using part of for both leaves an ambiguity which can be resolved by checking the types of the items, but it's not a generic solution. I still think it's better to have a subsequence property then, to distinguish between atomic elements (episodes) and other subsequences (seasons, which are themselves sequences of episodes).TomT0m (talk) 13:21, 5 August 2013 (UTC)
I would say an episode is part of a season and a season is part of a series. Dr Who used to have some stories in a season which were told over multiple episodes. In that case an episode would be part of a story which is part of a season which is part of a series for a particular regeneration of the Doctor which is part of the entire series. Even when we have sequences nested five deep, as this case, I think we can manage it with part of and qualifiers.
We can use 'preceded by' and succeeded by' directly on items for each episode, story, season and regeneration to link items in each sequence to adjacent items in that sequence, for the benefit of querybots which don't understand qualifiers, and we can use 'part of' to link to the item for the sequence of which the current item is part. We can even use 'consists of' to list all the elements in the current sequence/item. Filceolaire (talk) 15:13, 5 August 2013 (UTC)
It does not meet the definitions, see the articles on en: as an example. A serie is a sequence of episode. A season is a sequence of episode. An episode is not a sequence of episode. A story might be told in several episode, but it's not the story which is a sequence of episode itself. The problem with tour solution is the lack of regularity, for example some series does not have several seasons, it's still a sequence of episode : a bot would still find the same properties and would not have to treat it as a corner case. I think episode is a fundamental unit in this model (as well as the elements of a sequences are from different kind than the sequences themselves). The subsequence property solution has the advantage to make explicit this separation between the kind of the elements of the lists and the kind of subsequences. Of course this is the basic model, we also can add other facts to separate narrative units, but it's important to keep this regularity if we want the datas to be easily processable for a bot.[serie 1][serie 2]TomT0m (talk) 15:28, 5 August 2013 (UTC)
Refs
↑Serials are series of television programs and radio programs that rely on a continuing plot that unfolds in a sequential episode-by-episode fashion. Serials typically follow main story arcs that span entire television seasons or even the full run of the series, which distinguishes them from traditional episodic television that relies on more stand-alone episodes. Worldwide, the soap opera is the most prominent form of serial dramatic programming.https://en.wikipedia.org/wiki/Serial_%28radio_and_television%29
My proposal is for a property that allows objects which can be spatially located to have distances from other spatially
locatable objects added to them.
My inital thought with this was railroad mileages which are typically defined as being that X is so many miles from a defined Zero mileage at Y.
This property would need a qualifer - measurement datum.
Some proposals were not really well discussed in the early days of Wikidata :). But maybe you could change the datatype to "item" and change the title to "distance along". Example: We have the Arlberg railway (Q620564) which will get a length/distance property to say 136 km. A town along the railway is a certain distance from the railway measurement datum (see: de:Kilometrierung). So the statement could say for the town Sankt Anton am Arlberg (Q659996):
I've called this Geo_Datum, rather than measurement datum, because there may be other specifc "measurement datums' in other fields. Sfan00 IMG (talk) 18:07, 3 August 2013 (UTC)
Support - I think this would also be useful for altitude measurements, where almost every country has their own datum. Example from the list de:Höhe_über_dem_Meeresspiegel:
This property will be part of an on-going work to import parts of SSR into Wikidata. The property seems to be of general value and is because of this not prefixed with any project specific letters. Similar properties are maintained by (P126). Jeblad (talk) 14:36, 6 July 2013 (UTC)
Support I think it would be usefull as a qualifier for the canadian heritage properties, since they have many autorities who can protect with different statuses. I actually use owned by (P127), but a new property will be better, since they are not really maintained or owned by the governement in question. (ex: Charlotte County Court House (Q5085897)) --Fralambert (talk) 14:00, 5 August 2013 (UTC)
should link only from non-category item to category-item
Source
iverse property to "main article" templates and to Property:P301
Robot and gadget jobs
generate as complementary inverse property to Property:P301 which can be generated from "main article" template in Wikipedias and Commons categories. Items which are connected by Property:P360 should link to identic category.
Generally, Q subjects should represent items, not articles. Thus, article links belong to the item equally inehrently as category links. However, Wikidata structure was wrongly based and therefore we have mostly two Q subject for identic item, one for articles and second one for categories. This fault complicates integration of Wikimedia Commons because Commons categories are related not specifically to Wikipedia articles nor specifically to Wikipedia categories but to items, which are represented by both, articles and categories.
Most of properties are inherently complementary: some of them are inverse, some of them are symmetric. However, the Wikidata logic was is hardly deficiently thought out and thats why complementary properties doesn't works automatically as complementary yet but need to be rendered from ones to the complementary properties. It this case, link from the item itself to the additional category "item" should be primary toward the existing opposite property Property:P301.
Comment If this is organizing the structure of Wikipedia shouldn't the property be called "Wikipedia Category". It is not Prague that has a category, but Wikipedia has a category for Prague. --Tobias1984 (talk) 18:40, 6 August 2013 (UTC)
You can say also similarly: "It is not Prague that has an article, but Wikipedia has article for Prague". However, the decision that Wikidata "items" should be a tool to organizing the structure of other Wikimedia project (Wikipedias first of all) is not something now. Wikipedia articles appertain to their items just so as Wikipedia categories do. Wikidata are ill-based in this point as far as they don't allow to treat category-links equally as article links in relation to their common items. However, if the Wikidata Team ousted category links to such subsidiary or parallel duplicate "items", there is no reason to limit them to Wikipedia projects. Also some other Wikimedia projects have item categories. --ŠJů (talk) 21:32, 8 August 2013 (UTC)
You repeat my arguments but do not answer them. Yes, most of properties are inherently complempentary and it is a fatal defect of Wikidata that they don't really work as complementary. That's why we need to have inverse properties for most of properties and to render their data mutualy for now. However, if we should have only one property instead both complementary properties, we should prefer to link from the primary item to the secondary one, i. e. from the main item to the quasi-item in this case. --ŠJů (talk) 21:32, 8 August 2013 (UTC)
Oppose Categories are essentially queries on a set of pre-defined properties, and so should be obsolesced by Wikidata. The archived discussion Proposal for phase 4: unify and centralize categories contains detailed comments from several other contributors on this, but the gist is "get rid of categories". We should not be building infrastructure like specific 'category' properties to support a redundant, legacy categorization system on Wikidata. Emw (talk) 01:35, 7 August 2013 (UTC)
You are right, categories are esentially queries on a set of some elements and if Wikidata Team will comprehend all aspects and functions of wiki categorization, it would be very welcomed and interesting to try to transform them into WikiData. Unfortunately, Wikidata didn't implemented nor even modularity principle yet and drowns in countless useless duplicities when attributing. I'm afraid that such trials will bring more harm than benefits if they will be so rash and ill-planned as the first phases of WD.
However, simple (non-compound) item categories have a direct relation to their items, just as articles have. Relation between categories is esentially a relation between their items. If Wikidata usurped the organization of article interwikis, it should adopt responsibility for all interwikis and also for the relation between items, articles (or gallery pages) and categories, and rather improve and integrate than to peck out, sunder, smash and shatter the previous system. --ŠJů (talk) 21:32, 8 August 2013 (UTC)
Info This is a distinct designation issued publicly by the US Dept. of Defense. These designations are widely used and are the official designation/name for any aircraft in service with the US Armed Forces since 1962. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
Info Specifications issued by the UK Air Ministry (Air Board before 1918, RAF 1918 to 1920). These exist for most all aircraft operated by the UK military up to the 1970s. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
Support but propose name change to 'established': Datatype should be 'date', which should allow more detail than year alone. This property would apply widely to buildings, organizations, etc. A related 'disestablished' property is equally valid. Joshbaumgartner (talk)
There is no difference between time and date data types. They are the same and now you can use it. For buildings, organizations, etc the property is already created دوستدار ایران بزرگ (talk) 16:13, 30 May 2013 (UTC)
As TCN7JM(wikidata sysop) says here "inception (P571) is usable for items about cities, but I feel like "date established" would be better wording, but I suppose if this property works, the later would become an alias for inception (P571)." Maybe its's better to rewrite inception (P571) as foundation/establishment date. By the way don't forget that many Wikipedia categories are set by year not a more precise date --دوستدار ایران بزرگ (talk) 18:39, 30 May 2013 (UTC)
Time datatype accepts year as well as full date. For the renaming of the inception (P571) I let you start the discussion on the talk page of that property. If you have no other comment I will delete your proposal. Snipre (talk) 19:27, 10 June 2013 (UTC)
Oppose Change to 'key date for building' and link to the 'construction' item with start date and end date qualifiers. See my comment on 'key date for building:groundbreaking' above. Filceolaire (talk) 21:18, 11 June 2013 (UTC)
Oppose unless all the properties in this section are combined into one property 'key date for building" with datatype 'item' and qualifier 'date' or 'start date' and 'end date'.
It's seem a little complicated to manage those dates the way you are proposing it. I think that having properties seems more intuitive. Greenski (talk) 16:39, 19 June 2013 (UTC)
After thinking, I think I understand, but then it can't apply to opening and closing date, as it can't be an interval. Greenski (talk) 16:42, 19 June 2013 (UTC)
Datatype: date, as precisely as possible, possibly down to the day and month
Links:
Infobox parameter example:
Comments: date for the closing of the structure to the public. ex. w:en:Saint-Martin (Paris Métro), closing date September 2, 1939.
Support If we have opening date, we do need a closing date. It may for example be used for old railway stations, closed, but not demolished. Greenski (talk) 16:36, 19 June 2013 (UTC)
As explained at demolition is the planned destruction (i.e. knocking down) of a building, as opposed to destruction by natural or man-made disaster... Shawn in Montreal (talk) 20:48, 1 March 2013 (UTC)
Question: since en:Template:Infobox building does have both the demolished and destroyed fields, will there be some way later to qualify how a building has been lost? I don't see users at the English Wikipedia opting to use a Wikidata generated table in phase two if it means a loss of information from what they currently have, and I thought this was the point. Shawn in Montreal (talk) 22:50, 10 March 2013 (UTC)
Sorry, I just saw this comment: well, aside from the minor grammar point (it's "destroyed by") I'd have no objection if you Wikidata whizzes think such a property is possible. So you'd have a property for when it was destroyed (a date) and how it happened (an item)? If so, okay. Shawn in Montreal (talk) 20:07, 29 March 2013 (UTC)
To be clear, if this property is approved, this would not apply only to stations, but to all things that have opening dates. This is a good thing though. Sven ManguardWha?05:40, 18 February 2013 (UTC)
Support. There should also be "Closing date", and each of them could be multiple, with qualifiers for different purposes. I'm thinking in particular of stations that closed to passenger traffic before they closed completely (eg en:Idle (GNR) railway station) but I'm sure there are other cases. --ColinFine (talk) 09:46, 22 February 2013 (UTC)
That would be waaay too general. Using "date" as the property name would be like using "family members" as properties and using "father", "mother", "brother", etc, as qualifiers. --Wylve (talk) 15:46, 26 May 2013 (UTC)
It's not generalized when a qualifier is used. Yes, it would be like having a "relatives" property with a relationship qualifier, which works just fine in practice. How many date properties will there be if we create a specific one for every event? 10, or 1000 or 10,000? Danrok (talk) 15:56, 26 May 2013 (UTC)
Comment I support having an "opening date" property but think a generic "opening date" property would be better. (see key dates for building) Aude (talk) 22:18, 1 August 2013 (UTC)
Start of operation / Inbetriebnahme / mise en service
Not done
Description
the date when the facility / railway line / machine was put into operation
Comment That would be another property called "end of operation". However, either way is fine for me. I'm just wondering how long it will take to create this property. I asked for it end of April. Now it's mid July… --Frank Schulenburg (talk) 17:11, 14 July 2013 (UTC)
Move --Tobias1984 (talk) 09:01, 29 July 2013 (UTC)
Support --Kolja21 (talk) 18:52, 7 August 2013 (UTC)
Question, if there are several different sorts of ids for people / places / publishers, wouldn't it make more sense to use separate properties. It seems simpler both to encode and to decode. --Zolo (talk) 19:32, 6 May 2013 (UTC)
Comment I tried to create this property, but the webpage seems to be broken. I can't even find Gorch Fock and the link form de-wiki doesn't work either. --Tobias1984 (talk) 08:34, 27 July 2013 (UTC)
Done --Tobias1984 (talk) 06:28, 2 August 2013 (UTC)
Strong support
Oppose - there are simple to much objects in the world that everything which can be photographed has its own property. --Nightwish62 (talk) 21:06, 1 August 2013 (UTC)
Not done --Nightwish62 (talk) 08:02, 2 August 2013 (UTC)
Not done
Answer If the item has a standard license (from all licenses' items on Wikidata), then the property is not required, since it can be obtained easily; else, if the item has a custom license by its own, then it should have this property. --Ricordisamoa 10:30, 23 March 2013 (UTC)
Done --Fralambert (talk) 12:56, 5 August 2013 (UTC)
Wait Can we create an unique property for the different national classifications instead of different properties for each natioanl code ? See above for Russia Snipre (talk) 12:50, 29 July 2013 (UTC)
Comment - does concern only administrative geographic objects, does not exist for rivers or mountaines. Possible to fetch also from w:de:Vorlage:Infobox Ort in den Vereinigten Staaten, parameter name: Fips --Matthiasb (talk) 13:06, 7 March 2013 (UTC)
Move --Tobias1984 (talk) 09:01, 29 July 2013 (UTC)
Support --Kolja21 (talk) 18:52, 7 August 2013 (UTC)
Weak oppose in favor of a more general "related date" property used as qualifier for "emigrated to". --Ricordisamoa 23:29, 2 August 2013 (UTC)
Oppose This seems to be the inverse of category's main topic (P301). I don't think we need both. Filceolaire (talk) 22:41, 6 August 2013 (UTC)
Info This is a distinct designation issued publicly by the US Dept. of Defense. These designations are widely used and are the official designation/name for any aircraft in service with the US Armed Forces since 1962. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
