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
Possible, but be carefull! Examples where it can be wrong is in "216 Kleopatra". MPC 73983 only tells the origin of the name of "Cleoselene" and "Alexhelios", not the main object itself.
Today I see q328 used as "source" everywhere and my insticts tells me it's wrong, but I understand why it's necessary. This gives us a better alternative. Lavallen (block) 18:24, 10 May 2013 (UTC)
Support This is a good idea! A script could automatically show the link to the web page, as for GND or VIAF properties. --Paperoastro (talk) 11:25, 12 May 2013 (UTC)
A good idea, if it's possible. I have tried to copy those uri, but there is something strange with them. Does it demand a POST? -- Lavallen (block) 13:37, 12 May 2013 (UTC)
Please do not create a particular reference system. For website we have a set of "mandatory" parameters see in order to have a general concept as explained in Help:Sources. And if you want to use URL data please wait on the appropriate datatype because it would be a mess later. Snipre (talk) 17:22, 18 May 2013 (UTC)
I did not proposed it as a webb-property. I do not simply find a way to create a url based on this "number". I rather propose this as a "serial number" for this publication. The matrix in the webb-page above simply connects each "serial number" with some claim in some items. I know there is a RFC about references in progress, and this proposal should not be closed as succesfull until we know the result of that RFC.
Regarding the RFC: I find it very difficult to understand what they talk about there. But I often fail to understand the technical parts of references even when they are discussed on Wikipedia. To often are Wikipedians speaking about references as if they are going to publish a hand-written dissertation. My teacher told me to not bother about such things, as long as I use the same system in all of the paper. LaTeX simply solved that for me. -- Lavallen (block) 17:52, 18 May 2013 (UTC)
RFC concerns mainling books and the problem of different editions of the same but having different bibliographic data. Do not focus on that if you are not using books for referencing. Snipre (talk) 04:24, 19 May 2013 (UTC)
I'm sorry to generate confusion with my idea of automatic link! MPC circulars are identified only by a progressive number (and, optional, by the date of pubblication), as specified by Lavallen in this proposal. My idea of creating automatically a link to the web page (as for GND or VIAF) is not feasible because the circulars are grouped by the day of pubblication.
@Snipre thank you very much for the link, I read it very carefully. Imho the idea to have few properties to manage sources is intriguing and "MPC circulars" could be identified in the group of report.
@Lavallen your professor (and you) has right: is importat to use the same system, and in Help:Sources people try to do this for Wikidata ;-) Do not be discouraged! If I understand correctly, MPC circulars can be identified as "Report" in this manner:
Title: MPC circulars number;
Author: the list of authors;
Publisher: Minor Planet Center;
and, if we want, we can use also the Date of publication and the language. Do you agree?
If all of you are agree, we can change this proposal to create the missing property title for Reports. --Paperoastro (talk) 00:31, 19 May 2013 (UTC) P.S.: I hope not to be too bold!
Please support the Article title proposal with your comment for extension to report in order to show the consensus for the property creation. Snipre (talk) 17:53, 26 May 2013 (UTC)
@Lavallen: they actually use some sort of silly referer check, the message is "This script can only be called by the MPES or from the list of discovery circumstances of numbered minor planets." --Ricordisamoa22:44, 26 May 2013 (UTC)
Oppose We can use instance of or subclass of. Snipre (talk) 18:14, 8 June 2013 (UTC) I am not convinced by this proposal but I prefer to have this property and a solution for sourcing statement than spending still weeks in discussion. We can always change the property later. Snipre (talk) 19:26, 14 June 2013 (UTC)
It is not possible to have an item for every article so for reference purpose so we need an additional property allowing to enter this information in reference data. A constraint to use this propery will be to use it in parallel of the property "stated in": the "Article title" property concern only subpart of another work (a journal for example) and the whole work in which the article is published has to be cited too. Snipre (talk) 09:31, 13 April 2013 (UTC)
I think we need a "title" property for all sorts of works. It should be a monolingual string, a be the full title, by contrast to the label that is multilingual, will often be missing in many languages, and can clip the real title for convenience).
I would support simply renaming P:P357 to title. Having two properties is confusing, as we do not know which one to choose when the work does not have any translation. Major libraries simply use "title" for the original title, and that makes even more sense in a multilingual database. Note that I had initially created P:P357 under the name title and documented it with Q12418, where "original title" does not make any sense. --Zolo (talk) 07:29, 25 April 2013 (UTC)
A general title property for articles, report, books and so on will be very useful. Initially I was agree with Zolo to use P:P357, but I prefer as datatype monolingual string instead of string, so I Support the creation of this property with monolingual string datatype. To avoid confusion, P357 should be deleted. @Lavallen: monolingual string is a string with in addition the specification of the language of the text. --Paperoastro (talk) 18:36, 26 May 2013 (UTC)
We have a property to specify the language of the work see Property:P407, so we don't need to wait on a monolingual datatype. Using a property to screen language of sources is more simpler than using a subinformation of a datatype. And if you assume that you will have item as sources like for books, the language property will be the best solution to screen and compare languages of all sources and in a independent way from the datatype. Snipre (talk) 07:38, 27 May 2013 (UTC)
Your idea sounds good, and surely it could avoid confusion. (I "delete" my comment above, after your explanation) ;) Before to support this proposal, I have a question: what is the difference between this new property and P:P357? There are any reasons to have a different property? --Paperoastro (talk) 11:47, 27 May 2013 (UTC)
Comment Isn't it enough to create the property "triple point temperature" and use a qualifier for the pressure? As an alternative we could also make a property called "triple point" that links to an item which describes which triple point were talking about. Both temperature and pressure would be existing qualifiers for that property and we would be able to create items for all the phase changes not only the triple point for solid-liquid-gas. --Tobias1984 (talk) 15:25, 10 June 2013 (UTC)
Comment I think key point (item) with qualifiers temperature (number) and pressure (number) would be a better solution than having these 4 properties. This way all the information belonging together would be in the same claim. —★PοωερZtalk14:56, 8 June 2013 (UTC)
I can't really be done like that, because all of those measurements need qualifiers themselves if they weren't carried out by STP-conditions. I think we would need a new multi-dimensional data type to fully describe a chemical system with all its physical characteristics. --Tobias1984 (talk) 16:03, 8 June 2013 (UTC)
Support - As all of thermodynamics everything should be strictly in Kelvin and Pascal. No Bars, Fahrenheit, mmHG, etc. --Tobias1984 (talk) 16:03, 8 June 2013 (UTC)
No, unit as to be put in the original ãnd unit will be converted in the template in the client. the reason for that is to ensure a correct conversion of the unit. Snipre (talk) 17:53, 8 June 2013 (UTC)
To my knowledge all thermodynamic literature is metric so if somebody enters a non-metric number, that number has already been converted. So there is no way to tell if it has been converted correctly the first time around. --Tobias1984 (talk) 20:35, 8 June 2013 (UTC)
In organic chemistry they used a lot the calorie unit and depending the publication especially the old ones you can find formation enthalpy in kcal. Snipre (talk) 21:53, 10 June 2013 (UTC)
Units are a core problem of number datatype. We should wait for the devs to create the datatype before discussing possible problems with it. —★PοωερZtalk22:01, 10 June 2013 (UTC)
phase diagram of water for different ice phases (German)
Comment Water has eleven known triple points, so you have to group them together in one way or another (and also two critical points). —★PοωερZtalk04:20, 10 June 2013 (UTC)
You're right. We could rename this property "triple-point solid-liquid-gas"? What can we do with the other triple points? --Tobias1984 (talk) 15:11, 10 June 2013 (UTC)
When we create a property for one of the triple points, all of them should have one, but I think that's the wrong approach since we could end up creating a property with only one use. We have items for the different phases, e.g. ice Iₕ (Q1051773) (at least for water, I don't know about other materials' phases, so we might have to create them), so something like this structure could be better:
We might be able to replace Ice Ih, etc. by hexagonal, etc. to avoid creating items, as Ice Ih is just the name of the water phase with a hexagonal crystal system. —★PοωερZtalk18:29, 10 June 2013 (UTC)
Not in favor of a string datatype for triple point: I agree for the idea of T and P as qualifier, but I would propose to use 3 times the property phase as qualifier each time to describe one phase of the triple point. Ex.:
Support - I think this is the way to go for all the other cases of triple points. The solid-liquid-gas triple point might be special enough to warrant a separate item. Also, we should create separate items for all the phases of ice. We do the same for all the minerals and there are a lot of physical statements that can go into those items. --Tobias1984 (talk) 18:39, 10 June 2013 (UTC)
Alternative to 'edition' with datatype 'string' instead of 'item'.
Property is used to list editions of a book whether or not the edition has it's own item. If an edition does not have an item the qualifiers such as 'date of publication', 'place', 'language', 'title', 'subtitle' etc. can add info.
If an edition does have it's own page then qualifier 'dedicated page' can link to that page or 'edition of' can provide a reverse link.
Oppose If done this way it won't be possible to point to a specific edition of an item, besides there are many other fields associated with the edition that should be "packed" together (isbn, publisher, date, etc.).--Micru (talk) 18:14, 12 June 2013 (UTC)
Question - (1) Does a university in Bejing really have an English motto? (2) How will translations be available in monolingual-texts? --Tobias1984 (talk) 16:11, 8 June 2013 (UTC)
Comment Some Wikipedias use both, turnedpro and retired parameters (including en-wiki), and some only active parameter (e.g. 2000–2010). So I'm not sure what we should do with that, and if this is duplicate with from time (since) and to time (until). --Stryn (talk) 16:23, 1 May 2013 (UTC)
Support If both years are stored in wikidata, specific infoboxes may choose to display them on the same line or not. Vinkje83 (talk) 10:02, 7 May 2013 (UTC)
Wait This is better accomplished with a date datatype, and 'from/start' and 'to/end' properties will be amongst the first date properties available. Joshbaumgartner (talk) 10:09, 9 May 2013 (UTC)
Oppose as "number" datatype. We should have qualifiers of "datetime" type (not available yet), or maybe a "date-interval" datatype. --Ricordisamoa07:26, 14 May 2013 (UTC)
Source: External links section in biography articles in Wikipedia
Example item and value: <Toomas Hendrik Ilves> Twitter account <IlvesToomas>
Comments: Should be verified somehow. Link in personal webpage is good, Twitter account verification is better. --Papuass (talk) 13:36, 12 March 2013 (UTC)
Oppose. This would open the door to facebook-page, google-plus-page, tumblr, myspace, and many many more. Also I dont think that such property has any relevance in say 20 years.--Svebert (talk) 15:28, 14 March 2013 (UTC)
What's wrong with those? It's relevant data. It doesn't matter whether our data will be relevant in 20 years, or 100000 years. Legoktm (talk) 15:40, 14 March 2013 (UTC)
If find it awkward to say Person xy has the property twitter-account=xyz. Also I do not understand why twitter and not -say- myspace. Why twitter and not any email-address--Svebert (talk) 15:50, 14 March 2013 (UTC)
Propose a myspace property then. I would support that too. Email address is also a valid property, but might be harder, since people tend to keep their email address private compared to say, a twitter account. It's no less valid though. Legoktm (talk) 15:54, 14 March 2013 (UTC)
how about postal address? Or GPS-coordinates of the bedroom used in the month of may?
how about color of bed sheets or favourite car manufacturer?
how about length of distance to workplace in winter when streets are icy?
Why are these proposals obviously ridiculous but not “twitter account“?
My hint: Nobody on earth would describe somebody with the property “twitter account“. If you are talking about a person with a friend who doesn't know this person, do you say: “This person has the twitter-account xyz”? You propably stick to the more objective properties like “This persons sex is female“, “She works at ...“, ”She is at age 36” etc.--Svebert (talk) 16:32, 14 March 2013 (UTC)
All the stuff you said is non-notable. Twitter accounts are added to biographies in the External links section. Emijrp (talk) 12:31, 16 March 2013 (UTC)
I don't know how much this property will be relevant in 20 years, but at the moment, I feel that this information could be useful; however, including all names and codes for personal accounts will lead to edit wars (due to poor references) and overclaimization. --Ricordisamoa16:44, 14 March 2013 (UTC)
Oppose - I do not believe Wikidata should be a repository for external links, only personal information. The problem with linking any third-party service is that these services change and some go obsolete. In addition, I fear that some living people might see this as a privacy violation (even if it technically isn't).--Jasper Deng (talk) 00:48, 15 March 2013 (UTC)
Comment Svebert, the intention of nominating only Twitter property was to check general response. If this is considered OK property, then "personal website", "facebook page", "cyclingarchives.com profile ID" (for professional cyclists), "national-football-teams.com profile ID" (for professional football players), "nhl.com profile ID" and lots of other useful resources could be added. Notability guidelines can be established (I think they exist for external links section). These properties are not useful for infoboxes (maybe website link is used), but they are used in most Wikipedias in external links section. These links could be gathered from Wikidata and displayed in every Wikipedia, just like the Phase 2 for infoboxes. Anyway, if property is found to be outdated (Twitter decides to shut down the service), technically it is very easy to remove all references to it. --Papuass (talk) 09:42, 15 March 2013 (UTC)
Oppose Wikidata is not a directory of personal information. This kind of information doesn't help to describe or to inform about the person. Snipre (talk) 12:21, 15 March 2013 (UTC)
Comment official website is already accepted? Why not to rename it something like "official sites" where to put every notable links, including Twitter? --Stryn (talk) 08:57, 16 March 2013 (UTC)
Oppose. Official website is accepted, due to the fact that it does not run on another platform (like Twitter or Facebook) and provides relatively formal information, whereas Twitter pages display more personal information about the entity. --Wylve (talk) 09:56, 16 March 2013 (UTC)
Comment many people/band don't have official websites, but official twitter/facebook/google+/myspace account. --Stryn (talk) 10:25, 16 March 2013 (UTC)
I propose not to create this property, but to use the entity's twitter profile URL as the value of the official website property only when the entity does not have an official website. Same goes to Facebook, myspace, linkedin, etc. --Wylve (talk) 06:33, 17 March 2013 (UTC)
I'd Support an "official media" property, which could include official website and social network accounts, but also magazines, television shows, etc. But I Oppose having a property for each social network. --NaBUru38 (talk) 19:17, 19 March 2013 (UTC)
Oppose per NaBUru38's reason for opposing. But something like "social media" property would be good. --Stryn (talk) 21:40, 19 March 2013 (UTC)
It doesn't have to be a social media, it can be an old-school media like an official website, radio / television show or magazine. --NaBUru38 (talk) 18:51, 20 March 2013 (UTC)
If a person or organization has a relevant public account on a social network related to whatever it is they're notable for, I could see it making sense to have that data on Wikidata. (I'm picturing someone using Wikidata to analyze Twitter text output of all people elected to X position who also have attributes X...) However, we should specify that the account has to be relevant, though I'm not sure what criteria we would need for this. We probably wouldn't, for instance, want to list the account of someone who has a Wikidata item on account of being related to someone. This needs further consideration. --Yair rand (talk) 00:29, 20 March 2013 (UTC)
Oppose Wikipedia has achieved a consensus that articles about Twitter accounts of persons/organizations are not notable for inclusion. So, how do we'd link to them from here if they don't exist and an item about those Twitter accounts cannot be created? Also, they can change of account name when they wish, so we would have to be be updating the info each and then, which will make this more trouble than benefit. And additionally, I agree with what someone said above that this would open the door to facebook-page, google-plus-page, tumblr, myspace, and many many more. — ΛΧΣ2104:40, 26 March 2013 (UTC)
Comment Bear in mind that Wikidata is not Wikipedia. It may be that other users of Wikidata would want this information to be available. Danrok (talk) 13:06, 1 April 2013 (UTC)
Comment ΛΧΣ: there is no propositon to create items about Twitter acounts, but use them as properties instead. And I do not see much difference between this proposal and already confirmed property Property:P345. --Papuass (talk) 09:14, 2 April 2013 (UTC)
Oppose There are many websites, many hosting websites, and many social networking websites and networks of them. IMDB is an old database (23 years); OpenStreetMap is a free database (and integrated in Wikipedia). Twitter is a microblog hosting and a social networking service that appeared in 2006 (7 years ago). It is popular, but is neither old, nor free or integrated with Wikipedia; how is it different from StatusNet, Diaspora etc., except that it always has the same domain name (which means the specific service can be inferred from the address)? Maybe create an item for blogs and social networks, and use with qualifiers: Wikidata:Project_chat#Property_qualifier_release_on_Wednesday. But what if people start adding e-mail addresses? --AVRS (talk) 18:18, 17 April 2013 (UTC)
Oppose Many other social media and other website should be consolidated in a common attribute like member of "Twitter" then qualifier for media id.
Support, as it is a widely used and very influential website. I have nothing against creating properties for social media but would oppose a general "social media" property, as it would make things substantially more complicated for no clear benefit. --Zolo (talk) 08:58, 2 May 2013 (UTC)
Comment How do we ascertain that added account is the original one and not spoof? because there are a ton of spoof accounts.--Vyom25 (talk) 14:17, 23 May 2013 (UTC)
Support Let's say, hypothetically, that I've created my own AI running off of Wikidata, and am giving it away for free as an app. (This is, of course, what we hope will eventually become one of the primary purposes of this database.) So, what is the average person talking into their smartphone more likely to ask my AI: "What's so-and-so's VIAF identifier?" or "What's so-and-so's Twitter handle?" It's all well and good that we're turning this project into a useful resource for librarians, statisticians, and what-not, but don't forget the Everyman! — PinkAmpers&(Je vous invite à me parler)11:19, 30 May 2013 (UTC)
Leonard Huxley has child Aldous Huxley together with Julia Arnold; Robert Anton Wilson authored Illuminatus together with Robert Shea; Serge Haroche got the Nobel Prize in Physics (in 2012) together with David J. Wineland.
The together with qualifier allows an easy way to indicate that some property or relationship is shared with someone else. This is especially useful if the meaning of the relationship is influenced by it's shared nature, e.g. in the case of parentship. Note that this qualifier is not necessarily limited to people, but seems especially useful in that context. Duesentrieb (talk) 10:46, 25 April 2013 (UTC)
Question Is it useful to have properties/qualifiers inferable from neighbouring items? If there are exceptions, could you show an example? Thanks. --AVRS (talk) 10:56, 25 April 2013 (UTC)
In theory yes, but we'll not have automatic inferred parameters on Wikidata soon, and even when we do, we still need a qualifier property to represent them. I could imagine such qualifiers being added by bot, though.
I'm not sure what kind of example you mean... maybe, if Serge Haroche has Nobel Prize (in Physics) (in 2012), and David J. Wineland also has Nobel Prize (in Physics) (in 2012), we could infer the "together with" qualifier for that... but it already needs a bit of special knowledge to decide which qualifiers need to be taken into account for this match.
Anyway, no matter whether this is going to be maintained manually, by bot, or fully automated based on rules, we need to define the property to be able to use it as a qualifier. -- Duesentrieb (talk) 12:30, 25 April 2013 (UTC)
Comment This should be listed as a generic property because it applies to more than just people, but also organizations or even other items: Bell manufactures the V-22 Osprey together with Boeing; Idaho borders Oregon together with Washington; B-17 Flying Fortress maiden flight was in 1935 together with Douglas DC-3; etc. Joshbaumgartner (talk) 09:04, 9 May 2013 (UTC)
Putting one of the property items into a qualifier is relegating it to second place where it may well be missed in a search. We should just list both parties as above, giving each equal billing. Filceolaire (talk) 20:29, 6 June 2013 (UTC)
Oppose I can't see what this property would achieve which cannot already be achieved using existing properties, qualifiers, etc. Danrok (talk) 23:23, 8 June 2013 (UTC)
Comment I would like to point out that while this property can easily be derived from existing properties, for it to be derived visibly and usably within wikidata, it must exist! It's redundant in the sense that the brother/sister relationships are redundant, since they are implied by a shared parent: they are redundant and can be derived, but they are non the less useful to have, no matter wither they are entered explicitly, maintained by bot or derived by the system itself. I think that it is useful to be able to express the notion that some property is shared in cases where the "shared-ness" is relevant (like when having children, or sharing a prize). -- Duesentrieb (talk) 20:02, 10 June 2013 (UTC)
No, usually there is no separate item for the spouse, but there may still be a brother-in-law with an item. -- Docu at 14:54, 25 April 2013 (UTC)
Wikidata:Notability: "An item is acceptable [...] if it fulfils at least one of these two goals: [...] 3. It fulfils some structural need, i.e. it is needed to make statements made in other items more useful." If there is a relevant brother-in-law, wife becomes relevant. —★PοωερZtalk14:59, 25 April 2013 (UTC)
Comment What if sources only say "X is Y's brother-in-law" and nothing more? In this case we even don't know what "brother-in-law" means, should we use "brother-in-law (sister's husband)" or "brother-in-law (spouse's brother)"? --Stevenliuyi (talk) 17:37, 25 April 2013 (UTC)
Apparently this has never been proposed. If the property is already on its way, please revert… Btw, niece would be helpful as well. Alexander Doria (talk) 22:11, 30 May 2013 (UTC)
Unique Ingredient Identifier (Q6593799): UNique Ingredient Identifier (UNII) is a non-proprietary, free, unique, unambiguous, non-semantic, alphanumeric identifier linked to a substance's molecular structure and/or descriptive information by the Substance Registration System of the Food and Drug Administration (FDA)
PubMed Health provides information for consumers and clinicians on prevention and treatment of diseases and conditions. PubMed Health is a service provided by the National Center for Biotechnology Information (NCBI) at the U.S. National Library of Medicine (NLM).
sources: we can extract these variables by bots or manually form wikipedia infoboxs or websites like google map or coordination datacenters like openstreet maps and etc.
Comments: I suggest to make separate property for these variables. I tried to collect the vaital variabel and we can descusss for others like (map_alt ,map_caption ,pushpin_map ,pushpin_label_position,pushpin_map_alt,pushpin_map_caption,coor_pinpoint,coordinates_type,coordinates_display,coordinates_footnotes,coordinates_region) in another requests
Essential parameters for degree base coordination
latd :latitude degree (Datatype:Number)
latm :latitude minute (Datatype:Number)
lats :latitude second (Datatype:Number)
longd :longitude degree (Datatype:Number)
longm :longitud minute (Datatype:Number)
longs :longitud second (Datatype:Number)
latNS :latitude direction (North or South) (Datatype:String)
longEW :longitud direction (East or West) (Datatype:String)
Comment Data entry with UTM would be a lot easier in my opinion. Two numbers instead of a lot of special characters (",',°) or multiple fields. The other values can be easily calculated from UTM. --Tobias1984 (talk) 10:41, 17 April 2013 (UTC)
"easily calculated". Well, the more technical solutions you add to this system, the fewer users will be able to use it. The threshold will be higher and higher. In some project, there is maybe only a few users with such technical skills, and they become fatigued by all requests from other users. This is simple to calculate, for those who know. More people think they know, but don't. There will be problems if a project only has the latter kind of "technically skilled" users. -- Lavallen (block) 14:22, 18 April 2013 (UTC)
I think data entry will be possible in any format. But for storage a UTM number like 23423432 is a lot simpler than 34:234'34"32 in my opinion. I also can't do the calculations in my head :) but there are a lot of converters on the internet and programs like google earth allow you to switch from one format to the other. I guess my comment was more about that UTM was still missing from the list ;). --Tobias1984 (talk) 14:32, 18 April 2013 (UTC)
I'm full agree with Tobias1984, there is no need storing six entries instead of two. I really think that these entries will mostly be imported from Wikipedia using Bots (like User:Geobot) and so there is no problems about having homogeneity in the database. I really think that is better to have one standard in a database (simplify the reuses). Beside if we multiply the entries we increase the number of typos. Otourly (talk) 16:26, 22 April 2013 (UTC)
publication date (P577): Use P577 if the accessed webpage states a date of publication (either instead of this property or together with it).
point in time (P585): "date retrieved" is redundant as P585 could easily serve this way for references. But some Wikidatans have expressed that they want a separate property for use in references to avoid any possible confusion even though that qualifiers and references are distinct things in a statement. Byrial (talk) 07:48, 9 June 2013 (UTC)
Neutral – I see no need for another redundant property, but if the community prefers that, I can live with it without problems. However they should know what they do, and the property should have a description that makes sense. What's why I made this alternative proposal for a "date retrieved" property. Byrial (talk) 07:48, 9 June 2013 (UTC)
Support, I think it is what was meant by the previous proposal, but I can only support a more precise terminology. --Zolo (talk) 21:30, 9 June 2013 (UTC)
The previous proposal is better now than before, but it still uses the word qualifier which is misleading and contrary to Wikidata's datamodel. And the motivation talks about a need. There is no need. It would be better to motivate a wish for a redundant property than to deny the redundancy. So I will keep this alternative proposal for now. Byrial (talk) 06:21, 10 June 2013 (UTC)
AH. I missed your wording for the infobox parameter section. Your wording is better and I would like to merge into the proposal above. Filceolaire (talk) 18:15, 10 June 2013 (UTC)
This proposal is hereby withdrawn by the proposer – The proposal above for the same property have been changed so the two proposals are now nearly identical, and there is no reason to keep this proposal anymore. Byrial (talk) 08:35, 12 June 2013 (UTC)
year (en)
Not done
Description
Some magazines distinguish a specific issue by "issue x of the YEAR xxxx" rather than "volume xx issue x". ( Very common for Chinese journals and general magazines)
"year" and "volume" shouldn't coexist. If there are "year" and "volume" for a specific "issue" of a magazine, use the "volume" and record the "year" ( and possible more detailed month, day) on "date of publication". --凡其Fanchy15:14, 6 June 2013 (UTC)
Or the meaning of "volume" need to be extended to "volume number". These magazines in fact regard the "year" as "volume number" to distinguish "issues". In this way the "volume" could be 1999, 2000, 2001 ... rather than 1, 2, 3, ... --凡其Fanchy15:55, 6 June 2013 (UTC)
OK, don't create this property and it is better to add a claim <volume> "no value" for magazines not using volume and a claim <volume> "unknown value" when you don't know the volume. --凡其Fanchy09:07, 7 June 2013 (UTC)
Subdivisions / /
Description: Number of subdivisions of varios types (neigborhoods for municipalities)
Datatype: value, item
Links:
Infobox parameter example:
Comments: In Czech republic every municipality have in infobox numbers of three types of subdivisions (villages, cadastral areas and statistical parts (often are all similar)), might be with links too.
Comments: useful for the divisions which have a seat which is specifically not referred to as "capital" (e.g., in Russia). Alternatively, we might combine the capital property with this into a generic "seat" and create another property called "seat type".—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:56 (UTC)
Thanks for the example. I prefer a generic property, because otherwise we may also need properties like "county seat" for US, "county town" for UK, "chef-lieu" for various countries, and many more properties for many different kinds of seats of government in different countries. --Stevenliuyi (talk) 21:20, 8 March 2013 (UTC)
Well, the intent of my example was more to illustrate that there are cases where one generic moniker is not going to work because multiple terms are used within the context of the same infobox (as opposed to within the context of different countries). I feel that the best solution is to have both a "seat type" and a "seat" property; this way one can be easily customize for any country. But while that's unavailable, creating a generic property (be it called "seat" or "administrative center", but definitely not "capital") and allowing it to hold multiple values is probably the best solution.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 21:30 (UTC)
I agree that we need to specify the "seat type" if we use a generic "seat" property (I have no idea how we should call it), but I think it's better to let the "seat type" be a qualifier (when it's available) of the "seat" property, instead of creating two separate properties. --Stevenliuyi (talk) 22:02, 8 March 2013 (UTC)
I, too, agree that it'd better be a qualifier... it's just that we don't know when those are going to be implemented! By the looks of it Phase II might very well go live before that happens... Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 22:21 (UTC)
Sure. I have no problem with creating a temporary "seat type" property, since it's easy for bots to transfer the data when qualifiers are available. --Stevenliuyi (talk) 22:35, 8 March 2013 (UTC)
Oppose I would prefer that the existing capital cover this. While the exact name 'capital' may not be fully accurate itself in all situations, the description provides coverage for administrative seats. If the label is the problem, then it should be altered to broaden its coverage. If we have a different property for every different local way of considering its seat, it will be messy and hard to use for clients. The label we use won't matter to the template querying it, as client-side, an appropriate title can be provided. If it is really notable, a qualifier can be used to give the official 'title' of the seat. Joshbaumgartner (talk) 06:06, 16 May 2013 (UTC)
Oppose We have capital property, which description says that it can be seat of government of state or administrative division.--Ahonc (talk) 11:31, 17 May 2013 (UTC)
Support I think the role of translator is usually quite clear in any work and having a property "Translator" will convey useful information. Another option could be "secondary author", but in a work with several "secondary authors", then it would be unclear which one took the role of translator.--Micru (talk) 19:46, 2 June 2013 (UTC)
Stevenliuyi is right, for instance let's take this item: The Hundred-Year-Old Man Who Climbed Out the Window and Disappeared (Q3793400). It represents a work written by Jonas Jonasson in Swedish language. This book has different editions, some of them are in Swedish, some of them in other languages, including English. Usually there is a person called "translator" that takes the responsibility of translating from one language into another. So for that general item there will be linked items for each edition, the item representing the Chinese edition will have as translator "Zhaoyan Fan", the item representing the English edition will have as translator "Rod Bradbury", for the Italian edition the translator is "Margherita Podestà Heir". Later on, each language Wikipedia will use in their book infobox the main work item (containing the author, title, etc), and the edition item (containing the details regarding the translated edition, like ISBN, publisher, and the translator) so the readers have all the information that it is relevant in their language. Hopefully now it is more clear how important this property is.--Micru (talk) 15:57, 6 June 2013 (UTC)
Discussion on translations
The following discussion has been archived for the following reasons: translations will be stored as a separate item (see: guidelines for sources). In the light of this new circumstances I will ask the participants to share their opinion again on this property.--Micru (talk) 19:46, 2 June 2013 (UTC)
Archived discussion (relative to the separation of items)
The can be done two ways. For instance, either as a property of the original work:
QXX Hamlet, a play by Shakespeare. Property: French translator, François Victor Hugo (1865), Yves Bonnefoy (1958)
or in a separate item:
QXY Hamlet, translation of Shakespeare's play by François-Victor Hugo.
The latter sounds better to me, as it will be easier to add properies about the translation itself (date, publisher, isbn, etc.) --Zolo (talk) 07:57, 3 February 2013 (UTC)
This is important (see my Comments III above), because as I understand it we are confusing different levels. If we are willing to have a wikidata page per work (eg. Hamlet), we need to set all the properties minding all the manifestations and expressions of that work (plays, books, translations movies). We we prefer to have different Wikidata pages (Hamlet the play, Hamlet the movie(s), etc.) we'll have other properties (or, at least, same properties with different syntaxes, I suppose). Furthermore, if we set the Translator property like this we should be coherent for all the other properties.
Anyway, Support for the latter form also for me, it's easier and more wiki-like to have different items/pages. We just need a way (ie properties) to link these pages together. --Aubrey (talk) 09:45, 19 February 2013 (UTC)
Creating a separate item for each translation will, I believe, put Wikidata out of synch with WikiPedia for no good reason since we can deal with this by having a statement for each translation, just as we have for each edition. Translator would be a qualifier for the statement describing the translation. Filceolaire (talk) 11:56, 6 April 2013 (UTC)
Separate items for translations raises some issues, but I think it is a better long-term solution. An important usecase would be en:Template:Cite book. If we have an item for each edition, we would just need the item's ID to cite it. By contrast, if several editions are listed in the same property of the same items, choosing the right one would be much more complicated and brittle. I think a similar case could be made for other uses, both by Wikipedias or external clients. --Zolo (talk) 12:24, 6 April 2013 (UTC)
Comment apparently, the datatype should be string, as X and Y are not compatible with a number datatype. --Zolo (talk) 18:07, 18 June 2013 (UTC).
Comment 'Number' is a problematic datatype for the reasons cited above. However, 'string' isn't ideal either. Chromosomes are distinct objects that have properties like 'accession', 'length', etc. and should thus be represented as 'items'. I suggest changing the 'datatype' to 'item' and having claims of the form RELN (Q414043)GenLoc_chrhuman chromosome 7 (Q657319). Emw (talk) 01:31, 27 June 2013 (UTC)
Comment In addition to a species qualifier, when defining a gene's location I think we also need to include qualifiers for:
Which genome assembly the coordinates are derived from (e.g. GRCh37/hg19, NCBI36/hg18, etc).
The accession of the sequence (including a version, if applicable). This would make it unambiguous which gene variant or alternative placement is being used.
The same information would be needed in GenLoc_chr and GenLoc_end, since all three properties would be needed to define a chromosome coordinate. Emw (talk) 04:37, 19 June 2013 (UTC)
It's very useful, but should we create sub-properties for doing this? At the time it's not possible (I think) --Viscontinotalk 10:07, 2 March 2013 (UTC)
Comment 1. Since it's an item, we should create an article for each song. 2. We should add qualifiers such as the order number. --Viscontino (talk) 11:20, 19 April 2013 (UTC)
Support. I'm new to wikidata, but I would sure like this. It would be nice if it could be made in such a way that we have (or could later add) a link to the "canonical" version of the song. For example, there are many versions of Dream A Little Dream. And one artist might have several versions of a songs (e.g. live album and studio album). Somewhat related, it would also be nice with a way to say if a song samples a different song (i.e uses a clip of a song to make a new song). —Bajsejohannes (talk) 05:40, 30 April 2013 (UTC)
Don't understand to what this property should link? To an item linked to Wikipedia pages containing a tracklist? Not useful. To all Tracks? Maybe useful but an item has to be created for every song. Don't know what you mean by "Every track must have…" that wouldn't be part of the properties value. -- MichaelSchoenitzer (talk) 23:59, 10 May 2013 (UTC)
Oppose - Oppose the datatype. Track names don't have to be translated. A property called "tracks" could hold a string for each song with a qualifier for the number on the album. --Tobias1984 (talk) 12:39, 24 May 2013 (UTC)
Comment It's not about the point to translate a track name, it's about the point to have the possibility to enter more information to a track. --Nightwish62 (talk) 15:53, 30 June 2013 (UTC)
group
Not done
Description
the item is part of a group of the same kind of items as itself.
This property was briefly discussed at Wikidata:Properties for deletion#Property:P265. If it is created it will obsolete several other properties which should be deleted. (4 properties which can be replaced are mentioned in the examples section above, and there may be more). "Group" is clearly redundant with part of (P361), but it will be easier to use in infoboxes than P361 because of the constraint on the value type. Byrial (talk) 09:32, 10 June 2013 (UTC)
This property is similar to instance of (P31), but is used when the item is not one, but several instances of a class. The subject should not be a list of instances selected by some criteria (use is a list of (P360) for that), but should be about a few instances described in detail. If there also is separate items for the contained instances these can be indicated with has part(s) (P527). Byrial (talk) 10:00, 18 June 2013 (UTC)
Oppose This seems redundant with subclass of (P279). A class is a type, which is a set of instances and the properties that those instances share. Bonnie and Clyde (Q219937) is fundamentally a set of (two) instances and the properties that those instances share. It's clearly an unusual example of a class, but in terms of ontology components, 'Bonnie and Clyde' is a class nonetheless.
An instance of any class is also a subset with one member of the class, and thus a subclass by that argumentation. So can we expect a deletion proposal for instance of (P31)? The problem with this is that Bonnie and Clyde (Q219937) do not share any properties that other persons do not have, except for being Bonnie and Clyde. And the same is valid for each of them. Byrial (talk) 12:10, 18 June 2013 (UTC)
Insofar as set theory applies to ontology components like instances and classes, instance of (P31) (rdf:type) corresponds to (element of) and subclass of (P279) (rdfs:subClassOf) corresponds to (subset of). So I don't see how it's valid to say that all instances of a class are sets. Is that supported by the description logics that underlay OWL DL, or the basis of some other W3C recommendation for structured data?
I also still don't see how 'instances of' would be fundamentally different than 'subclass of'. P31 and P279 are based on W3C recommendations, are implemented throughout the Semantic Web, have support in ontology toolsets, and have a substantial body of literature about them. To my knowledge, 'instances of' does not. If it does, which would presumably mean it's not redundant with subclass of (P279), then please point me to where I can read more about that. Emw (talk) 04:07, 19 June 2013 (UTC)
Comment "named after" is applicable to a word or a name, not to a language. Actually "mercury" was also called "quicksilver" in English. --Zolo (talk) 12:12, 19 April 2013 (UTC)
Comment The program name "Jitsi" comes from a Bulgarian word for wires, but the name "Jitsi" itself probably cannot be called Bulgarian-specific. So one side of the "named after" statement is language-specific, but the other is not… --AVRS (talk) 12:23, 19 April 2013 (UTC)
Comment – There is still the problem that it not refers to the item, but to names for it. If a language have different names of different origin for an item, which of the names does the statement apply to? Examples where Danish have synonyms are some elements (like oxygen), plants (like Chamaecyparis lawsoniana), animals (like Common eland) and more. Byrial (talk) 13:58, 19 April 2013 (UTC)
This raises a question about the property itself, or about it's use. I can imagine multiple "named after" statement for one item even with the same language qualifier, especially when distinguished through other qualifiers (time etc.). I would understand a statement like this like: "There is some name for item A which is derived from some name of item B." Also, we can remove the "named after" property from the list. But if we'll have it, we'll definitely need a language qualifier for it.--83.240.94.18 =Šlomo (talk) 18:26, 25 April 2013 (UTC)
That's the beauty of qualifiers. They apply to one statement. Each 'named after' statement has it's own language qualifier that applies to that statement. Filceolaire (talk) 21:11, 6 June 2013 (UTC)
This property would give specific clarity as to the conficts that the subject has fought in. The property for the branch of their military service exists already military branch. This property would serve the purpose of denoting which specific events the subject has participated in while a member of their military force. Presentime (talk) 20:14, 20 April 2013 (UTC)
Comment This property seems useful! But I would tweak its title to simply 'fought in', and change the 'allowed values' field to be 'conflicts'. Conflicts are a subclass of event, and it's best for the 'allowed values' field to be as precise as possible. Emw (talk) 20:23, 20 April 2013 (UTC)
Comment - If somebody fought in the Battle of Gondar and that battle is a "subclass of = World War 2" then the qualifier would be redundant? --Tobias1984 (talk) 10:26, 8 May 2013 (UTC)
Yes, I think the battle would be enough, and battles are "part of" war, rather than "subclass of". See Q83224 Battle of Hastings. Danrok (talk) 02:44, 18 May 2013 (UTC)
Sorry but property member of sports team doesn't imply that the sportman has to play. I don't know if my English is too poor but draft is for me integration in a team, after if you play or not is something else. By being drafted you can play as member of the team. Snipre (talk) 17:36, 9 April 2013 (UTC)
Comment Very often a player will be drafted by a Major League Baseball team and never get close to even being on that team's roster. They may be traded or fail to develop long before reaching that point, or even refuse to sign with the organization at all. This is still relevant information to know though, so a separate property for the drafting organization is valid and distinct from a property for teams a player was a member of. Joshbaumgartner (talk) 08:32, 9 May 2013 (UTC)
Support, though it looks like the infobox parameter is draft_team. The date of the draft could be added as a qualifier when available. Superm401 - Talk01:00, 6 April 2013 (UTC)
Relevant to what? It seems like a well-defined concept that can be easily sourced. I see no reason to exclude it. Further, this is the kind of thing a biography would mention whether or not they actually played for the team. Superm401 - Talk04:24, 17 April 2013 (UTC)
Support this is a very useful piece of information when learning more about a player's career path, as well as studying a team's player development and scouting history. Joshbaumgartner (talk) 08:32, 9 May 2013 (UTC)
SupportComment hg19 (i.e. GRCh37) is a genome assembly, not a 'database assembly' or 'gene assembly'. I would suggest calling this qualifier "GenLoc_assembly" and updating the documentation 'description' field. Emw (talk) 03:28, 21 June 2013 (UTC)
Thanks! Another suggestion: to help avoid confusion over aliases for the genome assembly (GRCh37 vs. hg19 vs. ...), it seems like it'd be a good idea to change the "datatype" of this property from "string" to "item". Wikidata items for the genome assemblies could be created as needed. The set of relevant genome assemblies is small, so this doesn't seem like it would be a problem. Another benefit of using an "item" datatype is the assembly could also be linked to an accession. Emw (talk) 02:05, 22 June 2013 (UTC)
Handling aliases may not be a problem.I am not aware about whether there would be a need to represent assemblies as wikidata items. I will run this through the task force for some more clarification. --Chinmay26 (talk) 10:43, 22 June 2013 (UTC)
A more compelling reason to use 'item' instead of 'string' is that it would enable properties about those assemblies to be easily organized. For example, assemblies have accessions. Having this property point to an item representing an assembly rather than just a string would allow sequences to be queried by the accession of the assembly they're associated with. Assemblies also have other relevant properties, like length (i.e. the length of an organism's genome), associated chromosomes, etc. Emw (talk) 01:22, 27 June 2013 (UTC)
I think in the long term, assemblies as items make a lot of sense. However, I hesitate here because of the practicalities of Chinmay26's GSoC project. His goal of course is to model genes in sufficient detail so that the Wikipedia templates can draw most (if not all) of their content from Wikipedia. I don't want Chinmay to get too caught up in modeling all of biology correctly and never get to coding. Emw, what do you think? Can we leave this one as a string for now in the name of simplicity, and move toward assemblies as items later? Cheers, Andrew Su (talk) 20:09, 27 June 2013 (UTC)
Will any of the ported PBB template parameters use properties with an item datatype? If not, then it seems that many of the properties put forward for the GSoC work will need to be remapped to item-based properties in the long term. (And how will the kind of EC class discussed here be handled?) With this particular property, it seems claims would involve only two items: either the item for the human assembly or the item for the mouse assembly.
If handling item-based properties would be a big impediment to the progress of the GSoC project, then I agree it's better to have string-based claims than no claims at all. If that's the case, I agree it'd make sense to use strings now and update these claims to use item-based properties later. Emw (talk) 01:21, 28 June 2013 (UTC)
Good questions, as usual. I think the majority of the PBB parameters are modeled as strings (current first-pass list: HGNCid , Symbol , AltSymbols, Homologene, EntrezGene , Ensembl, RefseqmRNA(qualifier to protein ID) , GenLoc_db /start/chr , GeneAtlas_image, species , Uniprot ID). But on second thought, it probably doesn't matter from Chinmay's point of view if hg19 is an item rather than a string. I think as long as we let him create that as a bare-bones item and leave populating statements on that item to others (accessions, length, etc.), then that won't hold him up at all. I was getting worried that Chinmay would have to do that, but of course that's not strictly necessary just for changing the data type here. Bottom line, I'm happy with changing the data type to item. Anyone else (especially Chinmay) have any objection? Cheers, Andrew Su (talk) 07:11, 28 June 2013 (UTC)
the Enzyme Commission (EC)-based accepted name of any enzyme classifications of the protein or RNA molecule. May be the same as the name of an item about a protein or RNA molecule, but should only link from protein or RNA items to items that are a subclass of enzyme (Q8047) and have an EC enzyme number (P591) value. Should not be used for claims in enzyme items.
How should statements using this property be sourced?
How should enzyme classes that have no "full" name be labeled? For example, according to http://www.chem.qmul.ac.uk/iubmb/enzyme/EC2/1/, EC 2.1 has the name "Transferring one-carbon groups". Should such enzyme classes be labeled by taking the next-highest EC classes name (e.g. EC 2, "transferase") and prepending it to the "incomplete" name to give labels like "transferases transferring one-carbon groups"? The official EC name could be an alias of the item in these cases.
Support I agree that the edge cases mentioned above need some thought and discussion, but I'd suggest not holding up the property proposal before those are resolved. One way or another, we're going to need this property... Cheers, Andrew Su (talk) 17:47, 29 June 2013 (UTC)
Support – I took the liberty of adding EC-IUBMB as the source. In addition, the "name" parameter of the enzyme infobox should be set to the EC accepted name, hence this parameter should be appropriate for this property. Boghog (talk) 00:02, 30 June 2013 (UTC)
I agree that the names themselves should come from EC-IUBMB (and occasionally adjusted per the second question above?), but what source should be used to support the assignments of those EC names to gene products? For example, what source supports the claim that reelin is a serine endopeptidase (EC 3.4.21)? And when the EC name differs from the Wikipedia article name -- e.g. with the EC name serine endopeptidase corresponding to the Wikidata item Q420032 (currently labeled 'serine protease') -- should the Wikidata item label change, or should the EC name be added as an alias, or what? Emw (talk) 03:21, 30 June 2013 (UTC)
I think UniProt should the ultimate source of the annotation (e.g., [1]). For the latter question, I think the Wikipedia article should stay at "Serine protease" (because that's how most scientists would probably refer to it), and the Wikidata label should be "serine endopeptidase" (because that's the official label). And then we can use redirects and aliases to make sure either search resolves correctly on both ends. (The Wikipedia redirect is already in place.) My two cents... Cheers, Andrew Su (talk) 04:09, 30 June 2013 (UTC)
Great, having UniProt as the source for these claims seems good to me. If the EC classification for a gene product can be supported by simply referring to a URL of the formhttp://www.uniprot.org/uniprot/<UniProt ID>, then that seems fairly automatable, since virtually all protein items will have a UniProt ID added as part of the GSoC project. I don't think such sourcing should be necessary for the GSoC project, but is there some place to add this task to a backlog so it doesn't get forgotten?
Regarding labels, I think it would be reasonable to change the enzyme Wikidata item's label to the EC accepted name when the Wikipedia article name differs. In these cases, I imagine we agree that the Wikipedia article name should be kept as an alias on the Wikidata item. I've mocked up serine endopeptidase (Q420032) as an example. Emw (talk) 04:38, 30 June 2013 (UTC)
I agree that UniProt would be a good source for the protein → enzyme mappings. In addition, UniProt can supply a list of all proteins with a given EC number/accepted name (see for examplehuman serine endopeptidases) if that is needed. Boghog (talk) 09:43, 30 June 2013 (UTC)
PubChem (Q278487): PubChem is a database of chemical molecules and their activities in biological assays. Each compound in Pubchem is identified by a unique Compound Identifier (CID) accession number.
I haven't found this property in an infobox as yet, still I think it's a necessary property to describe an event, and can be useful for queries and generating lists (as soon as this functionality is available). The property would have several values in many cases; like in Eurovision Song Contest 2013, e.g., this would be not only the EBU, but also Sveriges Television. It's the same with international sports events that are not only organized by the international body, but (usually for the most part) by local organizations or committees.--Kompakt (talk) 07:37, 20 May 2013 (UTC)
I agree with the general idea. But how would it work exactly? Events, especially large events, are often organised by more than one entity, with each taking control of different aspects of the event. Danrok (talk) 22:54, 8 June 2013 (UTC)
You're right, I think we can simply add all organizers to the property. For Eurovision 2013, e.g., we'd add both the EBU and Sveriges Television.--Kompakt (talk) 16:00, 11 June 2013 (UTC)
Kyoto Encyclopedia of Genes and Genomes (Q909442): collection of online databases dealing with genomes, enzymatic pathways, and biological chemicals. The PATHWAY database records networks of molecular interactions in the cells, and variants of them specific to particular organisms. Since July 2011, KEGG switched to a subscription model, and access via FTP is no longer free.
is a classification method for primary care encounters. It allows for the classification of the patient’s reason for encounter (RFE), the problems/diagnosis managed, primary or general health care interventions, and the ordering of the data of the primary care session in an episode of care structure. It was developed by the WONCA International Classification Committee (WICC), and was first published in 1987 by Oxford University Press (OUP) (from: en:International_Classification_of_Primary_Care) See also: en:ICPC-2_PLUS
Comment - not sure what we should do with the second field that describes the entry. It could be a separate string or multilingual string? --Tobias1984 (talk) 16:50, 1 June 2013 (UTC)
The MeSH code is the structure of the classification. MeSH ID is the ID that each MeSH Code has in the database. The diseases infobox included the ID rather than the code. I think it would be better to store the code and put the database ID into the source information (so this is actually more of a proposal to change Property:P486. --Tobias1984 (talk) 10:17, 9 May 2013 (UTC)
I suggest to use only one parameter from MeSH DB: the code or the ID but not both. Put the suggestion in the talk page of the property and try to contact the contributors who supported the initial property to see what is the best solution Snipre (talk) 09:47, 12 May 2013 (UTC)
Weak support Because I have no background knowlenge about this only weak support. This property can be used in w:en:List of MeSH codes and subpages. But we also need the MeSH ID to link to a special medicine term because diseases can appear in different regions of the hierarchy. --Pyfisch (talk) 16:37, 12 May 2013 (UTC)
Definitely the new, the old one only exist anymore as redirects. Also, for many diseases multiple emedicine pages exist, how is this dealt with? --Wouterstomp (talk) 19:00, 1 June 2013 (UTC)
We have that problem with many pages on Wikipedia and items on Wikidata that they can have multiple entries in other databases. Currently the "infobox disease" just represents them as a list without any qualifiers. If you can think of a way on how we could improve this we could start a discussion at Wikidata:Medicine_task_force. --Tobias1984 (talk) 19:17, 1 June 2013 (UTC)
Support: Required for German Wikipedia's crusade to have reputable secondary sources on every chemical safety information provided. Also useful for other Wikipedias that show EU warning labels in their chemboxes. Matthias M. (talk) 20:52, 24 June 2013 (UTC)
Comment - Can this be an item datatype? We can create items for e.g. "lipoprotein particle receptor binding". This will reduce the amount of translation and I'm sure that these processes can hold plenty of statements of their own. Some of them might already have Wiki articles. --Tobias1984 (talk) 18:51, 2 July 2013 (UTC)
Exactly how will claims involving this property be sourced? I don't think it's critical to provide sources in the GSoC project (though it would be very nice), but I think we should establish how GO claims will eventually be sourced while everyone's thinking about GO properties.
Exactly how will claims involving this property be sourced? I don't think it's critical to provide sources in the GSoC project (though it would be very nice), but I think we should establish how GO claims will eventually be sourced while everyone's thinking about GO properties.
Exactly how will claims involving this property be sourced? I don't think it's critical to provide sources in the GSoC project (though it would be very nice), but I think we should establish how GO claims will eventually be sourced while everyone's thinking about GO properties.
ChEBI (Q902623): Chemical Entities of Biological Interest, also known as ChEBI, is a database and ontology of molecular entities focused on 'small' chemical compounds, that is part of the Open Biomedical Ontologies effort.
Support. We should probably encourage (and maybe require) this property to be used with a P89 (P89) qualifier, to enable easier unambiguous statements when orthologs for multiple species are made with this property. Emw (talk) 05:23, 10 July 2013 (UTC)
Minor comment: Would you mind renaming it to "NCBI Taxon ID" or similar? Each taxonomy database defines its own "Taxonomy ID". See for example [2]. — Felix Reimann (talk) 14:03, 4 July 2013 (UTC)
SupportWait I think this property description should be modified to allow it to be used on the gene product encoded by the gene, which can be either a protein or an RNA molecule. Consider for example HOTAIR, which encodes an ncRNA molecule. Emw (talk) 05:16, 10 July 2013 (UTC)
I was editing Q5788570, and wanted to enter that it is a disease of birds, in fact of galliformes. There does not seem to be a property for this (or indeed an infobox in enwiki). I haven't found a really good name for the property, though ColinFine (talk) 21:35, 16 June 2013 (UTC)
Support This property seems useful. A few things could be adjusted in the documentation template:
I would also change the label to simply 'afflicts'. "Gout afflicts humans" is much more natural than "Gout disease afflicts humans". The 'disease afflicts' label is putting the range constraint in the label, when it's enough to have it in the range field of documentation template (i.e. "allowed values"). Emw (talk) 00:18, 17 June 2013 (UTC)
Reply from proposer: thanks for the comments.
I didn't realise that the name was supposed to be read directly as part of an English sentence: in that case, "Afflicts" is probably the best we'll get.
I'd change the description to "type of organism which this medical condition afflicts" ("disease" is too narrow, I think).
I put "term" in because the comment in the template I copied says "type of items that may have this property. Mention main types (person, place, organization, event, creative work, term)". I think you're saying that this instruction is wrong.
I don't see where in the template there is a place so specify that the Q1 should be a disease or medical condition. Am I missing something? --ColinFine (talk) 15:49, 17 June 2013 (UTC)
Comment I have updated the proposal according to the comments above: changed the name and description, and added the organ as a possible target. --ColinFine (talk) 16:34, 9 July 2013 (UTC)
Comment I added the organ according to Tobias' suggestion, but I see that he has proposed a separate property for this, so I have removed it from "afflicts" again. --ColinFine (talk) 01:00, 12 July 2013 (UTC)
Comment - I also propose to create the 230 space groups as "Space group 1" through "Space group 230". The other notations could be put into the aliases because they require special letters to be non-ambiguous which are not available for the name (horizontal bars above letters and subscript). --Tobias1984 (talk) 08:25, 20 May 2013 (UTC)
Comment - In theory we could say that "Albite" is "space group 2" and because space group 2 has the crystal class "pinacoidal" and the crystal system "triclinic", those two things could be queried. So each mineral would just get one statement, if we don't want any redundancies. --Tobias1984 (talk) 16:31, 20 May 2013 (UTC)
:Oppose to the current solution of "space group #" items. The best datatype is string with value numbers between 1 and 230. Later when complex formulas will be possible we can change numbers by the formulas. Snipre (talk) 18:34, 23 May 2013 (UTC)
Comment - I have thought about this for some time and I think we need those 230 space group items. (1) We need them to make the symmetrical classification complete. (2) Space groups have many different string designations (one string would be insufficient) (3) They have different physical properties that can't be stored with other items (e.g. phyisical, chemical, spectroscopy, deformation, magnetic, (super)conductor). (4) some already have their own commons category (5) they can link to each other by common symmetry elements. --Tobias1984 (talk) 18:34, 24 May 2013 (UTC)
Is it possible to have other label than "space group #" ? Something a little more explicit. Just a question. Snipre (talk) 23:52, 4 June 2013 (UTC)
The problem is that the other names of the space groups are full of symbols that we can't use in the labels (yet). --Tobias1984 (talk) 06:07, 5 June 2013 (UTC)
I know about the symbols but it is just to be sure that we can't use a term even scientific and difficult to understand but which is a little more descriptive than space group 1.Snipre (talk) 11:16, 5 June 2013 (UTC)
I really can't think of any other way to name the space groups. Apart from the 7 crystal systems I don't find any of the symmetry terms particular descriptive. Everybody knows what cubic symmetry is about, but when I read about a point group like "ditrigonal-scalahedral" I always have to look at a picture or the Hermann-Mauguin notation to know what it looks like. The space groups to my knowledge don't have any names, but those would be very long and equally non-descriptive. I did take a look at how WolframAlpha handles this. A search for space group 210 returns the correct space group. But searching for the other notations which can't be inputted unambiguously returns weird results. --Tobias1984 (talk) 11:37, 5 June 2013 (UTC)
Question: what to do with those who are in multiple spacegroups? There are two forms of Tin, e.g., water can be crystallised in several groups, other compounds crystallise depending on the solvents or circumstances in different ways. Can a record link to multiple 'data'? --Beetstra (talk) 13:05, 24 June 2013 (UTC)
Single items having properties that can have multiple values is a general problem of Wikidata and propably any database. We just have to find a good solution for items we don't want to split or find out which items we should split into multiple items. Probably we need a qualifier for the symmetry properties that says "valid for = cubic phase" or "valid for = iron rich phase". A similar question would be, if chirals should have separate items. --Tobias1984 (talk) 15:21, 2 July 2013 (UTC)
Comment I see that the German de:Vorlage:Infobox_Mineral has a target for this, however most of the English chemistry pages use en:Template:Chemboxwhich doesn't currently have a dedicated option for space group. actually strike that, it does but it's rarely used en:Template:Chembox_SpaceGroup. The strucutre is noramlly described in the text - is that likely to be a problem? Also does this mean that we'll need to make 230 new pages on each space group?Project Osprey (talk) 13:35, 24 June 2013 (UTC)
230 items are not very much and they will ensure that we keep translation to a minimum. Also the 230 symmetry groups have many properties themselves. So we need to create the items anyway. I don't know if a bot can gather this information from a text. Otherwise we just have to try to import this information from a crystallographic database. --Tobias1984 (talk) 15:21, 2 July 2013 (UTC)
This property is needed for the GSoC project to put Gene Wiki infobox data onto Wikidata. The schedule here notes that deployment of Wikidata work onto Gene Wiki articles is intended to begin on July 20 -- three days from now. Given that RFCs can take several months to close and Chinmay's project depends on being able to put Gene Atlas image data into Wikidata properties, I propose that we not wait for the linked RFC to resolve itself and, absent a specific alternative for how this property should behave, work with this property as it's proposed above. Determining how image annotation should work on Wikidata is important, but that wider discussion should not block the GSoC project. Emw (talk) 02:43, 17 July 2013 (UTC)
Sometimes there is only 1 genus in family (for example). In such cases Wikipedia have 1 article for both of them, and the taxonbox infobox shows both the family and the genus in bold + taxonom author. I think that in Wikidata should handle such cases by creating seperate entity for the family, and declaring with some property that it is monotypic. Currently boolean data type isn'tsupported, but once it would... Eran (talk) 20:41, 26 April 2013 (UTC)
As long as the different ranks are in fact one and the same taxon, I am not thrilled about the prospect of creating separate entities for it. That would be like having one item for Germany and a different item for Deutschland. I think it would be better to list all ranks, all taxon names, and all authors in one item, and separate them with qualifiers. But first we'd have to agree on a standard for that. -Soulkeeper (talk) 14:35, 10 May 2013 (UTC)
"list all ranks, all taxon names, and all authors in one item" - but all the taxon ranks properties expect entity - so for a monotypic species, do you expect to define itself as both genus and species? (e.g: in Q30847 set genus and species to be Q30847 (and not a seperate entity for the genus?)
Comment I would suggest naming this to something like "times bigger than" and then have the datatype as an Item that defines how much does the subject have to be multiplied to get the object in it's qualifier. So a centimeter would have meter with a qualifier 100. And meter could have centimeter with a qualifier 0.01. Janjko (talk) 16:48, 19 March 2013 (UTC)
I think a more simple solution would be "SI equivalent" (or whatever label also applieas to nanosedond). "nanosecond. SI equivalent: 10^-9 s", "mile. SI equivalent: 1609 m".--Zolo (talk) 16:58, 19 March 2013 (UTC)
Oppose Treat 'nanosecond' like a physical constant with value>0.0001 and SI units>seconds or better yet wait to see if we can have a datatype with both value and units. Filceolaire (talk) 19:16, 16 May 2013 (UTC)
halite = {001} + Qualifier = good OR: halite = good cleaveability + Qualifier = {001}; {001} meaning any miller indices of cubic planes (100, 010, 001)
Would "string" be the more appropriate datatype then. I don't know if items for Miller indices would be a good idea. --Tobias1984 (talk) 07:03, 25 May 2013 (UTC)
„The legitimate or illegitimate, previously published name on which a replacement name (avowed substitute, nomen novum) is based.“ (see ICN-Glossary and ICN-Art. 6.11)
four-digit numbers that identify hazardous substances, and articles (such as explosives, flammable liquids, toxic substances, etc.) in the framework of international transport
Clearly, something needs to be done about author citations. Most likely the best thing would be a text field, as in the "description", as there are many permutations (see here). However if an itemized data structure is desired the following will go a long way:
Andinobates daleswansoni (Rueda-Almonacid, Rada, Sánchez-Pacheco, Velásquez-Álvarez, and Quevedo-Gil, 2006)
[ animal ]
basionym author1 = Rueda-Almonacid
basionym author2 = Rada
basionym author3 = Sánchez-Pacheco
basionym author4 = Velásquez-Álvarez
basionym author5 = Quevedo-Gil
basionym year = 2006
[ Note no "valid author" as the zoological Code omits the author(s) of the combination ]
Lithocarpus polystachyus (Wall. ex A. DC.) Rehder (1919)
[plant]
basionym ex-author1 = Wall.
basionym author1 = A.DC.
valid author = Rehder
valid year = (1919)
Gentianales Juss. ex Bercht. & J.Presl (1820)
[plant]
valid ex-author1 = Juss.
valid author1 = Bercht.
valid author2 = J.Presl
valid year = (1820)
Bacillus subtilis (Ehrenberg 1835) Cohn 1872
[ prokaryote ]
basionym author1 = Ehrenberg
basionym year = 1835
valid author1 = Cohn
valid year = 1872
But most likely, very many users will think this is too hard to understand, and will get tangled in it. Safest is a normal text field. - Brya (talk) 16:53, 9 July 2013 (UTC)
Support must needed property. --Nizil Shah (talk) 20:39, 8 February 2013 (UTC)
resolved, http://scully.cfa.harvard.edu/cgi-bin/showcitation.cgi?num=005002 can now be shortened and hotlinked with http://ricordisamoa.tk/mpc/005002! --Ricordisamoa 23:25, 26 May 2013 (UTC)
Oppose
Comment only current captain or every captains in the team history? --Stryn (talk) 09:04, 16 March 2013 (UTC)
Question - (1) Does a university in Bejing really have an English motto? (2) How will translations be available in monolingual-texts? --Tobias1984 (talk) 16:11, 8 June 2013 (UTC)
Wait This is better accomplished with a date datatype, and 'from/start' and 'to/end' properties will be amongst the first date properties available. Joshbaumgartner (talk) 10:09, 9 May 2013 (UTC)
Neutral – I see no need for another redundant property, but if the community prefers that, I can live with it without problems. However they should know what they do, and the property should have a description that makes sense. What's why I made this alternative proposal for a "date retrieved" property. Byrial (talk) 07:48, 9 June 2013 (UTC)
Strong support. --Beetstra (talk) 13:05, 24 June 2013 (UTC)
Weak support Because I have no background knowlenge about this only weak support. This property can be used in w:en:List of MeSH codes and subpages. But we also need the MeSH ID to link to a special medicine term because diseases can appear in different regions of the hierarchy. --Pyfisch (talk) 16:37, 12 May 2013 (UTC)