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)
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)
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)
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
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] --凡其Fanchy16: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--凡其Fanchy10: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--凡其Fanchy19:35, 1 June 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.
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)
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)
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)
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)
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
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. —Ruud14: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. —Ruud21:08, 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, 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)
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)
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.
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)
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)
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)
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)
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.
'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)
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)
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:
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)
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.
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)
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. ;-)
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)
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. TCN7JM12: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)
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)
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.)
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)
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.)
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)
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)
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)
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)
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
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)
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)
Comment In contrast to H phrases, P phrases are not defined by the regulatory authorities. --Leyo21: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)
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)
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. —Ruud12: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)
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 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)
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)
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)
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 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)
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)
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)
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)
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)
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)
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)
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)
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)