Oppose me suena a spam. --LadyInGrey (talk) 23:50, 5 February 2013 (UTC)
Support when IRI datatype is available. But we need to choose which websites are acceptable (e.g. only personal website, not social media pages).--Stryn (talk) 07:50, 6 February 2013 (UTC)
Support IRI for any entity's official web site. There is no spam problem as by definition if the subject has an Item on Wikidata, it is "notable".Espeso (talk) 18:43, 7 February 2013 (UTC)
OK, I think there's consensus for doing this; I am putting this in a hidden block so it doesn't distract from others that are on-going conversations, whilst we wait for the datatype to be created. James F. (talk) 19:57, 7 February 2013 (UTC)
Support Preferably sooner rather than later. However I believe the IRI datatype isn't deployed yet. Is it worth setting up the property with a string datatype in the meantime? --Avenue (talk) 01:19, 22 March 2013 (UTC)
Support, too. I think there's consensus for doing this, so I'll move this section to the pending properties. --Ricordisamoa 08:41, 24 March 2013 (UTC)
Support --DangSunM (talk) 22:30, 10 September 2013 (UTC)
Sorry. What do you need ? An property with a numeric datatype ? Or a property representing a numeric concept with a string as datatype ? If I take your example with swiss franc you want something like "currency division" to give the nominal value of each coin/note ( 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, 100, 200, 1000)? Snipre (talk) 21:03, 22 March 2013 (UTC)
In fact I think a good thing would be a generic property (e.g. "DrTrigonBot Value" or even more generic "Bot Value") for the bot in cases when it has data to write for which no property was created yet - as it is the situation right now for a property "Currency Exchange Rate" (or similar) that is needed for swiss franc. This would allow the bot to already be tested or used without having the need to create always the suitable/correct property before being able to check if the bot works at all (in that specific situation), e.g. That would be a really good and useful/helpful thing! Thanks a lot for considering this and Greetings --DrTrigon (talk) 21:41, 22 March 2013 (UTC)
Just for a test you can see if there is a property in request for deletion using string as datatype or a property which not used in a lot of item or finally try on the demo version of wikidata. Snipre (talk) 22:05, 22 March 2013 (UTC)
Thats clear, currently I am using something else. Also the demo was already used to adopt the bot code. What I need is something permanent. In future and daily (usual) operation there will always be a case where you have to test, since the bot is freely configurable from here - by any user. --DrTrigon (talk) 22:36, 22 March 2013 (UTC)
I think testing bots should not be done on the productive Wikidata, except in the sandbox.--Faux (talk) 17:04, 23 March 2013 (UTC)
It is not testing bots, but testing setups - as on wikipedia itself you will always have situations were you have to change something, modify setup of data, configuration and so on... at least that is what holds for me. Then I have to disagree because testing of bots is needed, e.g. in order to fullfill the bot flag request a given number (e.g. 250) of test edits have to be done. And there will in future clearly be other situations - as soon wikidata will be used frequently... Greetings --DrTrigon (talk) 20:55, 23 March 2013 (UTC)
I mean ... it does not need to be something bot specific, what about general maintenance (for human users)? I would even more support such a property, that can be used if it is e.g. not clear yet what property to use, one has to be renamed, other name conflicts or anything else... --DrTrigon (talk) 20:59, 23 March 2013 (UTC)
Why not simply a sandbox property per datatype ? I do not see what harm can be done with that, as long as it is clear that it is a sandbox. --Zolo (talk) 21:29, 23 March 2013 (UTC)
Sounds good! (+1) Thanks for the idea! Greetings --DrTrigon (talk) 22:41, 23 March 2013 (UTC)
Do you plan using that sandbox property only on sandbox/test items, or also on production items? --Faux (talk) 12:12, 24 March 2013 (UTC)
I do not see anything wrong in using it other items. It will not look very good, and if we can avoid using it too massively, that is better, but raw Wikidata items do not look very good anyhow. The important thing is that it does not unintendedly get transcluded to Wikipedias and other clients. And as long as they do not query sandbox statements, I see no reason for that to happen. --Zolo (talk) 12:22, 24 March 2013 (UTC)
So... are we done here, or for what are we waiting? ;) If you agree I would step forwards and create following 3 properties:
Label: Sandbox-CommonsMediaFile / Description: Sandbox property for value of type "Commons Media File" / Data type: Commons Media File
Label: Sandbox-Item / Description: Sandbox property for value of type "Item" / Data type: Item
Label: Sandbox-String / Description: Sandbox property for value of type "String" / Data type: String
any comments or thoughts on this? Thanks and Greetings --DrTrigon (talk) 10:52, 29 March 2013 (UTC)
mainly articles from newpapers, journals, magazines published within mainland China. Some magazines and newspapers can also be found in CNKI like People's Daily(Q54340)Qiushi(Q3429265)
Allowed values
I was thinking about the identification for items of CNKI. There is no formal identification method for CNKI.
It can be a replacement of DOI for items in CNKI. Although CNKI has been appointed as a registration agency in China, I didn't find the DOI for items in CNKI. [2] --凡其Fanchy 16:34, 4 May 2013 (UTC)
Waiting for the IRI type is better. CNKI is quite a mess, although it is the most comprehensive academic full-text database in China--凡其Fanchy 10:58, 13 May 2013 (UTC)
Obviously it is designed for the English version CNKI. I guess only articles with English titles and abstracts will be shown on that English version--凡其Fanchy 19:35, 1 June 2013 (UTC)
There is [3] corresponding to [4], and the www.cnki.com.cn site doesn't seem English-only. Liangent (talk) 16:01, 3 June 2013 (UTC)
Here is also a same paper [5] . That is why I say it is a mess. A paper is shown on three different place.--凡其Fanchy 16:36, 3 June 2013 (UTC)
A fourth place [6]--凡其Fanchy 16:43, 3 June 2013 (UTC)
(English) The website www.espnscrum.com provides stats for any international rugby union player. It is provided in the form http://www.espnscrum.com/statsguru/rugby/player/12757.html (in this example, Jonny Wilkinson) where the number in bold is the parametre used in the template Scrum and in its correspondants in Italian and French language. The property should indicate for each international rugby union player this number. (Français) paramètre qui correspond au code d'identification du joueur du rugby à XV affiché dans l'adresse web (example: http://www.espnscrum.com/statsguru/rugby/player/13317.html pour Sébastien Chabal) (Italiano) la proprietà dovrebbe indicare il numero della pagina html corrispondente al rugbista a 15 le cui statistiche sono indicate nel sito www.espnscrum.com (per esempio http://www.espnscrum.com/statsguru/rugby/player/10657.html per Diego Domínguez. Tale proprietà va indicata come campo del template Scrum, che ha corrispondenti anche sui capitoli in francese e in inglese di Wikipedia. Blackcat (talk) 12:01, 7 July 2013 (UTC)
Support should use time qualifiers. --Tobias1984 (talk) 21:44, 6 August 2013 (UTC)
Question Should I copy it to the organisation and event section? Zil (talk) 23:48, 7 August 2013 (UTC)
Comment support the idea, this needed. But is there another way to go about this? Many things are financed by other entities. Perhaps, one property for all financial backers, and a qualifier to indicate that they are a sponsor, provided a grant, or whatever. The applies to part (P518) could be the qualifier. Danrok (talk) 22:23, 27 August 2013 (UTC)
Support but it needs to be renamed 'Sponsored by' if it is to be used as your example.
Comment I think patronage should be a separate property. Danrok (talk) 12:37, 31 August 2013 (UTC)
Already done, but I still will Oppose. Sponsors are trivial information, and some people (eg. sportspeople) have so many sponsors, and it's not even possible to find reliable sources for all of them. And some can be sponsor just few days, some longer. How do we get this all by sourced? --Stryn (talk) 07:19, 12 September 2013 (UTC)
The goal of this property is to provide for each wiki the id number of each rugby union player who plays or has played in the English Premiership. Blackcat (talk) 11:46, 17 August 2013 (UTC)
Support similar idea to other properties created. Danrok (talk) 19:27, 29 August 2013 (UTC)
Comment thanks Danrock, you mean that you have already proposed similar properties for identifying players by tournament? -- Blackcat (talk) 19:23, 30 August 2013 (UTC)
Comment No, just saying that we have other properties for a variety of subjects which work along the same lines as this. That's one reason why I am supporting it. Danrok (talk) 12:59, 31 August 2013 (UTC)
Comment the label may need to be premiershiprugby.com ID if this ID is that web site's own reference, and not an official ID for the player. Danrok (talk) 13:04, 31 August 2013 (UTC)
Comment No problem for me to name it that way. Anyways that's the English Premiership's official website, and the player ID was the same even when it was known as guinnesspremiership.com. As a matter of fact the official Pro12's website shares the same IDs with the English Premiership's, see i.e. Brent Cockbain both in English Premiership and in the Pro12. I may suppose you agree also on this proposal? -- Blackcat (talk) 13:42, 31 August 2013 (UTC)
Info This is a distinct designation issued publicly by the US Navy. These designations were widely used and were the official designation/name for any aircraft in service with the US Navy from 1922 to 1962. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
Info This is a distinct designation issued publicly by the US Army and Air Force. These designations were widely used and were the official designation/name for any aircraft in service with the US Army Air Service, Army Air Forces, and United States Air Force from 1924 to 1962. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
Info Japan has usually employed its own system of aircraft designations to identify aircraft, both of domestic and foreign origin. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
Info Development specifications for several British aircraft projects, officially issued by the Air Ministry. Joshbaumgartner (talk) 12:49, 12 May 2013 (UTC)
value for librarian (Q182436) is : K1601 (v3 code). You can add the full v3 description "Gestion de l'information et de la documentation". You can also add the v3 job titles. You can also add a couple of matching v2 codes along with their descriptions and their several associated job titles. V3 is simplified when compared to V2, but some articles on WP:FR use V2, and many French website still use V2.
Format and edit filter validation
check that it's 1 letter followed by a 4 digit number, and against this list.
Special festivals are observed during New Year holidays. During these days people usually consume special meals. In countries like Iran and China, these are traditionally cooked from old times during each New Year called "nowruz" and "Nián Jié", respectively. These are often specific sweets or foods symbolizing happiness. دوستدار ایران بزرگ (talk) 10:19, 19 April 2013 (UTC)
Comment the source provided doesn't appear to be a source for this information. Danrok (talk) 23:58, 26 June 2013 (UTC)
Support. I've rewritten the English name to better match the description. This property can also be used to link places to foods associated with them. Filceolaire (talk) 19:50, 15 August 2013 (UTC)
I changed the Persian name Doostdar (talk) 17:00, 17 August 2013 (UTC)
Comment Still no information on how this would be reliably sourced. Danrok (talk) 02:31, 27 August 2013 (UTC)
PORT is a very popular (multilanguage) cultural website in the Carpathian region. It is widely used on huwiki. Matthew Beta (talk) 16:17, 3 May 2013 (UTC)
phase point to describe critical point and triple point, use of qualifier to describe the pressure, the temperature and the matter phase characterizing the point
Does anybody know how this would influence queries? --Tobias1984 (talk) 21:06, 12 June 2013 (UTC)
Right, for each solid form we need an item. And I dont see an issue with taht structure for query. Do you have an example ? Snipre (talk) 11:41, 15 June 2013 (UTC)
I like it. It could also be extended to implied claims, e.g. assigning sex:male to an item is it is father or brother of another item, if such actions were to be undertaken by a bot. --Magnus Manske (talk) 12:55, 2 August 2013 (UTC)
Oppose Good idea but this will mix source and value. And like wikipedia wikidata is grounded on external references. This kind of analysis can be used only for data checking and search of unconsistent values. Snipre (talk) 13:26, 2 August 2013 (UTC)
I'm not entirely sure I understand what you mean with "mix source and value". Also note, that we are already using heuristics to assign certain properties to items, this would merely make explicit the instances in we do (and have done) so. —Ruud 14:11, 2 August 2013 (UTC)
You base your source on value and not on external sources. Your approach is definitevely out of th scope of the wikipedia spirit: you assume that it is possible to find the sex of a person from its name. First it is not always the case: they are some persons which have a name of the opposite gender and some names in some language can be used by both women and men. This approach is a "original research" based on an assumption that the sex is linked to the sex of the person. This is often the case but not always. Here we reach the limit of heuristics to "create" data and this is not the goal of wikidata which is a repository of data and not a place where data is generated. Snipre (talk) 15:26, 2 August 2013 (UTC)
I think you are misunderstanding the situation. "I" do not base my source on a value and "I" do not assume that it is possible to find the sex of a person from its name, but there are currently bots running which do (so). This is not the appropriate venue to discuss whether what they are doing is appropriate or not. I simply note that this is already happening and propose a sourcing property to make what is happening explicit. —Ruud 21:08, 2 August 2013 (UTC)
Just noticing that SamoaBot's Task 33 has been regularly approved after a regular discussion; we selected suitable names with caution. The first run is now almost completed, but a new one is already planned. IMHO a "based on heuristic" property could be useful, but we should first have a large discussion on source properties; on the other hand, "imported from Wikimedia project (P143)personal name (Q1071027)" doesn't mean that personal name (Q1071027) is a clear and safe way at all to determine a person's gender. --Ricordisamoa 22:17, 2 August 2013 (UTC)
There is a RfC on the sourcing requirement of bots and if there is a problem that's because bot owners are sourcing with unofficial properties. The property was a temporary property and an offical guideline was defined for the sourcing since that time. From now there are only two correct ways to sources: provide source according to help:sources or don't add any source. That is the clearest solution. Snipre (talk) 12:48, 15 August 2013 (UTC)
Support. --Yair rand (talk) 13:44, 25 August 2013 (UTC)
Support, will be a clear indication that the information should be double checked, but good heuristics can make really few mistakes so we take the better of both worlds. TomT0m (talk) 18:47, 25 August 2013 (UTC)
Motivation: Needed to import Cite journal template.--Micru (talk) 20:37, 14 August 2013 (UTC)
Oppose Use data of the original publication instead of an intermediary reference. Snipre (talk) 23:15, 14 August 2013 (UTC)
Sure, but this property can be used for verification purposes, to check that the original publication details are accurate.--Micru (talk) 00:10, 15 August 2013 (UTC)
And what happens if the pmc code is wrong ? Which is right ? Then we have the DOI which more general than the pmc. We have to be careful with crosschecking parameters because once you have 3 or more prameters which can defined 3 or more different objects that is a mess to see what is correct especially when you don't have the access to the documents. Snipre (talk) 12:42, 15 August 2013 (UTC)
Only those who do nothing make no mistakes. Mistakes are made to be corrected. TomT0m (talk) 18:51, 25 August 2013 (UTC)
w:Mathematical Reviews is a journal and online database published by the American Mathematical Society (AMS) that contains brief synopses (and occasionally evaluations) of many articles in mathematics, statistics and theoretical computer science.
A w:Request for Comments (RFC) is a publication of the Internet Engineering Task Force (IETF) and the Internet Society, the principal technical development and standards-setting bodies for the Internet.
Support is what I meant :) --Tobias1984 (talk) 09:47, 15 August 2013 (UTC)
If I comment on this property, I suppose I should also write more than "LOL". Thus, Support. To avoid ambiguity, IETF might need to be in the label. -- Docu at 09:55, 15 August 2013 (UTC)
The w:Social Science Research Network (SSRN) is a website devoted to the rapid dissemination of scholarly research in the social sciences and humanities.
The service reviews more than 2,300 journals and serials worldwide, as well as books and conference proceedings. The Zentralblatt database also incorporates the 200,000 entries of the earlier similar publication Jahrbuch über die Fortschritte der Mathematik from 1868 to 1942, added in 2003.
Motivation: Needed to import Cite journal template. Before they were listed as sepparate entries, but since 2003 Zentralblatt incorporates the JFM codes, so it should be possible to merge them.--Micru (talk) 20:37, 14 August 2013 (UTC)
Comment key piece of information, particularly for modern aircraft, for understanding capabilities of an aircraft. By being an 'item' property, it will limit statements to notable pieces of equipment. Joshbaumgartner (talk) 02:58, 30 May 2013 (UTC)
Comment perhaps there is a more generic way to do this? Something like installed systems? So, the same property could be used for things like ships to indicate the radar installed, etc.? Danrok (talk) 21:12, 4 September 2013 (UTC)
That would be even better. I would support "carries instruments" which could also be used for scientific instruments of satellites. --Tobias1984 (talk) 09:37, 6 September 2013 (UTC)
Comment - What would be the primary source of this property? --Tobias1984 (talk) 13:53, 28 May 2013 (UTC)
Comment hull number of USS Iowa (Q562161) is 61 not BB-61. BB is the hull classification symbol. Danrok (talk) 18:29, 28 May 2013 (UTC)
Support as a property for any and all types of codes/numbers combined in to a single string, as is usually painted on the hull. e.g. hull classification + hull number. Danrok (talk) 13:59, 31 August 2013 (UTC)
CPU aka "Central processing unit" (en) / CPU aka "Prozessor" (de)/ CPU aka "Processeur" (fr)/ CPU aka "unità di elaborazione centrale" (it)
Comment I think there should be three allowed values: W, OX/OXY and SA (Simple Asphyxiant). ∼Wostr (talk) 10:04, 6 August 2013 (UTC)
There are more than 3 possibilities but only 2 are official. Snipre (talk) 11:24, 14 August 2013 (UTC)
As far as I know SA symbol is one of the three official symbols. See Chapter 8, par. 8.2.4, NFPA 704 (2012 edition). ∼Wostr (talk) 21:23, 15 August 2013 (UTC)
Added the template above. Someone might want to propose/create it. It seems preferable to split this out from FIPS 55-3 (locations in the US) (P774) -- Docu at 08:25, 13 August 2013 (UTC)
How useful is this for objects outside US? Does this help our bots to identify correct items and fill them with information? -- Lavallentalk(block) 07:31, 24 August 2013 (UTC)
It does make it easier to check the values in the other properties by clarifying the scope. Obviously, as all these FIPS codes are historic, current use is limited. Though, at least for US locations, they seem to have been used by the US government past their date. Maybe it's a way to help with the adoption of newer ones. -- Docu at 07:39, 24 August 2013 (UTC)
Historic or future is not a big deal, as long at it helps us identify items compared with databases and statistical reports. -- Lavallentalk(block) 07:44, 24 August 2013 (UTC)
Support - Isn't the letter needed to make the string an unambiguous? --Tobias1984 (talk) 06:50, 3 June 2013 (UTC)
Oppose I = italian, D = german, F = french : use the property language to define the language. Snipre (talk) 12:03, 3 June 2013 (UTC)
In that case it should probably be a multi-lingual string with all other languages linking to a default. --Tobias1984 (talk) 12:09, 3 June 2013 (UTC)
In that case you just give the url, the title, the language and the date of access and no property is needed. Snipre (talk) 17:30, 3 June 2013 (UTC)
Comment Articles are available in all three languages under the same identifier. Users can select the language of an article by changing "i/I" in the URL to "f/F" or "d/D". - Vacallo (talk) 05:03, 10 June 2013 (UTC)
libris is a library-catalog provided by the National library of Sweden. A libris-id is often a nice tool to easily identify books who do not have an ISBN.
Comment switched proposal to new template. Danrok (talk) 10:16, 12 September 2013 (UTC)
Support even if we have to create some new items. Filceolaire (talk) 12:43, 26 May 2013 (UTC)
Support but should be renamed to "type of electrification" for semantics. --Tobias1984 (talk) 16:14, 1 August 2013 (UTC)
Support --B.Zsolt (talk) 12:32, 23 August 2013 (UTC)
Comment is there a reason why we can't just say instance of = overhead line (Q110701) (with relevant qualifiers when available)? Danrok (talk) 14:15, 29 August 2013 (UTC)
'instance of' links an item to a class which contains that item. '25kV overhead line electrification system' is more like a part of a railway line than a class it belongs to. I think 'has part' 'overhead lines' is better than 'instance of' but it still doesn't feel quite right. I think this new property is worth having. Filceolaire (talk) 18:08, 29 August 2013 (UTC)
Heritage Foundation of Newfoundland and Labrador identifier (en) / identifiant Heritage Foundation of Newfoundland and Labrador
The English Wikipedia article on this property, Rada (fiqh), notes that 'rada' is a technical term with more specific meaning than simply a person that's important to another person. For example, it seems that this property would generally not be valid unless either the subject or object were female. And given the example of Muhammad al-Bukhari in that article, it seems like it might not be limited to persons. I think it would be worth establishing those kinds of basic parameters as part of this discussion.
I don't recall seeing any Arabic-speaking editors contributing to property proposal discussions. It'd be nice to get input from folks who are knowledgeable about rada. Would it be worth asking for input from users in Category:User_ar, and perhaps WikiProject Islam? Emw (talk) 03:48, 8 May 2013 (UTC)
Oppose I believe rada is a type of relationship (roughly understood as milk-kinship), not a property of a person. For example, you would not give a person the property 'marriage', but instead 'spouse'. Similarly, you would not assign a person the property 'rada'. Granted, this is just my understanding and could be incorrect. Kaldari (talk) 07:28, 25 May 2013 (UTC)
Rada is the relation of one person towards another. You do not say is a rada ... you imply: rada of ****. Thanks, GerardM (talk) 13:47, 28 May 2013 (UTC)
Oppose until a few examples are added to the template. --Tobias1984 (talk) 12:33, 4 August 2013 (UTC)
Comment is this sourceable data? Danrok (talk) 00:33, 31 August 2013 (UTC)
any item which describes a facility, e.g. escalator, toilet, car park, hangar, wheelchair ramp/lift, clinic, telephone, wi-fi, port crane, post office, letter box, lifeguard station, etc.
Comment this could be used on a wide range of items, and reduce the need for more specific properties. For example, we won't need a "number of elevators (lifts)" for buildings, just indicate that the building has facility = lift plus a quantity qualifier (when available) plus other qualifiers to indicate characteristics such as maximum load weight. Danrok (talk) 16:47, 29 August 2013 (UTC)
Comment allowed values = any item which describes a facility, e.g. escalator, toilet, car park, hangar, wheelchair ramp/lift, clinic, telephone, wi-fi, port crane, post office, letter box, lifeguard station, etc. Danrok (talk) 16:50, 29 August 2013 (UTC)
Even though this is done, I'd like to comment that I believe this duplicates the "has part" relation, substantially if not completely (on a side note, this is exactly the use that 'has part' is best for). --Izno (talk) 20:35, 16 September 2013 (UTC)
Not sure that the two are exactly the same. The spirit of has facility (P912) is similar to what we'd see for a place on a map, e.g. a park which has car parking and camping facilities. In some cases, a facility provided might not be a physical part of the subject item. A hotel may offer tennis facilities to its guests, but the facility could be part of a neighboring sports complex, not a direct part of the hotel. Other facilities are not so tangible. e.g. wi-fi, and perhaps "has part" doesn't quite fit there. Also, this property was proposed twice. The other proposal related to a requirement for Wikivoyage, but I'm not familiar with what is needed there. Danrok (talk) 01:43, 24 September 2013 (UTC)
Alternative use of interwikis. Working around the mainly inactive Gallery namespace at Commmons. Note the proposal below to link items for Commons Gallery pages (Q14916142) to items for articles (#Main_Commons_gallery_topic).
Some time ago I created Commons category (P373) to be able to store the links we have to Commons categories on Wikipedia's in a central location. This works, but is without the benefits of Wikidata. For example if a category gets deleted on Commons, this doesn't remove the claim. Now that Wikidata is going to be enabled for Commons, we can take the next step. We can start making links:
Based on that, we would need to create about 2 million items for existing Commons categories. -- Docu at 20:22, 9 September 2013 (UTC)
Why does Commons have such a large number of categories? Do you know? --Izno (talk) 22:09, 9 September 2013 (UTC)
Because Commons are file-based. There are 18'583'448 files on Commons and these are categorized in 2'950'000 categories. Galleries (that are also categorized) are only "additional bonus". --Jklamo (talk) 22:23, 9 September 2013 (UTC)
A large number of categories at Commons are intersected categories. For example "Churches in Haarlem". In the first run we should probably only create categories which are linked to, that would be a maximum of 800.000 items, but probably not even half of them. Multichill (talk) 07:31, 10 September 2013 (UTC)
I would tend to agree that this property should exist, and it's odd that it doesn't currently.
On a side note, we probably also need to figure out the whole namespacing situation that Commons deals with. --Izno (talk) 22:11, 9 September 2013 (UTC)
Oppose I say no unless the categorization of Commons will be maintained in Wikidata: w:Haarlem to Commons:Category:Haarlem, good thing but what happens is somebody changes the category in Commons without doing the update in Wikidata ? If Commons wants to use Wikidata, this means thaht every commons data will be mangaed in wikidata and not more in commons (no parallel system). Snipre (talk) 03:48, 10 September 2013 (UTC)
Snipre, I don't think you get it. This is not about metadata, this is only about the interwiki links. Multichill (talk) 07:31, 10 September 2013 (UTC)
Comment For pure symmetry, we should have this property, whatever the solution for Commons interwikis. -- Docu at 17:51, 10 September 2013 (UTC)
True, and because this is a one on one mapping we don't have an exploding problem. Multichill (talk) 19:45, 10 September 2013 (UTC)
Support as an intermediate step to getting rid of categoriesOppose 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.
I realize categories are fundamental to the current version of Wikimedia Commons. I have spent many hours curating categories and fastidiously categorizing my images there. I also realize there are currently also several very widely used properties that add some support for categories on client wikis. However, proposals for 'category' properties have been rejected before, see e.g. "category" and others. The fact that categories are currently so important on Wikimedia Commons does not negate the fact that queries and properties enable a vastly better solution to the problems that categories try to solve.
If someone could explain how this property would speed the transition away from categories and to a more property-and-query-based replacement, then I would likely support this property. Emw (talk) 02:38, 12 September 2013 (UTC)
I understand the property is not useful to you, but would the creation of this property adversely affect anything you try to do when using properties? -- Docu at 04:51, 12 September 2013 (UTC)
I would like to have a system available that will let me browse images in an ad-hoc categorization scheme fulfilled by queries and properties. The creation of this property seems like it would forestall that goal, as explained in detail above. Furthermore, "would the creation of this property adversely affect anything you try to do when using properties" should not be a criterion of valid opposition. Otherwise, why have a property proposal? Emw (talk) 12:14, 12 September 2013 (UTC)
Emw, I want to get rid of categories of Commons in the long run. I've been saying that for over 2 years. So in the future File:Bavo haarlem south.jpg would just have a claim "depicts" linking it to Grote Kerk (Q1545193). I believe that we should go step by step. Commons category (P373) was the first step and this is the next one to achieve this goal. This way the whole chain between an article on Wikipedia and a category on Commons is all claims and items. Better links come available on Wikipedia and it will be a rich source of information to start adding claims to images in the future. Multichill (talk) 16:22, 12 September 2013 (UTC)
I've changed my vote to conditionally support this property as an intermediate step to eliminating categories. Thanks for the explanation, and your work in this domain. Emw (talk) 23:11, 12 September 2013 (UTC)
Oppose because it is not needed. Commons categories currently linked with pages in most cases (see commons:Category:Luna 9, commons:Category:Jimmy Wales as examples). This is good practice because there are many logical links between Wikipedia articles and Commons categories. Number of links between Wikipedia categories and Commons categories is less. Usually Commons category tree have +1 hierarchy level then Wikipedia category tree. This occurs because when we have notable object we create aritcle in Wikipedia and category on Commons for it. Wikipedia categories can obtain commons link using existing Commons category (P373) or category's main topic (P301). For gallery pages we can create separate property or do not use it at all because galleries exists for too low number of articles and often outdated. — Ivan A. Krestinin (talk) 18:47, 14 September 2013 (UTC)
Category items include links to Wikipedia and Wikivoyage too - so this isn't just about Commons. See Q5626403.
Wikivoyage`s hierarchy is more similar to Wikipedia as I see. Commons has different structure. — Ivan A. Krestinin (talk) 12:53, 15 September 2013 (UTC)
Yes, Commons has a different structure, but that doesn't preclude a link from a mainspace item to a corresponding category item from being useful, nor does it render this proposal invalid. Because Commons category (P373) goes directly to Commons it cannot provide this item to item link.
Subject Headings for public libraries mantained by the Spanish Ministry of Education, Culture and Sport. Terms are linked (in different numbers) to LCSH, GND, RAMEAU, LEMAC (Subject Headings in catalan).
Support There is depicts (P180) which is used for descriptive creative works (a picture <depicts> item), then there is category's main topic (P301), which is used for categories. It was perceived that none of this properties was precise enough to describe the subject/topic of a creative work.--Micru (talk) 00:46, 25 June 2013 (UTC)
Ok, so all the discussions are over, and this property should be differentiated from category's main topic (P301) because when doing searches it would bring up confusing results (category items). So if there is no opposition or no other comments I will create this property in a week from now.--Micru (talk) 20:47, 19 August 2013 (UTC)
Wait I put this property on hold until the discussion about subject headings has finished (extremely related to this one).--Micru (talk) 14:23, 26 August 2013 (UTC)
Support --Shisma (talk) 14:43, 27 August 2013 (UTC)
so whats happening here? I don't see how subject headings is related to this property--Shisma (talk) 09:17, 9 September 2013 (UTC)
Support I was going to propose this property after the discussion concerning hierarchy of the property P60 (P60). @Ivan: 1) my idea is to use P60 to classify astronomical objects to help Wikipedias to choose the right infobox. Furthermore, we can classify stars also for spectral type, luminosity class... 2) I prefer to not mix values of a property that can be used to choose an infobox or give a value for infobox parameters. --Paperoastro (talk) 20:12, 20 July 2013 (UTC) P.S.: I'd like to have your opinion about this. ;-)
Ok, I just ensure that you know about P60. — Ivan A. Krestinin (talk) 17:21, 30 July 2013 (UTC)
Support --Art-top (talk) 15:13, 30 July 2013 (UTC)
Comment: This is needed for situations where an airport served a notable destination, particular as its primary service area, but this is not reflected by its location. Many airports are located in smaller towns outside of the primary city they serve. Joshbaumgartner (talk)
Weak support - Shouldn't this link to US-counties instead of cities? Maybe name it "closest international airport for" and then list all the counties? --Tobias1984 (talk) 09:12, 1 May 2013 (UTC)
Comment I'm not entirely sure how exactly to limit this one, so I see your point. I avoided including something like 'closest...' or 'primary...' because it could limit the utility of the property. Boeing Field (technically an international airport I believe) is closer than Sea-Tac to Seattle, but clearly Sea-Tac is a Seattle airport. Also, this property should be able to be used by non-international airports as well. I'm also not sure that an 'airport' property for use with cities/divisions/countries might not allow the same goal to be met from the other direction. Qualifiers could be used in that case to indicate role (some cities have different airports focused on different areas of flying). Joshbaumgartner (talk) 09:37, 1 May 2013 (UTC)
Support Note that the infobox label is city-served Infobox_airport. Danrok (talk) 00:01, 25 May 2013 (UTC)
Weak oppose in some countries major international airport can serve half of the country - shall all it's cities and towns be listed in it? --Base (talk) 13:10, 28 June 2013 (UTC)
I don't think it has to be a city. There are articles for the recognized regions of most countries, so we could probably use those. TCN7JM 12:44, 6 August 2013 (UTC)
I agree. For a small country, e.g. Estonia, you would just specify that Tallinn airport serves Estonia, so just one item to list, not every city. Danrok (talk) 02:51, 27 August 2013 (UTC)
Support - Useful TCN7JM 12:48, 6 August 2013 (UTC)
Weak oppose This depends on both destination and what airline. Heathrow serves in some parts all of Europe, and maybe more than that. -- Lavallen (block) 05:45, 7 August 2013 (UTC)
If it can't be sourced, then there's no problem. It can be simply omitted for Heathrow (given that nothing is specified in the article). This should not prevent the creation of this property, which will be useful for many airports. Danrok (talk) 02:59, 27 August 2013 (UTC)
Support - Interesting! Quico (talk) 14:53, 9 August 2013 (UTC)
If the airport is associated with a major city but actually located in a smaller town, list the major city here and the smaller town under location. This is not automatically linked, in order to allow multiple links if needed. (Source of this description: Airport summary.)
Oppose Use data of the original publication instead of an intermediary reference. Snipre (talk) 23:16, 14 August 2013 (UTC)
Sure, but this property can be used for verification purposes, to check that the original publication details are accurate.--Micru (talk) 00:10, 15 August 2013 (UTC)
And what happens if the pmc code is wrong ? Which is right ? Then we have the DOI which more general than the pmc. We have to be careful with crosschecking parameters because once you have 3 or more prameters which can defined 3 or more different objects that is a mess to see what is correct especially when you don't have the access to the documents. Snipre (talk) 12:42, 15 August 2013 (UTC)
According to good citation rules, you cite where you get the information from, regardless of whether that source is the actual original source of information. That's no less true for a website database such as PubMed then it is for an encyclopedia. --Izno (talk) 03:45, 17 September 2013 (UTC)
Support. --Izno (talk) 03:45, 17 September 2013 (UTC)
Support, though I think the the property's name should be changed from "PubMed Center article number (pmc)" to "PubMed Center reference number (PMCID)"; see http://publicaccess.nih.gov/citation_methods.htm. Emw (talk) 04:09, 17 September 2013 (UTC)
CommentCommons category (P373) is an intermediate solution and I expect it not to stay around very long. With wikidata coming to Commons I don't think this is needed. Multichill (talk) 18:02, 9 September 2013 (UTC)
Support Support as nom. See this RFC. Filceolaire (talk) 00:11, 19 August 2013 (UTC)Proposal withdrawn as per Danrok below.
Comment I created a similar proposal here before I saw this. Seems to be the same, except I am suggesting broader scope. Danrok (talk) 00:58, 30 August 2013 (UTC)
This is just to collect ideas, to brainstorm, not to evaluate if we should have such a property (no pros and cons). Such a property is not meant to replace other properties or interfere with the way they may work. Please avoid mentioning P31 (we already read all about that and people can look it up) and GND type (this has been discussed elsewhere).
Things it should be able to do:
identify easily if an item is about a real person (or a legendary one that might have lived), possibly before we know gender, DOB, etc.
identify items about organizations, companies
identify geographic features on Earth, possibly before we know which country it is located in, the exact coordinates ..
identify objects in space
identify Wikipedia specific items (templates, Wikipedia namespace pages, categories, etc.)
identify everything else
Please mention things it should do for you. -- Docu at 05:33, 10 September 2013 (UTC)
Yes, please respect my request above and discuss P31 there, not here. Thanks. -- Docu at 21:42, 11 September 2013 (UTC)
Docu, have you seen the discussion at the Primary sorting property RFC? The questions above are precisely what was discussed there and I can't find your signature anywhere on that page, so it seems plausible that you might be unaware of that conversation. Emw (talk) 03:04, 12 September 2013 (UTC)
If you have suggestions for principal groups, please add these here. Thanks. -- Docu at 04:36, 12 September 2013 (UTC)
You request that we "mention things (a list of main types) should do for you". I'm interested in biology and think it's generally relevant; a list of main types should help me find things related to biology. So in a hypothetical world in which we, for some reason, ignored detailed comments in one of Wikidata's most active RFCs and pursued the very suboptimal idea of having a "main type" property, here are some main types I would like to see:
Disease
Organism (+ viruses)
Biological sequence (e.g. gene, protein)
The last might be a stretch, but it's still very high-level and something I would like to see in a list of main types. The other two seem clearly important enough to have among main types, certainly more than "objects in space". Emw (talk) 12:08, 12 September 2013 (UTC)
I added them. -- Docu at 11:05, 15 September 2013 (UTC)
subclass of (P279) is the property to do this, creating a hierarchy of groups/classes from the very specific up to the very general. Then we need tools to let us define a class as all the instance of (P31) of an item plus all of the items that are subclasses of that item (sorry but you can't discuss subclass of (P279) without mentioning instance of (P31)). This is being used to do all the things you list above. Filceolaire (talk) 21:47, 12 September 2013 (UTC)
Brainstorming can be hard. Maybe I should start a separate thread for all the instance/class comments. -- Docu at 23:57, 12 September 2013 (UTC)
This is the wrong place to be doing this. You might consider opening an RFC. --Izno (talk) 18:18, 14 September 2013 (UTC)
Weak support - If this tries to link e.g. Ephesus (Q47611) to Selçuk (Q876176) I support that. I think the English description might have to be reworded to be a little clearer. It might also be a thing we could query. Ephesus lies in the administrative region of Selcuk. So actually we are producing a slight redundancy in many of those statements. --Tobias1984 (talk) 16:02, 1 August 2013 (UTC)
Maybe these could also use P17, P131 and/or P30. BTW the proposed English name is already used by Property:P276 ("current location"). -- Docu at 19:33, 8 August 2013 (UTC)
Not done as far as I can see, based on the example given by the proposer, there is no need for this property. Also, no need for "current" type properties, just use date qualifiers. Danrok (talk) 10:03, 25 September 2013 (UTC)
historical period
Not done
Description
The historical period to which the item belongs according to relevant sources
Support Seems like a good idea to me. Ajraddatz (Talk) 17:18, 2 September 2013 (UTC)
In addition to the regular date markers, all such time-based items could also state which historical period it was/is part of? No limitations? --Yair rand (talk) 18:03, 2 September 2013 (UTC)
No limitation as such. For some items there may not be any specific dates available, but the item may have been determined to originate in a given period, which is one good reason for this property. Danrok (talk) 18:02, 3 September 2013 (UTC)
Could 'part of' do this job? Filceolaire (talk) 21:37, 4 September 2013 (UTC)
Maybe part of could work, if so it would be the best way. Take a look at Roman Kingdom which is described as a period, but also described as part of the Iron Age (another period), and as part of modern Italy. I can't think of any issue with claiming that it is part of all of those things. I'll look at some more examples. Danrok (talk) 00:42, 5 September 2013 (UTC)
Oppose Better give the dates of the start and the end as qualifier. For the example above, this can be described withe the property official name with dates as qualifier. Snipre (talk) 19:57, 5 September 2013 (UTC)
Comment For many items there are no dates, which is part of my motivation for this. Also, not all historical eras have specific start/end dates. This is not necessarily about dates, it's about an expert stating that a given thing is of a certain era, based on scientific evidence and methods. For example, an item is found in the ground along with pottery from a certain period, so the item can be assumed to belong to the same period. Danrok (talk) 22:10, 5 September 2013 (UTC)
Not done I'll abandon this for now, in favour of using part of. Danrok (talk) 02:20, 25 September 2013 (UTC)
Comment In contrast to H phrases, P phrases are not defined by the regulatory authorities. --Leyo 21:33, 28 July 2013 (UTC)
P phrases are derived from H phrases: there are some official rules to translate H phrases to P phrases. In some way we can do that automatically. Snipre (talk) 17:46, 20 August 2013 (UTC)
GRAU index (Q527163), условное цифро-буквенное обозначение образца вооружения, присваиваемое одним из Заказывающих Управлений Министерства обороны СССР и России
Oppose who needs this in infoboxes or lists? It is enough if you write it in the articles, though not necessary for an ecyclopedic view. It is also not needed in boxes to know where the wedding ceremony was or the baptism ceremony or the bar mitzwa or whatever ceremony one can experience in life (or death in that case).--Giftzwerg 88 (talk) 09:28, 27 August 2013 (UTC)
Not being useful for Wikipedia infoboxes or lists does not mean it shouldn't be included in Wikidata. That said, I'm not sure having a unique property would be the best way to handle this data. Each funeral having a separate item might work, but that seems rather cumbersome. --Yair rand (talk) 10:25, 27 August 2013 (UTC)
We have place of burial for this purpose which is clearly identified. We can speculate about the location of the funeral ceremony of the pharaohs a lot.--Giftzwerg 88 (talk) 19:29, 31 August 2013 (UTC)
thx for the info. I'm ok to withdraw my demand. Pyb (talk) 14:42, 27 August 2013 (UTC)
Comment The use of significant event (P793)=>funeral (Q201676) indeed seems to respond to the demand. But if we want to request people on funeral ceremony, we could have a confusion with burial (Q331055) which is a sub-class of funeral (Q201676) and have 2 different places and 2 different dates. Maybe it could be interresting to create an event funeral ceremony, sub-class of funeral (Q201676).--Shonagon (talk) 20:20, 27 August 2013 (UTC)
I think there's a long list of possible events regarding funerals around the world and throughout time. Same for births, as it is we don't have any properties relating to baptisms (and that is often the only date recorded, churches didn't record the birth date. The recording of dates of birth is a fairly new process). Danrok (talk) 19:47, 31 August 2013 (UTC)
Not done opposition, and proposer agrees with an alternative solution. Danrok (talk) 00:15, 28 September 2013 (UTC)
Does this include nonfictional entities? If so, I think it would be better for this to be a property of the work, rather than of the subject featured. Also, some limitations would really need to be in place. ("France" appears in the work? "George Bush", "Microsoft", a "keyboard"? Etc.) --Yair rand (talk) 11:17, 17 July 2013 (UTC)
Yes, this could become problematic if not limited within reason. Restricting it to apply to only fictional entities would likely resolve most issues, and is its intended purpose. On the other hand, with some appropriate user interface support (limiting the number of items shown by default) it might be possible to also support this for some non-fictional entries like "France" and "George Bush", but also applying it to entities like "keyboard" would probably be overdoing it. —Ruud 12:14, 17 July 2013 (UTC)
Comment This needs to be more clear. The meaning of "appears" in this context means that the actual person appeared. For example, Steve Jobs did not appear in Jobs (Q392825), he was portrayed in that movie. In any case, all of this is already handled in the movie's item using the cast member and role properties. So, this kind of information can already be determined. Danrok (talk) 15:52, 25 August 2013 (UTC)
Oppose. Better have properties that work the other way round - you don't want 'London' to have a list attached to it of every film and book that it ever appeared in. Filceolaire (talk) 10:18, 31 August 2013 (UTC)
Oppose too general. Snipre (talk) 11:19, 1 September 2013 (UTC)
Not done due to opposition, and little support. Danrok (talk) 00:12, 28 September 2013 (UTC)
possible examinations / (fr) examen complémentaire
Authors with the same name that cannot be distinguished without error, authors signing with initials or incomplete name and whose identity cannot be determined now.
Support I think we also need a task force to help with identifying these authors. --Stevenliuyi (talk) 20:29, 5 June 2013 (UTC)
Support but change the name: this is the author property with another datatype. Insome cases even if the author can be identified as he published only one document there is no advantage to create an item for that guy. Then you have to propose a string format in order to handle that author in the same way as name from author item: example Li, Wang, or L. Wang or Hells, G. M. Snipre (talk) 00:51, 7 June 2013 (UTC)
I think if it is identifiable we should create an item wether there is an interest or not. Identifying objects to items is the whole point of items, and if the author is identifiable we have some sourcable datas on him. Having an item on him will nethertheless help people to cite him as author if he write or has written on something else, and with the source the work will have to be done only once, and not potentially over and other again checking google to see if there is information on that name string on google, to see if there already have authors on the same name on wikidata ...
Support but only if we can obtain nothing on the author. We should always have some informations on the author on something, it is important to have a bird eye view on the quality of source. TomT0m (talk) 14:30, 8 June 2013 (UTC)
Oppose I think here should author be used instead with a qualifier that the author is unverifiable. --Pyfisch (talk) 19:18, 10 June 2013 (UTC)
But with your solution 2 authors with the same name and without elment to differentiate them will share the same item. This proposal aims to solve the problem of author without wikipedia articles: in lot of documents like scientific or newspaper articles the authors are unknows even if you have their names. If the author name is special no problem but if the name is share by different authors you will have to 1) create in new item for each occurence or 2) use the same item even for different persons. Snipre (talk) 19:08, 12 June 2013 (UTC)
Neutral, not really against, but I think we could create items even for "unverifiable" authors, just like the GND "undifferentiated" type. It would avoid to have two properties to express the same relation. -Zolo (talk) 20:26, 12 June 2013 (UTC)
Oppose - qualifier or rank will be better. Otherwise we create many properties twice (verified and unverified). --Nightwish62 (talk) 18:08, 6 July 2013 (UTC)
Oppose per Nightwish Filceolaire (talk) 04:20, 28 August 2013 (UTC)
Not done due to a number of oppositions with explanations. --Danrok (talk) 20:02, 29 September 2013 (UTC)
Comment I think it would be best to use the creator (P170) for this, and create some suitable items which would be the unverifiable authors. Each item would be claimed as a name of an author, or several authors of the same name, who cannot be fully identified. Danrok (talk) 20:25, 29 September 2013 (UTC)
Once upon the time there was a property labelled based on/Inspired by which now has been relablled to based on. maybe because these are two separate things. this ancient property can be found here: based on (P144). please feel free to add better examples --Shisma (talk) 15:39, 27 September 2013 (UTC)
Correction: based on (P144) has been "based on" since the beginning in Feb 2013, and only "based on/inspired by" between Aug 18th and Sep 26th. --AVRS (talk) 08:12, 28 September 2013 (UTC)
Support needs to be separate from based on. Useful property for many items. --Danrok (talk) 20:11, 29 September 2013 (UTC)
Code attribué à chaque localité de Hongrie par l'Hungarian Central Statistical Office (Q1125966) à des fins statistiques. / Code of the Hungarian Central Statistical Office for every locality (town and commune) in Hungary / A KSH kódja minden magyarországi településre
Utilisés sur Wikipédia en français dans le modèle d'infobox des localités de Hongrie / Used in the French WP template for localities of Hungary / A francia wikin a magyar település infobox sablon használja : fr:Modèle:Infobox Commune de Hongrie/Code KSH
Domain
Localités de Hongrie : 3179 villes et communes. / 3179 towns and communes of Hungary / 3179 magyarországi település
Les ajouts sont facilement automatisables. / Easily added by bot from source / Könnyű adatfeltöltés bottal a forrásból. Add 'http://www.ksh.hu/apps/!cp.hnt2.telep?nn=$1' to Gadget-AuthorityControl.js
I added a request for Gadget-AuthorityControl.js to show the value with a link to the page of the locality on the KSH site (Hungarian Central Statistical Office), since this page will be the source of many other property values for the locality which are presently discussed here (in French, but feel free to use English or Hungarian, maybe in a new section). Oliv0 (talk) 09:23, 27 August 2013 (UTC)
Comment Seems ready for creation. -- Docu at 19:04, 6 September 2013 (UTC)
Comment Thanks Danrok for the creation. The link on the value through Gadget-AuthorityControl.js is still absent, and I think also the control of allowed values and allowed items. Oliv0 (talk) 18:40, 26 September 2013 (UTC)
I can't edit Gadget-AuthorityControl.js because I am not an admin. But, you can ask someone to do that here MediaWiki_talk:Gadget-AuthorityControl.js. I believe the control of allowed values can be set-up/modified by anyone. --Danrok (talk) 12:19, 30 September 2013 (UTC)
Comment -- I'm not clear on what this data is for. "Sign"" means exactly what? Once we figure it out, we might be able to name the field a bit more descriptively to help other English readers. Cheers. N2e (talk) 14:01, 27 April 2013 (UTC)
I think this is call sign - Soyuz TMA-8, callsign Karat. Secretlondon (talk) 14:43, 27 April 2013 (UTC)
Для аероліній існує Property:P432 — можливо просто розширити її сферу дії? --Base (talk) 16:22, 2 May 2013 (UTC)
I think airplane call sign are different? Secretlondon (talk) 20:22, 3 May 2013 (UTC)
How is it different? I would prefer to have one general callsign property to be used in space mission/ships/planes and what else may use callsigns. Byrial (talk) 08:30, 9 May 2013 (UTC)
We'll we'd need to rename P432 and take the restraints off. Secretlondon (talk) 11:26, 9 May 2013 (UTC)
The problem is if we use P432 for any call sign, it gets harder to do constraint checks on it. -- Docu at 11:40, 12 May 2013 (UTC)
Do we have a military callsign field? That would be a closer match than an airline's callsign? --WDGraham (talk) 18:38, 22 May 2013 (UTC)
Comment I think that callsign of airline (P432) should be renamed to call sign, based upon what I have read about call signs. See Call sign. Danrok (talk) 00:11, 30 August 2013 (UTC)
Comment Also, constraint checks will be difficult given that any organization or person can potentially have a call sign (need to apply for it, have a licence for that radio, etc.). Danrok (talk) 00:15, 30 August 2013 (UTC)
Comment See this guy's call sign is FK8GX. Danrok (talk) 00:19, 30 August 2013 (UTC)
Support given that spacecraft call signs are exceptional, but it looks like this will need to be multilingual-text, or a string in the original language only. Danrok (talk) 00:27, 30 August 2013 (UTC)
Comment Should be string. The whole thing about call signs is that they are unique identifiers, independent of language. If you want explanations or transcriptions these can be in multi-lingual qualifiers properties. Filceolaire (talk) 20:39, 30 August 2013 (UTC)
Oppose. Rename P432 and use that instead for airlines, spacecraft, ham radio etc. As call signs are arbitrary strings it will be tough to apply constraints. Where call signs for a particular domain have constraints which can be checked then we can check based on the Class that the subject of the property belongs to. Filceolaire (talk) 20:39, 30 August 2013 (UTC)
All non-space call signs will be unique (as far as I know). Space call signs might not be, because they're not regulated in the same way. I have no idea if there really are, or have been, 2 entities with the same call sign. But, perhaps this won't present an issue if all call signs share the same property, search results can always be further filtered to weed out spacecraft/astronauts, if needed. I'll mark this as not done, and change the description of callsign of airline (P432). Danrok (talk) 13:50, 2 September 2013 (UTC)
I didn't find any property that describe could be used in this way. I though that it could be used as qualifiers, but, like follows (P155) and followed by (P156) it could be used normally if needed. It maybe used in other proposes, but I just though in this.
P.S.: I don't know what could be the name in English so I put this. I would appreciate if you find one better. - Sarilho1 (talk) 12:40, 12 August 2013 (UTC)
Oppose* The example is implied by a query (award winners with qualifier date of), so I would oppose that usage. Is there another example that would make this property useful? --Izno (talk) 23:47, 22 August 2013 (UTC)
Commentcollaborator is one possible word for this, with on its own is very broad. Danrok (talk) 21:32, 30 August 2013 (UTC)
Comment for use with awards only, it would be called the joint awardee. --Danrok (talk) 02:38, 25 September 2013 (UTC)
Oppose "With" is too broad, it might be used instead of the best descriptive property. --DoSiDo (talk) 12:02, 4 October 2013 (UTC)
Not done No consensus. John F. Lewis (talk) 18:50, 6 October 2013 (UTC)
Dedicated item for property
Not done
Description
a property to identify with which property a given item is used. Can make it easier to do "one-of" constraint checks. Avoids cluttering other properties (e.g. P31)
Added above template. -- Docu at 17:33, 5 September 2013 (UTC)
Interesting idea. What tasks are needed this property? — Ivan A. Krestinin (talk) 12:45, 15 September 2013 (UTC)
It could make it easier to check one-of constraints. Instead of adding items to the list on the talk page, one would add this property to the items themselves and then using (Template:Constraint:Target required claim). -- Docu at 12:51, 15 September 2013 (UTC)
As it works with instance of (P31) I don't see a need for this property.
but I would like to rename "Constraint:Type" to "Constraint:Domain" and "Constraint:Value Type" to "Constraint:Range". Filceolaire (talk) 20:33, 20 September 2013 (UTC)
But I Support idea with "Dedicated item for property". Lets try this approach too. — Ivan A. Krestinin (talk) 18:12, 15 September 2013 (UTC)
I think we should avoid adding metadata to the database. My 2 cents. --Izno (talk) 18:19, 15 September 2013 (UTC)
I agree with Izno that using items and properties to define metamodel entities is inappropriate. However, unless developers suddenly realize that and propose new types of links for structuring concepts, better use such properties than doing nothing. - LaddΩchat;) 16:37, 20 September 2013 (UTC)
As I said at #Constraint type, the devs have signaled positively that they would like to work out a better way for us to store metadata and metarelations. The better question is when, as the devs always seem to be busy with other things. :). Until such time, I think the current way to deal with metadata is fine. --Izno (talk) 20:18, 20 September 2013 (UTC)
Comment seems like a hack because the dev team does not allow to use Properties entity in statements (and to put statements in properties). Really a good idea or should we talk to them ? TomT0m (talk)
Oppose. Add Constraints to the properties instead (using templates on the talk page until we can do something else). Filceolaire (talk) 20:38, 20 September 2013 (UTC)
No, a solution for this kind of data is instance of (P31) with an adequate classification. See the RfC about this subject. And we don't delete the GND property to create a new one using these items. Snipre (talk) 11:19, 16 September 2013 (UTC)
Agre with Snipre. The Domain should be defined by the class (item) which the subject is an instance of. Not by these P107 items. Filceolaire (talk) 17:32, 21 September 2013 (UTC)
The Wikidata devs have already discussed helping us with metadata management through other means and are amenable to other solutions than properties.
That aside, as I said elsewhere, we should not include metadata relevant only to Wikidata in the list of properties. --Izno (talk) 19:46, 16 September 2013 (UTC)