Wikidata:Property proposal/Archive/17
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
court case of
Description | the subject is a court case that was or is being handled and/or decided by the object, a judicial body |
---|---|
Data type | Item |
Template parameter | "court" in en:Template:Infobox court case |
Example | Sample: Loving v. Virginia (Q1345835) => Supreme Court of the United States (Q11201) |
Proposed by | SPQRobin (talk) 01:22, 8 September 2013 (UTC) |
- Discussion
Not sure about the wording of the property (maybe just "court"?). Also, should we allow multiple values for cases that have previously been handled by a lower court? SPQRobin (talk) 01:22, 8 September 2013 (UTC)
- All properties allow multiple values. Using multiple values as you have commented seems appropriate. Filceolaire (talk) 14:35, 9 September 2013 (UTC)
- I think the right phrase in formal speech is "the case was argued before the Court of..., House of..., etc.". Danrok (talk) 00:33, 9 September 2013 (UTC)
- Oppose Use author property: Loving v. Virginia (Q1345835) is a legal text defined by the Supreme Court of the United States (Q11201). No need of specific property. Snipre (talk) 19:56, 9 September 2013 (UTC)
- A court case is not just a text, in the first place it's a legally binding decision following arguments in court, whereas "author" is rather used for creative works written by a person. So I'd prefer to have a separate property. But if there's consensus to use the author property, I'm fine with that. SPQRobin (talk) 21:53, 10 September 2013 (UTC)
- The info box for a court case would include lots of information - see the info box on en:Loving v. Virginia
- Have you thought through the best way to record all of this data into wikidata? I would be more inclined to vote for a comprehensive proposal. Filceolaire (talk) 13:11, 11 September 2013 (UTC)
- A court case is not just a text, in the first place it's a legally binding decision following arguments in court, whereas "author" is rather used for creative works written by a person. So I'd prefer to have a separate property. But if there's consensus to use the author property, I'm fine with that. SPQRobin (talk) 21:53, 10 September 2013 (UTC)
- Oppose Use author property: Loving v. Virginia (Q1345835) is a legal text defined by the Supreme Court of the United States (Q11201). No need of specific property. Snipre (talk) 19:56, 9 September 2013 (UTC)
- Comment I would support under the wording "argued before"; that would let us include cases before the Judicial Committee of the Privy Council. But Filceolaire makes a good point about needing a comprehensive proposal. I've already proposed "legal citation" under authority control, but we could also add a bunch of other properties, like majority decision by, minority decision by, concurring decision by, appealed from, plaintiff, defendant. --Arctic.gnome (talk) 16:48, 1 November 2013 (UTC)
SPQRobin, Danrok, Snipre, Filceolaire, Arctic.gnome: I have marked this proposal as not done as per comments. I would suggest starting a "legal task force" to start a comprehensive approach and maybe start another property proposal for "argued before".--Micru (talk) 16:33, 23 November 2013 (UTC)
Not done Needs a holistic approach.--Micru (talk) 16:33, 23 November 2013 (UTC)
Main Commons gallery topic
Description | Item the gallery is about, e.g. for Commons:Pablo Picasso this is Pablo Picasso (Q5593) There are 100,000 generally outdated and unmaintained galleries on Commons. These need to be accommodated in one way or the other. In comparison, there are 3,000,000 categories related to corresponding Wikipedia articles. |
---|---|
Data type | Item |
Domain | any: items with interwikis to Wikimedia Commons Galleries, with P31=Q14916143 |
Example | Q14916142, the item for Commons:Pablo Picasso ==> Pablo Picasso (Q5593) |
- Possible solution to the Commons interwiki problem. -- Docu at 13:52, 15 September 2013 (UTC)
- Commons:Pablo Picasso should be one of the sitelinks at Pablo Picasso (Q5593). Saying that we have 100.000 outdated and unmaintained galleries is not true. People are curating these. Especially in the plants/bugs corner of Commons a lot of people are working on it. This property would be redundant. Multichill (talk) 20:39, 15 September 2013 (UTC)
- You are in the other model assumption. This property would actually improve on the model presented in File:Commons Interwiki links - with wikidata.svg.
- Better stats on galleries would be welcome: I think there may be 10,000 active galleries (out of 110,000), this still leaves us with 100,000 others. Anyways, with this property, we can link items for these through Wikidata items. This way, nothing is lost. -- Docu at 22:48, 15 September 2013 (UTC)
- I strongly disagree with mixing namespaces. It short term this might be useful, but on the long run it will bite us. At the moment we have a little over 1 million categories (Wikimedia category (Q4167836)) of these categories 150.000 (15%) include Commons category (P373) directly linking them to the equivalent category on Commons. We have about 110.000 galleries on Commons, 75.000 of these galleries are linked to articles on Wikipedia. I've been hitting Commons:special:RandomPage to see what turns up: Mostly tree of life, second locations and third people. Most pages are reasonably well maintained, although some people galleries are quite small. Multichill (talk) 12:28, 19 September 2013 (UTC)
- Support — Ivan A. Krestinin (talk) 09:08, 17 September 2013 (UTC)
- Support --Paperoastro (talk) 09:12, 17 September 2013 (UTC)
- Support much better than "liking categories and articles" model. --Jklamo (talk) 15:47, 17 September 2013 (UTC)
- Oppose: Largely per Multichill. We should link categories with categories and main space pages with main space pages (as applicable e.g. lists with Anexo namespace), and let the other new property (pages main category) take care of the rest. --Izno (talk) 02:31, 20 September 2013 (UTC)
- Oppose per Multichill and Izno. Sannita - not just another it.wiki sysop 10:32, 29 September 2013 (UTC)
Not done As per RFC closure there will be no items for galleries, they will be linked from sitelinks.--Micru (talk) 14:44, 23 November 2013 (UTC)
External resources
Description | an article in a non-wikimedia website about this topic. Probably a wiki. |
---|---|
Data type | URL |
Domain | everything |
Example | Sherlock Holmes (Q4653) => bakerstreet.wikia.com/Sherlock_Holmes |
Source | external reference, Wikipedia list article (either infobox or source) |
Proposed by | Shisma (talk) |
- Discussion
Many articles have an External links-section. It contains links to Documents with the same topic. This could be generated from wikidata as well. Shisma (talk) 11:33, 19 September 2013 (UTC)
- I guess many properties here already can be used for that purpose. Authority control, imdb, library-catalogs, official webpage, the proposed sameAs-property etc etc... -- Lavallen (talk) 13:28, 19 September 2013 (UTC)
- I see this opening us to spam that we don't need, and we also need to develop an external links policy, something that I don't think we're quite ready to do. --Izno (talk) 20:22, 20 September 2013 (UTC)
- I agree. there should be a mechanism to review website as a source first. --Shisma (talk) 11:02, 21 September 2013 (UTC)
- Support But with the caveat that is only implemented after a clear policy on external links is made through community consensus. Macadamia1472 (talk) 04:26, 17 October 2013 (UTC)
- How would this be different from described at URL (P973)? --朝彦/Asahiko (talk) 22:00, 21 October 2013 (UTC)
Not done Use described at URL (P973) instead.--Micru (talk) 17:33, 22 November 2013 (UTC)
image depicts
Description | Used as qualifier of image (P18). see Wikidata:Requests for comment/Image properties: many properties or many qualifiers. |
---|---|
Data type | Item |
Example | See Rfc |
Proposed by | GZWDer (talk) |
- Discussion
Motivation. GZWDer (talk) 09:35, 23 November 2013 (UTC)
Question What is wrong with using depicts (P180)? If it is used as qualifier of an image, it is already clear that it refers to what the image depicts.--Micru (talk) 10:24, 23 November 2013 (UTC)
- OK, I have closed it.--GZWDer (talk) 14:35, 23 November 2013 (UTC)
Dewey Decimal Classification / DDC / Classification décimale de Dewey
- Description: Dewey Decimal Classification (Q48460) proprietary library classification system created by Melvil Dewey in 1876
- Infobox parameter: de:Vorlage:DDC
- Datatype: StringValue
- Domain:
- Allowed values:
- Source: en:List of Dewey Decimal classes; DNB-Portal; CiNii Books
- Examples:
- psychology => 150; criminal law => 345; analytical chemistry => 543
- art (Q735) => 700
- recreational & performing arts => 790
- public performances => 791
- radio documentary (Q2125867) => 791.446 (see de:Kategorie:Radio-Feature)
- The Party Journalist (Q25555) => 791.44609431 [DDC22ger] (DNB-Portal; CiNii Books)
- radio documentary (Q2125867) => 791.446 (see de:Kategorie:Radio-Feature)
- public performances => 791
- recreational & performing arts => 790
- Use case:
- Robot and gadget jobs:
- Qualifier: has edition or translation (P747) (DDC 1, DDC 22ger, DDC 23 etc.)
(reopening since the previous discussion was archived) - CristianCantoro (talk) 14:37, 30 June 2013 (UTC)
- Secure sources tell me that it is possible to freely put the ID, but not the whole classification tree (which is proprietary). If I can find a good source we could discuss it further (we could regard it as a authority control identifier). Moreover, if we have different identification (i.e. different libraries classifying the same object in different ways), we can have different sources. Aubrey (talk) 11:06, 29 June 2013 (UTC)
- Could you explain how a Dewey Decimal ID is different than the Dewey Decimal classification tree? Is the classification tree deducible from the ID? Emw (talk) 15:31, 30 June 2013 (UTC)
- Questions: (Reposting unanswered questions from previous discussion. Questions are in response to a comment that "I don't know if we can adopt DDC in full depth (due to copyright reasons) but we could use the ten classes, each divided into ten divisions.") The Dewey Decimal Classification is not freely licensed, as you allude to. Given that, could Wikidata use even the 10 classes? If so, could it use the additional 100 derived divisions? If so, could it use the additional 1000 derived sections? Where is the line, if one exists? How does fair use apply to structured data like Dewey classifications? Would Wikidata allow fair use, since its structured data is in the public domain? Emw (talk) 15:31, 30 June 2013 (UTC)
- We reopened the Proposal, after a meeting with the staff from the National Library of Florence. They claimed that, although the DDC is proprietary and you pay to use it, it was free to use the simple ID. We are still waiting for a link/source for this claim, and we'll share with you as soon as they send to us. It was worth thought to reopen the discussion (hopefully, this time it will be approved, if we can). Aubrey (talk) 16:18, 30 June 2013 (UTC)
- I think Aubrey is right. I would not expect that the assigning of an ID to some object could be copyrighted since the assignment itself is not part of the Dewey system, but done by librarians and others, and it's subjective to some extent. One book might not have the same dewey numbers in two different libraries even though they often have. OCLC has also released DDC linked data under CC BY-NC-ND at dewey.info. Danmichaelo (talk) 19:17, 2 August 2013 (UTC)
- CC BY-NC-ND is not compatible with CC0 (public domain), the terms for the main namespace here. Superm401 - Talk 21:23, 1 October 2013 (UTC)
- There are multiple versions of the DDC. The latest is released under under CC BY-NC-ND, but the earliest is out of copyright. Depending on the use, the DDCs can be 5-8 digitals long. The leaf labels and IDs are created the individual libraries. The copyright would seem to apply to the labels on the non-leaf nodes and the instructions and ruleset for using the system. Stuartyeates (talk) 21:44, 20 August 2013 (UTC)
- The Dewey identifiers are just that -- identifiers. They are used on the spines of books all over the world and no one has to pay to use them. The Dewey documentation and tools are different than the Dewey numbers -- those are either open (as in what's available at dewey.info) or a fuller set of tools available via OCLC. I had an in depth conversation with the Dewey Editor, Michael Panzer, last week and this use of Dewey identifiers as free for all to use lines up with his understanding as well. As an OCLC employee and dedicated volunteer editor I'm here to do everything I can to help clarify this. Merrilee (talk) 18:13, 21 October 2013 (UTC)
- I was also on the call with Merrilee and Michael Panzer. He had no copyright concerns about using Dewey numbers as identifiers. There are parts of Dewey that are licensed CC-BY-NC-ND or licensed per institution, but those are the additional notes and metadata and subject relationships and access to a web service, not the numbers themselves. Ocaasi (talk) 18:29, 21 October 2013 (UTC)
- As I understand it storing identifiers as URIs counts as attributions. So as long we store the DDCs as as links not strings, then there shouldn't be an issue. It's OK to give attribution even if Wikidata does not require it because Dewey is not share-alike. Maximilianklein (talk) 23:05, 21 October 2013 (UTC)
- Storing numbers somewhere was never an issue. However (cf. also the remarks with respect to the tree above) due to the NC license wikidata will never be allowed to provide text labels for the numbers it stores nor can it reproduce the established relations (e.g. broader/narrower) between the "numbers"? (And there also is the issue of "subtables" if I recall correctly). Under these circumstances wikidata usage of the Dewey system would narrow down to possibilities comparable to identifiers from more typical authority control schemes: Import "opaque" numbers found elsewhere, make wikidata items acessible from outside by those identifiers and maybe provide links via that identifier to some external datasets. Not too bad, but far away from what one would expect from a classificiation which could be imagined to be implemented by wikidata items to represent classification nodes... -- Gymel (talk) 14:03, 19 November 2013 (UTC)
- I'm glad the copyright concerns were cleared up by OCLC. To be clear, I think we should store simply the ID as a string (similar to VIAF ID (P214) and many others), and generate the URL. From what I can tell, attribution for this is not required by OCLC. Superm401 - Talk 06:39, 23 November 2013 (UTC)
- As I understand it storing identifiers as URIs counts as attributions. So as long we store the DDCs as as links not strings, then there shouldn't be an issue. It's OK to give attribution even if Wikidata does not require it because Dewey is not share-alike. Maximilianklein (talk) 23:05, 21 October 2013 (UTC)
- Aubrey, Emw, CristianCantoro, Danmichaelo, Superm401, Stuartyeates, Merrilee, Ocaasi, Maximilianklein, Gymel. After reading all the comments I consider that this property is ready for creation. Even being a classification system, this is no different than other identifiers that we are using/linking (viaf, lcc, lccsh, etc). Since there are 23 editions of the DDC and there might be more in the future, which one do you want to refer to? Current one only? If that is the case, the property name would be "Dewey Decimal Classification (ed 23)" and the generated links would be 'http://dewey.info/class/$1/e23/about' (where $1 would be replaced by the DDC number). Thanks for your patience.--Micru (talk) 16:42, 22 November 2013 (UTC)
- I'm not an expert on DDC, but to my memory at the occasion of new editions some subtrees(?) receive a major rehaul and the rest remains mostly (completely?) unchanged. By creating an edition-specific property as you proposed we should be on the safe side, and a future "upgrade" of unchanged numbers from the 23rd edition to newer ones could be feasible. -- Gymel (talk) 17:28, 22 November 2013 (UTC)
- Thank you for bringing up versioning, Micru. I agree that we need to include edition information. An unfortunate consequence is that there are relatively few bibliographic records with ddc 23 classification available for import, since they are not generally updated. But importing classification from older records and assuming they align with ddc 23 is definitely not an acceptable option either. I think starting with ddc 23 is a good option. Then we might add ddc 22 and older editions as needed. Danmichaelo (talk) 02:30, 23 November 2013 (UTC)
Question: Why does it still says in the proposal: "Qualifier (future): Version (DDC 1, DDC 22ger etc."?
- Imho this statement can be replace by one of these:
- Use volume (P478) as a qualifier. Example: DDC 23 (string)
- Use stated in (P248) as a qualifier. Example: Link to the edition DDC 23 (item)
I would prefer #2.We can treat Dewey Decimal Classification (Q48460) like a work (book) that has different editions. --Kolja21 (talk) 06:08, 23 November 2013 (UTC)- Kolja21, good call. Now that you mention it, we also have has edition or translation (P747) or edition number (P393) that could be used as qualifiers. Do you have any preference between stated in (P248) or has edition or translation (P747)?--Micru (talk) 09:00, 23 November 2013 (UTC)
- Support I would treat DDC as a work and therefore prefer has edition or translation (P747). stated in (P248) could mean I've looked up the DDC in the DNB-Portal or an other source. (@Micru: I've updated the proposal.) --Kolja21 (talk) 09:43, 23 November 2013 (UTC)
- Kolja21, good call. Now that you mention it, we also have has edition or translation (P747) or edition number (P393) that could be used as qualifiers. Do you have any preference between stated in (P248) or has edition or translation (P747)?--Micru (talk) 09:00, 23 November 2013 (UTC)
To Aubrey, Emw, CristianCantoro, Danmichaelo, Superm401, Stuartyeates, Merrilee, Ocaasi, Maximilianklein, Gymel, Kolja21:
Done Property created as Dewey Decimal Classification (P1036) to use together with qualifier has edition or translation (P747) to link with the corresponding edition (example: DDC 23 (Q15222117), create new items for other editions as needed).--Micru (talk) 12:05, 23 November 2013 (UTC)
VLACC identifier
Description | Authority control identifier used at the Flemish Public Libraries |
---|---|
Data type | String |
Example | Josephus (Q134461) · viaf:22143666 is using for the future VLACC the value 000001370 . |
Robot and gadget jobs | yes |
Proposed by | לערי ריינהארט (talk) |
- Discussion
Many minority languages are published in the main area covered by the Flemish Public Libraries. לערי ריינהארט (talk) 20:24, 18 October 2013 (UTC)
- FYI: added url anchor via <font id="VLACC" /> לערי ריינהארט (talk) 14:37, 28 October 2013 (UTC)
From w:Flemish Flemish or Belgian Dutch (Belgisch-Nederlands ˈbɛɫʝis ˈneːdərlɑnts, or Vlaams) is the w:Dutch language as spoken in w:Flanders, the northern part of w:Belgium ...
It is quite strange that the Dutch identifier #NTA has been created but the Flemish not. I should spend more time to contact Flemish speakers ... לערי ריינהארט (talk)
- Support - I guess we shouldn't discriminate against languages. --Tobias1984 (talk) 16:24, 13 November 2013 (UTC)
- Oppose - To early. Right now this property would be redundant to VIAF. I think we should wait till there is 1) a possibility to research the identifier directly and 2) a web page we can link to. --Kolja21 (talk) 06:21, 23 November 2013 (UTC)
Not done Redundant with VIAF. Propose again when it can be linked directly to the VLACC website.--Micru (talk) 14:49, 23 November 2013 (UTC)
honorific suffix
- See also #Member of learned society
Description | letters placed after the name of a person to indicate that the individual holds a position, educational degree, accreditation, office, or honour |
---|---|
Data type | Item |
Template parameter | en:Template:Post-nominals |
Domain | Person |
Proposed by | Shawn in Montreal (talk) |
- Discussion
Conversely, should/can post-nominal honours also be a property? Shawn in Montreal (talk) 20:15, 24 February 2013 (UTC)
- Comment I think all of this needs to be handled, but perhaps using more than one property. "Graduate degrees" could be a property in itself, and this is not always used as post-nominal letters. Someone who holds high office and has various honors is very unlikely to indicate Bachelor of Arts (BA) at the end of their name. Danrok (talk) 16:59, 25 February 2013 (UTC)
- Honestly, I just copied the lead from the wiki article on post nominals. I really was thinking of honours like Britain's OBE, or a bunch here that we have. Not really thinking of thinks like a Bachelor's degree in fact I think we should specifically exclude undergrad degrees Shawn in Montreal (talk) 05:01, 27 February 2013 (UTC)
- Support as Honorific suffix as seen in person info box. Danrok (talk) 17:10, 25 February 2013 (UTC)
- Comment Should first understand what level of aggregation/separation the different kinds of suffixes have in the various languages. w:en:Template:Post-nominals is used only on en.wiki, most languages seem not to care at all about such suffixes (see e.g. w:en:John Stuart Mill) and some may have different selections of them and use them in a different way. --Nemo 09:34, 1 March 2013 (UTC)
- Comment Should post-nominal initials be a StringValue, and their membership of whichever society or order be a separate item property? One post-nominal initial might indicate two distinct things; as MS can mean both master of science and membership of the Catholic order Missionarium Saletiniensis. --OldakQuill (talk) 17:42, 6 March 2013 (UTC)
- Comment Post-nominals property should be a string datatype. Another property ('qualification'? 'awards'?) with 'item' datatype should be used to link to items where the names are written out in full. Filceolaire (talk) 15:35, 13 June 2013 (UTC)
- Comment Should all types of suffixes be listed in one property? Alternatively, there could be two properties one for honorific and one for academic. Either way, it must be possible for these to be separated by users of the data because they're used, or not used, in different situations. Danrok (talk) 17:09, 2 July 2013 (UTC)
- Support as Honorific suffix ("honorific_suffix" in many en.Wikipedia infoboxes. Consider also a matching "honorific_prefix"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:33, 19 September 2013 (UTC)
- Another Comment. There are two different ways this might be used.
- 1. As a property for a title which is often represented by a postnomial. Doctor of Philosophy (Q752297)-<postnomial>:"PhD" (String)
- 2. As a qualifier to a name
- <name>:"John Smith PhD MIEE"
- 'given name:John'
- 'surname:Smith'
- 'postnomial:Doctor of Philosophy' (Item)
- 'postnomial:Member of the Institute of Electrical Engineers' (Item)
- <name>:"John Smith PhD MIEE"
- So which way did you mean this property to be used? Filceolaire (talk) 14:29, 19 September 2013 (UTC)
- Comment post nominals belong to the process that granted the letters, eg. Companion of the Order of Australia has post-nominal AC, a graduate or post-graduate degree, etc. on the respective degree, and from there an awardee may use. A person's page should have the respective order, with the level of the order granted, not an attachment of post-nominals. So to me the listing of the post-nominal would be an item but not listed for a person, and called from the award page if needed. — billinghurst sDrewth 08:47, 17 November 2013 (UTC)
@Shawn in Montreal, Danrok, Nemo, OldakQuill, Filceolaire, billinghurst
Done Created as item, since there is the precedent honorific prefix (P511). Ideally it should be linked from the prize/position that confers the title as noted in the comments. The use must be consensuated for both properties if possible.--Micru (talk) 20:17, 22 November 2013 (UTC)
honorary titles
Description | w:Title of honor; particularly w:Hero of the Russian Federation, w:Honorary titles in Russia |
---|---|
Data type | Item |
Template parameter | en:template:infobox person/title |
Domain | Person |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | 4th-otaku (talk) |
- Discussion
technically, this is type of award (Property:P166). --4th-otaku (talk) 02:59, 5 March 2013 (UTC)
- Oppose per 4th-otaku. --NaBUru38 (talk) 19:15, 19 March 2013 (UTC)
- Comment I'm commenting this, bucause I cannot say "support". I think, the honorary title is necessary. E.g. cardinal is honorary title, but cardinals are more known than other bishops and it's important title. And honoris causa for doctors. I hope, you'll say "support". 176.101.138.10 17:27, 18 May 2013 (UTC)
- "cardinal is honorary title" - can you provide a source for this? Danrok (talk) 17:41, 18 May 2013 (UTC)
- w:pl:Szablon:Duchowny infobox (Template:Clergyman infobox) Parameter "tytuł" (title) is reccomending among other things cardinal title. Cardinals except for participate for pope conclave haven't got any other privileges. E.g. the only British cardinal is living, but the English (catholic) primate is common bishop. Cardinals can menage diecese or archidiecese like common bishop. 176.101.138.10 17:58, 18 May 2013 (UTC)
- PS.: And the direct source w:pl:Hierarchia kościelna (Church hierarchy). 176.101.138.10 18:49, 18 May 2013 (UTC)
- As far as I can tell, it would be correct to use the existing Property:P511 (honorific prefix) for this, because Ecclesiastical titles are a sub-category of Category:Honorifics and that's what Property:P511 is for. Danrok (talk) 19:39, 18 May 2013 (UTC)
- OK. It can be prefix, but it must be honorary. :) 176.101.138.10 21:03, 18 May 2013 (UTC)
- The exact wording of labels will never be prefect. We're trying to keep the number of properties to a minimum by taking a generic approach where possible. Danrok (talk) 21:29, 18 May 2013 (UTC)
- OK. It can be prefix, but it must be honorary. :) 176.101.138.10 21:03, 18 May 2013 (UTC)
- As far as I can tell, it would be correct to use the existing Property:P511 (honorific prefix) for this, because Ecclesiastical titles are a sub-category of Category:Honorifics and that's what Property:P511 is for. Danrok (talk) 19:39, 18 May 2013 (UTC)
- "cardinal is honorary title" - can you provide a source for this? Danrok (talk) 17:41, 18 May 2013 (UTC)
- Support --Odejea (talk) 13:14, 5 June 2013 (UTC)
Not done Lack of consensus.--Micru (talk) 20:03, 22 November 2013 (UTC)
thesis
Description | the thesis someone wrote to obtain a (PhD) degree |
---|---|
Data type | Item |
Template parameter | "thesis_title", "thesis_url" and "thesis_year" in en:template:infobox scientist |
Domain | person |
Source | various |
Robot and gadget jobs | I want to import this property from the Mathematics Genealogy Project for mathematicians and computer scientists. |
Proposed by | —Ruud 08:21, 17 July 2013 (UTC) |
- Discussion
- Support --Kompakt (talk) 08:56, 26 July 2013 (UTC)
- Support --Tobias1984 (talk) 12:36, 4 August 2013 (UTC)
- Oppose unless the datatype is changed. I don't think we should be creating items for every thesis. Change it to the Monolingual text datatype with optional qualifiers for a url if it is available online and for an 'associated item' if it does exist as an item on wikidata (if it is used as a source for instance). Filceolaire (talk) 12:38, 5 August 2013 (UTC)
- Separate items are definitely the way to go here, as this would also allow several bibliographic identifiers and properties to be stored with the item as well. Using separate properties or qualifiers, effectively duplicating already existing ones, is rather awkward and misses the point of Wikidata being a database of linked items instead of an encyclopedia: every Wikipedia articles will eventually likely have several Wikidata items associated with it; lists of facts given in the running text of an article will be split out into several linked items on Wikidata. —Ruud 22:17, 12 August 2013 (UTC)
- Separate items would be useful if the URL changed (no more deadlinks!!!!) or to track which articles used a source if it was found to be inaccurate or copyrighted --Macadamia1472 (talk) 06:43, 15 October 2013 (UTC)
- Support, kun "Ero" datumtipo. --Yair rand (talk) 01:19, 7 November 2013 (UTC)
- Support -- Yiyi .... (talk!) 07:34, 7 November 2013 (UTC)
- I think there is consensus to create this; would someone mind providing an example of where this would go, as none was given? Thanks, --Jakob (Scream about the things I've broken) 17:05, 8 November 2013 (UTC)
Done--Micru (talk) 18:22, 18 November 2013 (UTC)
ancestor
Description | ancestry is often used to legitimise position of power.. particularly relevant at the start of a dynasty or when succession is contested |
---|---|
Data type | Item |
Template parameter | put Wikipedia infobox parameters here. If existing, sample: "population" in en:template:infobox settlement |
Domain | person |
Example | example item and/or example value (please add one or several sample uses of the property. Sample: Moulay Ali Cherif (Q3050987) => Al Hassan Addakhil (Q4703997)) |
Format and edit filter validation | (sample: 7 digit number can be validated with edit filter Special:AbuseFilter/17) |
Source | external reference, Wikipedia list article (either infobox or source) |
Robot and gadget jobs | Should or are bots or gadgets doing any task with this? (Check other properties for consistency, collect data, etc.) |
Proposed by | GerardM (talk) |
- Discussion
Motivation. GerardM (talk) 12:39, 3 October 2013 (UTC)
- Comment how do you envisage this working in detail? Exactly who would be included? For example, would a person's father and mother be included? (legally they are ancestors) --Danrok (talk) 02:44, 15 October 2013 (UTC)
- This is only when the existing properties would not function ie it is more generations back than 2. GerardM (talk) 11:27, 19 October 2013 (UTC)
- Oppose. This should be done with relationship properties like father (P22) and mother (P25). "Ancestor" is way too vague and provides little information in terms of family lineage. --Wylve (talk) 16:40, 30 October 2013 (UTC)
- Please explain how you would indicate a relation with someone who is more than 3 generations removed? GerardM (talk) 18:32, 3 November 2013 (UTC)
- Support. Should only be used when there isn't enough information to describe the relationship more precisely. Filceolaire (talk) 17:13, 6 November 2013 (UTC)
Not done Use as alternative relative (P1038) with qualifier kinship to subject (P1039).--Micru (talk) 15:10, 23 November 2013 (UTC)
awarded by
Description | Person or organization who awards a prize to a recipient |
---|---|
Data type | Item |
Domain | Person; Organization |
Allowed values | Person, Organization |
Example | Maurice Papon (Q327009) was awarded the Legion of Honour (Q163700) by Charles de Gaulle (Q2042) |
Proposed by | Freedatum (talk) |
- Discussion
- This qualifier identifies the person or the organization who gives the award. Some awards are given by an organization (committee, institute, foundation), some are given by a person (acting in the capacity of). This qualifier helps understand the relationship between the presenter and the recipient. -- Freedatum (talk) 13:26, 11 October 2013 (UTC)
- Support assuming it is just 'by' as in your example, not 'given by' in the title Macadamia1472 (talk) 07:24, 15 October 2013 (UTC)
- Comment if this if for use with awards, and similar things like medals, then it should be awarded by or awarder. --Danrok (talk) 23:27, 15 October 2013 (UTC)
- Comment But just 'by' would be more useful as a qualifier across multiple applications i.e. <J. F. Kennedy> cause of death <assassination> {by: Lee Harvey Oswald} Macadamia1472 (talk) 05:07, 16 October 2013 (UTC)
- But those don't mean the same thing. I agree with Danrok. --Yair rand (talk) 15:11, 16 October 2013 (UTC)
- Extending it to "<anything> by" would probably creates overlaps with properties like killed by (P157), review score by (P447), lyricist (P676), legislated by (P467), owned by (P127), follows (P155). -- Freedatum (talk) 10:17, 18 October 2013 (UTC)
- Comment But just 'by' would be more useful as a qualifier across multiple applications i.e. <J. F. Kennedy> cause of death <assassination> {by: Lee Harvey Oswald} Macadamia1472 (talk) 05:07, 16 October 2013 (UTC)
- Comment "given by" could be applied to any item that can be possessed and that has been given by a person or organization. It's essential for awards, but it's also useful for describing the origin of other items: creative works (a painting donated to museum), property rights (a patent given to a foundation), and even a place (lands granted to a vassal). This qualifier could also be known as: donated by, granted by, sold by, bequeathed by, stolen by, etc. -- Freedatum (talk) 10:15, 18 October 2013 (UTC)
- Comment if this if for use with awards, and similar things like medals, then it should be awarded by or awarder. --Danrok (talk) 23:27, 15 October 2013 (UTC)
- Better name for the use case given would be "awarded by". Also need "donor", for artworks given to galleries, etc. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:15, 30 October 2013 (UTC)
- I think potential uses of this need to be clearly restricted to qualifying award received (P166). --Yair rand (talk) 00:28, 31 October 2013 (UTC)
- I agree with Andy. We need an "Awarded by" property and a "Donated by" property rather than this "Given by" property. Filceolaire (talk) 17:18, 6 November 2013 (UTC)
- I also agree with Andy and Filceolaire. -- Yiyi .... (talk!) 16:42, 9 November 2013 (UTC)
- Support Renamed to "awarded by" and started a new property proposal for "donated by" (see below). --Micru (talk) 16:48, 9 November 2013 (UTC)
Done --Micru (talk) 18:24, 18 November 2013 (UTC)
donated by
Description | Person or organization who donates an object |
---|---|
Data type | Item |
Domain | art; Organization |
Allowed values | Person, Organization |
Proposed by | Per above discussion--Micru (talk) 16:48, 9 November 2013 (UTC) |
- Discussion
- Support--Micru (talk) 16:48, 9 November 2013 (UTC)
- Support -- Yiyi .... (talk!) 10:47, 10 November 2013 (UTC)
Done --Micru (talk) 18:26, 18 November 2013 (UTC)
son-in-law, daughter-in-law, grandchild, father-in-law, mother-in-law
Description | degrees of relationship |
---|---|
Data type | Item |
Domain | people/persone |
Example | son-in-law: Gabre Gabric (Q3756452) => Eddy Ottoz (Q5447) grandchild: Gabre Gabric (Q3756452) => Patrick Ottoz (Q3000767) mother-in-law: Eddy Ottoz (Q5447) => Gabre Gabric (Q3756452) |
Source | son-in-law, daughter-in-law, grandchild, father-in-law and mother-in-law |
Proposed by | Yiyi .... (talk!) |
- Discussion
I think theese properties should be useful in cases like w:Ottoz family and many others. Thanks ;) Yiyi .... (talk!) 13:24, 3 November 2013 (UTC)
-- Support לערי ריינהארט (talk) 18:25, 3 November 2013 (UTC)
- I don't understand how these could ever be useful. This data could all be deduced from other statements. --Yair rand (talk) 21:59, 3 November 2013 (UTC)
- For example, in the Ottoz Family we have Sandro Calvesi who is Eddy Ottoz father-in-law and also his trainer: IMO it's a relevant information... I think there may be other cases like this. Then, we have on Wikidata P45 (P45): why not grandchild? -- Yiyi .... (talk!) 08:04, 4 November 2013 (UTC)
- I'm not sure it can automatically be deduced, since not all people are notable enough to have an item. For example, if Person A : sister : Person B : spouse : Person C, where A & C are notable entries, but Person B is not, the link would need the in-law property to connect the two. Joshbaumgartner (talk) 09:29, 4 November 2013 (UTC)
- Yes, with my example I wanted to say just that: Lyana Calvesi (Sandro Calvesi's daughter and Eddy Ottoz's wife) isn't a notable entry, but the relationship between theese people is so relevant. Thank you Joshbaumgartner! -- Yiyi .... (talk!) 13:37, 4 November 2013 (UTC)
- Please see criterion 3 of WD:N. Entities become notable as soon as they are needed to fill out the structure of the related articles, so Lyana Calvesi is completely notable. --Yair rand (talk) 20:33, 4 November 2013 (UTC)
- I added Lyana Calvesi (thanks for the suggestion). But I still think that these properties continue to be useful (when I see the element "Eddy Ottoz" I want to know that Sandro Calvesi was both his trainar and his father-in-law, without passing through "Lyana Calvesi", because there is a close relationship between Eddy and Sandro - and it's only an example). -- Yiyi .... (talk!) 21:28, 5 November 2013 (UTC)
- So you would add the redundant data to make the statement more noticeable/prominent and less hard to find? That doesn't sound like a good idea to me. --Yair rand (talk) 21:36, 5 November 2013 (UTC)
- Ok, we have two different points of view :-) Other opinions? (is it me or this page is a bit depopulated?) -- Yiyi .... (talk!) 19:22, 6 November 2013 (UTC)
- So you would add the redundant data to make the statement more noticeable/prominent and less hard to find? That doesn't sound like a good idea to me. --Yair rand (talk) 21:36, 5 November 2013 (UTC)
- I added Lyana Calvesi (thanks for the suggestion). But I still think that these properties continue to be useful (when I see the element "Eddy Ottoz" I want to know that Sandro Calvesi was both his trainar and his father-in-law, without passing through "Lyana Calvesi", because there is a close relationship between Eddy and Sandro - and it's only an example). -- Yiyi .... (talk!) 21:28, 5 November 2013 (UTC)
- Please see criterion 3 of WD:N. Entities become notable as soon as they are needed to fill out the structure of the related articles, so Lyana Calvesi is completely notable. --Yair rand (talk) 20:33, 4 November 2013 (UTC)
- Yes, with my example I wanted to say just that: Lyana Calvesi (Sandro Calvesi's daughter and Eddy Ottoz's wife) isn't a notable entry, but the relationship between theese people is so relevant. Thank you Joshbaumgartner! -- Yiyi .... (talk!) 13:37, 4 November 2013 (UTC)
- I'm not sure it can automatically be deduced, since not all people are notable enough to have an item. For example, if Person A : sister : Person B : spouse : Person C, where A & C are notable entries, but Person B is not, the link would need the in-law property to connect the two. Joshbaumgartner (talk) 09:29, 4 November 2013 (UTC)
Oppose I think these kind of specific properties should be avoided and more general ones used instead. The reason is that they won't be used that much, and it is hard to say where to stop creating them (what about cousins, adoptions, etc?). In addition to direct kindship (father, son, etc) we could use the pair "relative" and "type of kinship" as qualifier. That way we could represent *any* relationship that might be relevant when entering data.--Micru (talk) 12:46, 9 November 2013 (UTC)
- Support…but, couldn't this better be suited with a qualifier? e.g. Mother -> qualifier is "by birth" vs "by adoption" separate properties would still be needed for grandparent/grandchild. Also many languages differenciate between maternal and paternal grandparents so this would likely need to be two values to be properly internationalized
Jared Zimmerman (talk) 21:55, 12 November 2013 (UTC)
- Oppose per Micru. Use a generic 'relative' property plus a qualifier instead, as the proposal further down the page. Filceolaire (talk) 22:51, 22 November 2013 (UTC)
Not done Use as alternative relative (P1038) with qualifier kinship to subject (P1039).--Micru (talk) 15:12, 23 November 2013 (UTC)
Event (or something like this)
Description | In athletics, the event in which an athlete is specialized (but it should be used for other sports). It could be used like qualifier for athletics competitor (Q11513337) |
---|---|
Data type | Item |
Template parameter | "Specialità" in it:Template:Sportivo |
Domain | persone |
Example | Sara Simeoni (Q5442) => athletics competitor (Q11513337) => high jump (Q165704) |
Proposed by | Yiyi .... (talk!) |
- Discussion
- Oppose. We have sport (P641) for this. Filceolaire (talk) 17:07, 6 November 2013 (UTC)
- Yes, but the sport is athletics (or track and field); long jump, shot put, 100 m, hurdless, etc. are events of this sport. -- Yiyi .... (talk!) 19:17, 6 November 2013 (UTC)
- Question Can we just link 'long jump' as the sport with sport (P641), and the fact that 'long jump' should be a subclass of 'athletics', the fact that the person competes in athletics be inferred by virtue of being linked to 'long jump'? Joshbaumgartner (talk) 08:43, 7 November 2013 (UTC)
- We can, but it would not be precise, because the 'sport' is athletics. I's valid also (I think) for skiing, swimming, motorsports, cycling, etc. -- Yiyi .... (talk!) 09:08, 7 November 2013 (UTC)
- Question Can we just link 'long jump' as the sport with sport (P641), and the fact that 'long jump' should be a subclass of 'athletics', the fact that the person competes in athletics be inferred by virtue of being linked to 'long jump'? Joshbaumgartner (talk) 08:43, 7 November 2013 (UTC)
- Yes, but the sport is athletics (or track and field); long jump, shot put, 100 m, hurdless, etc. are events of this sport. -- Yiyi .... (talk!) 19:17, 6 November 2013 (UTC)
- Oppose. I think we should use sport (P641). Linking to 'long jump' is more precise than 'athletics' because it is a narrower class. If 'long jump' is not considered to be a 'sport' then P641 needs a name change or an alias to indicate it can be used to link to a precise subclass such as 'long jump' where appropriate. Filceolaire (talk) 22:45, 22 November 2013 (UTC)
- Ok, I like this option. -- Yiyi .... (talk!) 12:12, 23 November 2013 (UTC)
Not done As per comments.--Micru (talk) 12:36, 23 November 2013 (UTC)
relative
Description | use together with the property "type of kinship" as qualifier (see proposal below) to describe non-direct family relationships between members and when the intermediary family members are unknown or irrelevant |
---|---|
Data type | Item |
Domain | person |
Example | Moulay Ali Cherif (Q3050987) => Al Hassan Addakhil (Q4703997) with the qualifier kinship to subject (P1039) => ancestor (Q402152) |
Proposed by | Micru (talk) |
- Discussion
Motivation: There are many family grades that might be relevant but we might not want to create properties for all of them (son-in-law, daughter-in-law, grandchild, father-in-law, mother-in-law, adoptions, ancestors, etc.) and the members in between might be irrelevant or unknown so it is not possible to infer the relationship. By using this property together with "type of kinship" as qualifier, we can represent all possible relations.Micru (talk) 22:54, 12 November 2013 (UTC)
Support "non-direct relative" seems a bit odd though could we get away with "relative" or "family member"
Jared Zimmerman (talk) 23:02, 12 November 2013 (UTC)
- I'm not sure I understand. Why would it matter whether the members in between are irrelevant or unknown? If they fill out the structure, they need items, per WD:N. --Yair rand (talk) 23:30, 12 November 2013 (UTC)
- In the case of "ancestors" we don't even know how many items should be created. And if we create properties for all kind of kinship there might be too many.--Micru (talk) 23:35, 12 November 2013 (UTC)
- If that's the intended purpose of the property, I think the description and example given should be modified to reflect that. --Yair rand (talk) 00:40, 13 November 2013 (UTC)
- In the case of "ancestors" we don't even know how many items should be created. And if we create properties for all kind of kinship there might be too many.--Micru (talk) 23:35, 12 November 2013 (UTC)
- Support. It seems a good solution. -- Yiyi .... (talk!) 08:15, 13 November 2013 (UTC)
- Support though I think the name could be improved, as Jared Z's suggestions. Filceolaire (talk) 22:54, 22 November 2013 (UTC)
- Name updated to "relative".--Micru (talk) 12:45, 23 November 2013 (UTC)
GerardM, Danrok, Wylve, Filceolaire, Yiyi, לערי ריינהארט, Joshbaumgartner, Yair rand, Jared Zimmerman:
The properties relative (P1038) and kinship to subject (P1039) have been created. You are being notified because you either participated in this discussion or in the discussion about "ancestor, son-in-law, etc" which have not been created since they can be represented using this pair.--Micru (talk) 16:23, 23 November 2013 (UTC)
type of kinship
Description | use together with the property "non-direct relative" (see above) to describe non-direct family relationships between members and when the intermediary family members are unknown or irrelevant |
---|---|
Data type | Item |
Domain | person |
Example | Moulay Ali Cherif (Q3050987) <relative (P1038)> Al Hassan Addakhil (Q4703997) with the qualifier kinship to subject (P1039) => ancestor (Q402152) |
Proposed by | Micru (talk) |
- Discussion
Motivation: See "non-direct relative" proposal.Micru (talk) 22:54, 12 November 2013 (UTC)
Done--Micru (talk) 15:05, 23 November 2013 (UTC)
This doesn't quite work… Texas Jack (Q7707785) is the adopted father of Texas Jack Jr. (Q7707787) but with the properties and values we have no you can't express the "Adopted father" or "adopted son" part only that they are relatives and it is via adoption.
Jared Zimmerman (talk) 00:18, 24 November 2013 (UTC)
circa
Description | Means in approximately, Year (of birth/death) uncertain. Can't be replaced by precision. |
---|---|
Data type | boolean-invalid datatype (not in Module:i18n/datatype) |
Domain | mainly person |
Allowed values | True |
Example | Genghis Khan (Q720)date of birth (P569)1162<circa>true |
Robot and gadget jobs | en:Category:Year of birth uncertain, en:Category:Year of death uncertain |
Proposed by | GZWDer (talk) |
- Discussion
Motivation. GZWDer (talk) 15:25, 23 November 2013 (UTC)
- Oppose This should be a general change to the time/date input, allow for a checkbox or similar to specify that the input date is approximate, and not precise.
Jared Zimmerman (talk) 00:24, 24 November 2013 (UTC)
- Oppose - Boolean datatype is not planned anymore. The uncertainty should be taken care of in the date-datatype. 1162 +/- 2 years for example. Its important to remember that usage of the circa is pretty subjective. --Tobias1984 (talk) 09:55, 24 November 2013 (UTC)
Not done To be handled by the datatype.--Micru (talk) 12:09, 24 November 2013 (UTC)
manager/director
Description | person who manages an organization, group, or body |
---|---|
Data type | Item |
Template parameter | "director" in en:Template:Infobox Museum |
Domain | organization |
Allowed values | person items |
Example | Louvre Museum (Q19675) => Jean-Luc Martinez (Q3167200) |
Proposed by | The Anonymouse (talk) |
- Discussion
There needs to be a generic manager/director property when chief executive officer (P169) and chairperson (P488) are not suitable. The Anonymouse (talk) 15:16, 5 November 2013 (UTC)
- Support--Micru (talk) 12:48, 12 November 2013 (UTC)
- Support--Yiyi .... (talk!) 22:34, 20 November 2013 (UTC)
- Done --Jakob (Scream about the things I've broken) 14:45, 23 November 2013 (UTC)
Combatant
Description | Proposal for 3 properties. Multi-item list of allied belligerents who oppose(d) the other set(s) of belligerents |
---|---|
Data type | Item |
Template parameter | "combatant3" in en:template:military conflict |
Domain | battles, conflicts, wars |
Allowed values | Generally countries and organization-type items |
Example | Q570456 => Q34266 |
Source | wikipedia, history books, news articles, etc. |
Robot and gadget jobs | Can be sourced from infoboxes |
Proposed by | Danrok (talk) 20:38, 26 August 2013 (UTC) |
- Discussion
- Comment Quite an important one this. As things are, we have no way of indicating who was at war, and on which side. I have only specified 3 sides because that is what is indicated in the infobox. Please say if you think there is a better way to handle this. Danrok (talk) 20:44, 26 August 2013 (UTC)
- Comment I would prefer something like:
- Someone
- fought in = war 1 (property)
- against = someone else (qualifier)
- with = friend (qualifier)
- start date = 1900 (qualifier)
- end date = 1901 (qualifier)
- fought in = war 1 (property)
- Someone
- The problem is that it will be hard to handle cases where a friend turns into an enemy. --Tobias1984 (talk) 15:05, 28 August 2013 (UTC)
- Not that hard:
- Someone
- fought in = war 1 (property)
- against = someone else (qualifier)
- with = another someone (qualifier)
- start date = 1900 (qualifier)
- end date = 1901 (qualifier)
- fought in = war 1 (property)
- against = another someone (qualifier)
- with = someone else (qualifier)
- start date = 1902 (qualifier)
- end date = 1903 (qualifier)
- fought in = war 1 (property)
- These are properties for 'someone'. Danrok is proposing a property for the item related to the battle or the war. I think this would work as follows:
- The battle of the big river (item)
- combatant : 1st brigade (property + item)
- part of : The Grand Alliance (qualifier + item)
- combatant : 9th army (property + item)
- part of : The Axis of Evil (qualifier + item)
- combatant : 1st brigade (property + item)
- You can have as many combatants as you need - all with the 'combatant' property. If it works better for the infobox it could be:
- The battle of the big river (item)
- combatant : The Grand Alliance (property + item)
- has part : 1st brigade (qualifier + item)
- combatant : The Axis of Evil (property + item)
- has part : 9th army (qualifier + item)
- combatant : The Grand Alliance (property + item)
- Support if renamed to 'Combatant'. Filceolaire (talk) 01:49, 29 August 2013 (UTC)
- Comment Just to be clear, I am trying to solve what you can see in the info box of a war/battle article, under the heading of Belligerents, see here: World War II. In that case there are 2 sides, Allies and Axis. We have a participants property, but how to indicate which side a combatant was on? And, not all participants are combatants. Danrok (talk) 20:38, 29 August 2013 (UTC)
- Comment I think Filceolaire's suggestion above may do it. Any more suggestions are still welcome. Danrok (talk) 02:04, 3 September 2013 (UTC)
- Looking at en:Template:WW2InfoBox which is probably as complicated an info box as ever you would want to try to do with a wikidata page.
- There is a long list of countries that participated in the war. For each the infobox specifies:
- The 'Combatant' they are allied to
- if they are a 'client/puppet state' or a 'co-beligerent' or a full member of that alliance
- the start date and end date of their participation
- Here is how I think you can do it for a worst case:
hidden because I changed my mind |
---|
The following discussion has been closed. Please do not modify it. |
Thinking about it that isn't ideal because you should be able to get the important info about any case even if you cannot see the qualifiers.
|
- Would the idea be to create an item for each group of combatants? For The Allies and Axis there will already be items, no problem, but not sure how that will work out for other battles where there is no formal name for each side, we can't really make-up names. Or am I misunderstanding? The way I see it, is that the current design of wikidata does not cater well for this. I wonder if it is possible to get the devs to allow specific properties to occur more than once in an item, then we would be able to have multiple groups of multi-values. Danrok (talk) 10:42, 12 September 2013 (UTC)
- You can have specific properties as many times as you like. The problems is that you cannot have a qualifier to a qualifier. If you have property 'Combatant 1' with all the countries (or the military units) that make up that side as qualifiers to that property then there is no where to put the qualifiers to say how many soldiers/casualties each country had. Putting each side on a different page is like getting another layer of qualifiers.
- Infoboxes for each battle include these lists of participants so in each case you need to give the item for the battle a pair of daughter items e.g. <Allied forces at the Battle of Tobruk> then use the 'combatant' property on the <battle of Tobruk> item to link to these daughter items. There may be a better way to do it but I can't see it.
- Basically you need to wait until you have a proposal for all the data in the battle infobox and then propose all the properties together. You are not there yet. Filceolaire (talk) 23:25, 21 September 2013 (UTC)
- Would the idea be to create an item for each group of combatants? For The Allies and Axis there will already be items, no problem, but not sure how that will work out for other battles where there is no formal name for each side, we can't really make-up names. Or am I misunderstanding? The way I see it, is that the current design of wikidata does not cater well for this. I wonder if it is possible to get the devs to allow specific properties to occur more than once in an item, then we would be able to have multiple groups of multi-values. Danrok (talk) 10:42, 12 September 2013 (UTC)
- OK. I've had another idea:
- World War II (item)
- combatant:The Allies (property)
- combatant:The Axis
- participant:United Kingdom (property)
- part of:The Allies (qualifier)
- flag:flag.jpg
- number of soldiers:1234567
- number of military dead:12345
- number of civilian dead:123456
- participant:The Philippines
- instance of:puppet state
- part of:The Allies
- flag:flag.jpg
- start date:1941
- end date:1945
- 'Leader:Churchill
- part of:The Allies
- flag:flag.jpg
- There. That might work. Filceolaire (talk) 00:07, 22 September 2013 (UTC)
- I think having the flag there is redundant. Querying the country flag at the time of the conflict is more practical. Also, United Kingdom (Q145) should already be an item included in Allies of the Second World War (Q329888) (using has part(s) (P527), as shown here). In Paraguayan War (Q58947) I added the belligerants as participants, which because of the Triple Alliance (Q15051546) became easy to sort out who was fighting who, but I realise this would be more complicated if it featured more participants. Pikolas (talk) 14:47, 23 November 2013 (UTC)
Danrok, Tobias1984, Filceolaire, Pikolas: I have marked this property as "not done", however it would be useful if you could start a task force (war? military?) and record all properties that you are using. If you find any gap, please propose the property again.--Micru (talk) 17:02, 23 November 2013 (UTC)
Elevation / Höhe ü. NN / Altitude
- Description: Elevation
- Datatype:
- Links: How high a place is.
- Infobox parameter example:
- Comments: Reedy (talk) 02:11, 5 February 2013 (UTC)
- Isn't this info going to be part of the Geodata stuff? --Yair rand (talk) 02:39, 5 February 2013 (UTC)
- Yes and no. Here we will to distinguish
- official elevation (not ever clear what this is, but that goes into the geodata - coordinate)
- lowest elevation
- highest elevation
- arguable: elevation of town hall
- arguable: elevation of railway station
- arguable: elevation of post office
- arguable: elevation of whatsoever
- where the one or more or all of last six are possibly the same as #1. --Matthiasb (talk) 13:42, 7 March 2013 (UTC)
- Further we need to pay attention which elevation reference system is used. --Matthiasb (talk) 14:07, 7 March 2013 (UTC)
- What is Geodata? --NaBUru38 (talk) 20:10, 27 March 2013 (UTC)
- Comment Elevations are usually given in each countries favored map projection and "zero elevation datum". To keep the coherency of the data we would need all measurements according to a global standard or have some way of converting local standards. --Tobias1984 (talk) 21:17, 16 April 2013 (UTC)
- Comment Or this could be defined with qualifiers. Joshbaumgartner (talk)
Not done Inconclusive discussion. Start again when the appropriate datatype is available.--Micru (talk) 11:29, 24 November 2013 (UTC)
Existing road length / Straßenlänge im Betrieb / longueur de la route en service
- Description: length of the completed or existing part of the road / Länge des fertiggestellten Teils der Straße
- Datatype: number value
- Links:
- Infobox parameter example: w:de:Vorlage:Infobox hochrangige Straße (Betrieblänge)
- Comments: unit in kilometer per default --Daniel749 talk 09:21, 23 February 2013 (UTC)
- Oppose. Use Length (datatype number with dimension) with qualifier 'point in time' for the date that length applies or will apply for planned/underconstruction routes. Filceolaire (talk) 20:39, 9 October 2013 (UTC)
Not done Redundant / lack of support.--Micru (talk) 15:55, 9 November 2013 (UTC)
Date of opening
Description | Date an object was opened for public or inaugurated |
---|---|
Data type | Point in time |
Template parameter | "opened" in en:Template:Infobox station, "Дата открытия" in ru:Шаблон:Станция метро |
Domain | buildings, artificial geographical objects |
Allowed values | date, possibly with time |
Example | Eiffel Tower (Q243) => +00000001989-03-31T00:00:00Z, Lermontovsky Prospekt (Q4259275) => +00000002013-11-09T11:00:00Z |
Proposed by | YLSS (talk) |
- Discussion
I doubt that this was never discussed before, but I was unable to find anything, so please forgive me if I'm forking. Everything is pretty self-explanatory here; the only questions are: 1) whether to have only "Date of opening", or the full array of "Date of completion", "date of inauguration", "construction started" etc. 2) The interrelation with closing. If "Date of opening" is created, I suppose that necessitates "Date of closing" as well ("closed" in en:Template:Infobox station, "Дата закрытия" in ru:Шаблон:Станция метро). However, for such cases when an object was re-opened after some time; and possibly again closed and re-opened; how to present such sequences? Using qualifiers, and if so, which? Or should some sequential data type be created? YLSS (talk) 12:37, 11 November 2013 (UTC)
- This should probably be start date, which is already a property. --Izno (talk) 23:14, 11 November 2013 (UTC)
- Yes, I know of it, but its description says "The time the claim began being valid, usually as a qualifier, often paired with end date", which is not very applicable, or that it "indicates the time an item begins to exist" - which brings again the question of "construction started" vs. "Date of completion" vs. "date of inauguration". That said, I'm not against using start time (P580) for such purposes, but if so, some more appropriate aliases should be added to it. Is that OK? YLSS (talk) 09:57, 12 November 2013 (UTC)
YLSS, you can use start time (P580) or if you want more precission, then significant event (P793) with qualifier point in time (P585).
Not done--Micru (talk) 11:23, 24 November 2013 (UTC)
Source
Description | Mountain or locality where a river begin. |
---|---|
Data type | Item |
Template parameter | "nasce" in it:Template:Infobox fiume |
Domain | luoghi |
Example | Po (Q643) => Viso (Q1248); qualifier: Pian del Re (Q3382175)) |
Proposed by | Yiyi .... (talk!) |
- Discussion
Support as proponent. Yiyi .... (talk!) 20:21, 12 November 2013 (UTC)
Yiyi, why not to use origin of the watercourse (P885)?--Micru (talk) 02:05, 24 November 2013 (UTC)
- Micru I didn't know that it existed. Now I've translated it in italian. Thanks.
Not done As per comments.--Micru (talk) 11:24, 24 November 2013 (UTC)
Crew member / Члены экипажа
Description | члены экипажа/crew member |
---|---|
Data type | Item |
Template parameter | ru:Шаблон:Космическая экспедиция Членов экипажа, en:Template:Infobox space mission Crew |
Domain | пилотируемые космические аппараты/manned spacecraft |
Allowed values | космонавты/cosmonauts |
Example | Союз (Soyuz) ТМА-8, члены экипажа/crew member: Виноградов, Павел Владимирович, Понтис, Маркус, Уильямс, Джеффри Нелс |
Source | Карточки в статьях и т. д. |
Proposed by | — Ivan A. Krestinin (talk) 19:20, 1 April 2013 (UTC) |
- I support that the crew members should be mentioned, but I would prefer a more general domain for general use with a more generic term like maybe "participant" . Byrial (talk) 08:15, 9 May 2013 (UTC)
- Comment Do we still need this property or has another solution been found? I am asking because the question was asked on 9 May 2013. --Tobias1984 (talk) 08:40, 29 July 2013 (UTC)
- Oppose In preference to using participant (P710), and how about using occupation (P106) as a qualifier, and in this case astronaut (Q11631)?
- participant (P710) is not applicable for spacecrafts. Man can not be participant (P710) of some device. — Ivan A. Krestinin (talk) 21:37, 27 October 2013 (UTC)
- Support there is: member of (P463) for organizations, member of sports team (P54) for sport, member of political party (P102) for politics. None of this can be used for these topic. --Paperoastro (talk) 22:08, 27 October 2013 (UTC)
- Support --Adert (talk) 23:02, 8 November 2013 (UTC)
- Oppose: Member of (P463) can and should be used here for correlating people to missions. Missions should be correlated to spacecraft separately (I assume there is already a property for that correlation). --Izno (talk) 00:01, 9 November 2013 (UTC)
- Support with qualifier like "Commander", "Pilot" or "Flight Engineer" --ValterVB (talk) 23:01, 11 November 2013 (UTC)
Done --Micru (talk) 18:33, 18 November 2013 (UTC)
Type of propulsion or engine (ship)
Description | Type of propulsion and/or engine (general or specifique) for a ship |
---|---|
Data type | Item |
Domain | Transportation |
Example | French battleship Démocratie (Q5501991) => steam engine (Q12760) and French battleship Démocratie (Q5501991) => propeller (Q205451) Aigrette (Q15104547) => diesel engine (Q174174) and Aigrette (Q15104547) => electric boat (Q3407641) and Aigrette (Q15104547) => propeller (Q205451) |
Source | https://fr.wikipedia.org/wiki/Propulsion_maritime |
Proposed by | Antoinelam (talk) |
- Discussion
Motivation. There are so many types of propulsion (waterjet, sails, ...) or engine (nuclear, petrol engine, ...) for a ship Antoinelam (talk) 09:51, 5 November 2013 (UTC)
- Comment Moved under Ships.
- Question There is already powered by (P516) which is in use for powered vehicles. Is this not sufficient for the purpose? Joshbaumgartner (talk) 06:57, 6 November 2013 (UTC)
- Comment I think that powered by (P516) is a general facility to make electric current, such as a nuclear power station, a tidal power station or a electrical generator. if it isn't, the english label and description aren't very precise and perfectly clear (also the french translation). Antoinelam (talk) 10:10, 6 November 2013 (UTC)
- Comment Interesting to hear that take on it. I've been linking a bunch of airplanes with their engines using powered by (P516) and I wouldn't see the problem with using it for what you are stating either. The nature of usage would be determined by the subject item it is used for. For an airplane or car, it would be the vehicle's engine, for a ship, the diesel engine or nuclear reactor even, though I'll let the ship folks parse out exactly what qualifies as a 'powerplant' on a ship. Likewise it could be used as you mention for a power-generating facility if one exists for a subject, though I can't think of an example off hand of exactly how that might link up. At least in aviation, I would say the label is very clear (it is exactly how the engine is called out in a great many sources) and from what I know of ships, the same is true that 'powerplant' is a well-understood terminology. I believe the property was intentionally broad to allow it to be used for several types of items, avoiding the need for separate specific properties for aviation, automobiles, ships, trains, etc. Joshbaumgartner (talk) 08:36, 7 November 2013 (UTC)
- Comment Ok. I understand now. My english is so poor that I misunderstood the general signification of powerplant (with the help of the very bad french translation !). From now on I'll take this property powered by (P516) for my ship-datas, but for the other french contributors like me, I'm going to suggest a better french Label and a better french description. Thank you for your answer. Sincerely Yours. Antoinelam (talk) 09:49, 7 November 2013 (UTC)
- Absolutely! Be bold and make the label in French whatever it needs to be to convey the meaning. Your English is 100% better than my French. Joshbaumgartner (talk) 08:04, 8 November 2013 (UTC)
- Comment Ok. I understand now. My english is so poor that I misunderstood the general signification of powerplant (with the help of the very bad french translation !). From now on I'll take this property powered by (P516) for my ship-datas, but for the other french contributors like me, I'm going to suggest a better french Label and a better french description. Thank you for your answer. Sincerely Yours. Antoinelam (talk) 09:49, 7 November 2013 (UTC)
- Comment Interesting to hear that take on it. I've been linking a bunch of airplanes with their engines using powered by (P516) and I wouldn't see the problem with using it for what you are stating either. The nature of usage would be determined by the subject item it is used for. For an airplane or car, it would be the vehicle's engine, for a ship, the diesel engine or nuclear reactor even, though I'll let the ship folks parse out exactly what qualifies as a 'powerplant' on a ship. Likewise it could be used as you mention for a power-generating facility if one exists for a subject, though I can't think of an example off hand of exactly how that might link up. At least in aviation, I would say the label is very clear (it is exactly how the engine is called out in a great many sources) and from what I know of ships, the same is true that 'powerplant' is a well-understood terminology. I believe the property was intentionally broad to allow it to be used for several types of items, avoiding the need for separate specific properties for aviation, automobiles, ships, trains, etc. Joshbaumgartner (talk) 08:36, 7 November 2013 (UTC)
- Comment I think that powered by (P516) is a general facility to make electric current, such as a nuclear power station, a tidal power station or a electrical generator. if it isn't, the english label and description aren't very precise and perfectly clear (also the french translation). Antoinelam (talk) 10:10, 6 November 2013 (UTC)
Not done As per comments.--Micru (talk) 12:13, 24 November 2013 (UTC)
Type locality (Locus typicus) / Typlokalität, Typenfundort (Biologie)
Description | The place where the type was found. |
---|---|
Data type | Item |
Example | Stratigraphy: The section where the division or unit was defined: Fortunian (Q1424618) (stage of the geologic time scale) = Fortune Head section Mineralogy (petrology): The locality where the type specimen was found. Keilite (mineral) = Abee meteorite (source), tonalite (Q650147) = Tonale Pass (Q944457) |
Proposed by | Gaurav(talk) 18:03, 14 February 2013 (UTC) |
- Comments: Makes most sense from species on downward. There are different types of types (holotype, paratype, lectotype).
- Note that a paratype is not a type. - Brya (talk) 15:51, 18 August 2013 (UTC)
- Not sure how useful this would be. I tried to expand this into a "type specimen" property, but then you have to deal with type series. --Gaurav(talk) 18:03, 14 February 2013 (UTC)
- Support - but should be general enough to work for other sciences that use type specimen, type localities or type material (e.g. meteorites: type specimen nakhlites is nakhla meteorite; Stratigraphy: Type sections define a unit; Isotope sciences: Type material for Sulfur is Canyon Diablo Troilite). --Tobias1984 (talk) 08:31, 4 May 2013 (UTC)
- Comment - the Datatype should probably be changed to item. Most of the time it will be museum that already has an item. --Tobias1984 (talk) 08:33, 4 May 2013 (UTC)
- Comment - I modified the request to be more general. We could also split it into "type locality" and "type material" if we want only links to institutions in the one and only the material/section/etc.. in the other. --Tobias1984 (talk) 18:59, 11 May 2013 (UTC)
- Splitting it into type locality and type material sounds like a good idea to me. - Soulkeeper (talk) 20:49, 14 August 2013 (UTC)
- Discussion after proposal was split
- Support proposal split into type locality and type specimen. --Tobias1984 (talk) 14:11, 16 August 2013 (UTC)
- Comment In most cases the type specimen will not have it's own item; it will be one of the properties of the species/mineral etc. This means the location of the type specimen is better described using a qualifier to the "Type Specimen" property. Wouldn't P766 (P766) (in a museum) and located in/on physical feature (P706) and located in the administrative territorial entity (P131) be better properties for this? Filceolaire (talk) 14:34, 21 August 2013 (UTC)
- The location of the type is dealt with in the request below ("type"), so all these comments belong there also? - Brya (talk) 17:29, 21 August 2013 (UTC)
- Oppose. we should use existing properties in qualifiers to the 'Type specimen' property below as this location is purely related to this type specimen. If we had two type specimens then the location would have to be in a qualifier anyway, else we could not tell which specimen was from which location. Filceolaire (talk) 00:42, 24 August 2013 (UTC)
- Again, the location of the type specimen can be hundreds (thousands) of miles distant from the type locality. - Brya (talk) 10:23, 25 August 2013 (UTC)
@Gaurav, Brya, Tobias1984, Soulkeeper, Filceolaire.
Not done Consensus not reached. Use location of discovery (P189) instead.--Micru (talk) 19:40, 22 November 2013 (UTC)
main food source
Description | the property describes what a plant or animal eats. the direction is predator ---> prey. the link should always go to the most specific subdivision. So instead of saying a certain species of bird eats seeds, it should list all the specific seeds. Queries for "birds that eat seeds" should return said bird and list the seeds that it eats. |
---|---|
Data type | Item |
Template parameter | ? |
Domain | GND:term. |
Allowed values | animal/plant species and groups |
Example | koala = the species of eucalyptus that it eats, panda = bamboo (and the other stuff they eat), european bee-eater = bees, wasps, bumblebees, flying beetles, dragonflies, ... |
Source | relevant scientific literature |
Robot and gadget jobs | ? |
Proposed by | Tobias1984 (talk) |
- Discussion
- Wikidata could generate food chains with this property. A lot of interesting queries would open up. Tobias1984 (talk) 12:54, 10 May 2013 (UTC)
- Comment I think a general property distinguishing between carnivore, herbivore, omnivore, etc. is enough. Koalas and Pandas are quite an exception when it comes to food. —★PοωερZtalk 14:13, 10 May 2013 (UTC)
- I think most animals have a small set of other things they eat. I don't know if Koalas and Pandas are a big exception. There are also many insects that have favorite plants they eat. We could also make the food chain a little simpler and just say things like phytoplankton is autotroph, fish eat phytoplankton and shark eats fish for example. --Tobias1984 (talk) 14:39, 10 May 2013 (UTC)
- How about a "main food(s)" property? For example, penguin species A eats mostly fish species 1, and sometimes fish species 2, while penguin species B eats mainly fish species 2 and sometimes fish species 3 or 4, etc. - Soulkeeper (talk) 14:42, 10 May 2013 (UTC)
- Comment - I think that would be the way to go. Those would be some awesome queries for biologists. I would say the more detail we can put into it the better. --Tobias1984 (talk) 16:58, 14 May 2013 (UTC)
- How about a "main food(s)" property? For example, penguin species A eats mostly fish species 1, and sometimes fish species 2, while penguin species B eats mainly fish species 2 and sometimes fish species 3 or 4, etc. - Soulkeeper (talk) 14:42, 10 May 2013 (UTC)
- Question I think that 'food chain' gives the impression of identifying which food chain a taxon is part of. If the goal is to indicate the taxon's food source, then that would make a better label. Also, is this to cover their naturally-occurring preferred food sources that they eat in their natural environment, or is this the type of food they 'can' eat (a potentially much larger set)? i.e. would dog 'food source' Alpo be appropriate? Joshbaumgartner (talk) 06:51, 13 May 2013 (UTC)
- Comment - Good question. Domesticated dogs fall more in the realm of culture. Probably good to keep that separate. I changed the name to reflect that. --Tobias1984 (talk) 16:58, 14 May 2013 (UTC)
- Support. Very useful piece of information. Filceolaire (talk) 14:51, 21 August 2013 (UTC)
- It was proposed a while back that edibility (P789) be used together with species qualifiers to show which foods can be eaten by which species. Would such data make the data supplied by the property proposed here redundant (or vice versa)? --Yair rand (talk) 04:10, 15 October 2013 (UTC)
- Support But would suggest something a name like 'major [or main] food source' Macadamia1472 (talk) 05:44, 16 October 2013 (UTC)
@Tobias1984, 23PowerZ, Soulkeeper, Joshbaumgartner, Filceolaire, Yair rand, Macadamia1472:
Done--Micru (talk) 19:27, 22 November 2013 (UTC)
Homonymous taxon
Description | When two taxa are honomymous they can link to each other using this property. |
---|---|
Data type | Item |
Template parameter | NA |
Domain | term |
Allowed values | taxa |
Example | Q1840191 Myrmarachne attenuata (Karsch) <=> Q2502351 Myrmarachne attenuata (Cambridge) |
Proposed by | Soulkeeper (talk) 20:49, 14 August 2013 (UTC) |
- Discussion
Support--Micru (talk) 13:08, 15 August 2013 (UTC)
- Not sure. There are at least three kinds of 'homonyms'; this runs the risk of confusing them? - Brya (talk) 05:33, 16 August 2013 (UTC)
- Maybe that can be solved with qualifiers: Instance of nomen oblitum, etc.
? But then there's potential confusion about which taxon the qualifier applies to.on the taxon name. - Soulkeeper (talk) 10:25, 16 August 2013 (UTC)
- Maybe that can be solved with qualifiers: Instance of nomen oblitum, etc.
- Support --Tobias1984 (talk) 20:07, 7 September 2013 (UTC)
- What do we gain by classifying same-named (but different) taxa as such? It seems to me that such are simply curiosities—in the ideal world, no species would be named the same as another... --Izno (talk) 23:37, 13 September 2013 (UTC)
- While homonyms are seldom in biology, they are common in other fields - search for "Michael Smith". Wikidata uses the description field just to keep them apart for human readers. From the model point of view homonyms are not treated special. I think we should follow this rule in biology also. Homonyms just exist, no extra property required. — Felix Reimann (talk) 11:42, 25 September 2013 (UTC)
- Oppose Such a property as no benefit in modeling taxa, because we have taxon author (P405) and year of publication of scientific name for taxon (P574) and - assuming the worst case - the posibillity to add a full reference to the original publication to distinguish them. --Succu (talk) 22:10, 7 November 2013 (UTC)
Not done Not that useful.--Micru (talk) 18:25, 22 November 2013 (UTC)
Appearence
Description | description of chemical at 25°C and 1 atm: odour, colour, phase,... |
---|---|
Data type | Multilingual text (not available yet) |
Template parameter | fr:infobox chimie, en:chembox, de:Chemikalien |
Domain | chemistry, biology, mineralogy |
Allowed values | text |
Proposed by | Snipre (talk) 12:12, 8 July 2013 (UTC) |
- Discussion
- Comment - but we could make items for odours and already have items for colours. Some odours could hold statements of which molecules are characteristic for them. Same goes for taste. An item for "salty" could hold neurology-related statements like "receptor = Na+ receptor" and "place of reception = tongue". --Tobias1984 (talk) 18:17, 8 July 2013 (UTC)
- I am a little afraid that we can't define all characteristics by existing items. Could we really create some "amine odor" or "fish odor" item ? Snipre (talk) 09:45, 29 July 2013 (UTC)
- Maybe we should do both. A text field for a human readable description and items for machine readability. But I think that items for odors (and subconscious olfactory odors) will appear sooner or later. We could build fancy crosslinks like:
- fish
- smell ( amine odor )
- amine odor
- made from (amine (Q167198))
- reaction in humans (nausea (Q186889) & disgust (Q208351))
- molecular receptor (biogenic amine receptor (Q4914844))
- But regarding this proposal I think it will be good to make the simple solution first Support --Tobias1984 (talk) 10:41, 29 July 2013 (UTC)
- Maybe we should do both. A text field for a human readable description and items for machine readability. But I think that items for odors (and subconscious olfactory odors) will appear sooner or later. We could build fancy crosslinks like:
- I am a little afraid that we can't define all characteristics by existing items. Could we really create some "amine odor" or "fish odor" item ? Snipre (talk) 09:45, 29 July 2013 (UTC)
- Oppose - This proposal is really quite subjective. Also, Wikidata is not an encyclopedia. --Jakob (Scream about the things I've broken) 15:25, 15 August 2013 (UTC)
- The description itself is not overly subjective, and we anyway need to state what the sources say. But if you think a string is inappropriate we could go with a series of item-datatype properties (as the above example). Appearance is just the combination of a few material properties. I think we could describe any material with 10 to 20 properties with item-datatype. I will try to think of a list. --Tobias1984 (talk) 09:15, 16 August 2013 (UTC)
- Odor, color, taste are part of the msds (see for example this, an official document for all sold chemicals, so if there a small part of subjectivity there are clearly some references. Snipre (talk) 08:00, 18 August 2013 (UTC)
- Er, anyway, can't we just use the description section to describe an item's appearance? --Jakob (Scream about the things I've broken) 21:43, 25 August 2013 (UTC)
- No, how do you want to distinguish between terms used for appearance and structural or classification terms ? Snipre (talk) 09:18, 16 September 2013 (UTC)
- Er, anyway, can't we just use the description section to describe an item's appearance? --Jakob (Scream about the things I've broken) 21:43, 25 August 2013 (UTC)
- Odor, color, taste are part of the msds (see for example this, an official document for all sold chemicals, so if there a small part of subjectivity there are clearly some references. Snipre (talk) 08:00, 18 August 2013 (UTC)
- The description itself is not overly subjective, and we anyway need to state what the sources say. But if you think a string is inappropriate we could go with a series of item-datatype properties (as the above example). Appearance is just the combination of a few material properties. I think we could describe any material with 10 to 20 properties with item-datatype. I will try to think of a list. --Tobias1984 (talk) 09:15, 16 August 2013 (UTC)
- Support with items for odours etc. The advantage of items is that they can come with translations into other languages for the name. We are only talking about the odours listed in the msds having items - not every conceivable smell. Filceolaire (talk) 10:00, 25 August 2013 (UTC)
@Snipre, Tobias1984, Jakob, Filceolaire:
Not done While the property might be useful with the datatype item, it lacks a controlled vocabulary to refer to. If it does exist, it can be reconsidered.--Micru (talk) 19:15, 22 November 2013 (UTC)
GHS signal word
Description | GHS signal words |
---|---|
Data type | Item |
Template parameter | fr:infobox chimie, en:chembox, de:Chemikalien |
Domain | chemistry |
Allowed values | warning, danger, - |
Example | sodium azide (Q407577) = danger |
Source | EU database |
Proposed by | Snipre (talk) 22:10, 9 July 2013 (UTC) |
- Discussion
-
- Support --Tobias1984 (talk) 08:45, 19 July 2013 (UTC)
- Support --Leyo 21:27, 28 July 2013 (UTC)
- Support but Comment Since there are only 2 signal words (danger and warning) we could just use two items and implement translation once, not translate "danger" or "warning" to every language on every chemical we define. Macadamia1472 (talk) 06:26, 16 October 2013 (UTC)
- Support But with the change that Macadamia1472 suggestedd. --Jakob (Scream about the things I've broken) 14:26, 5 November 2013 (UTC)
@Snipre, Tobias1984, Leyo, Macadamia1472, Jakob:
Done Changed type to item as suggested. Please use Q15221216 and danger (Q15221217) as signal words.--Micru (talk) 18:33, 22 November 2013 (UTC)
- Thanks, but why did you add
(used by P1033)
? --Leyo 20:18, 23 November 2013 (UTC)
Digital Rights Management system / Kopierschutz
Description | with which technology or software a product would be protected |
---|---|
Data type | Item |
Template parameter | de:Vorlage:Infobox Computer- und Videospiel Kopierschutz |
Domain | software and video games |
Allowed values | integer |
Example | NBA Live (Q48854)=>SafeDisc (Q1753835) |
Source | en:Category:Digital rights management systems |
Robot and gadget jobs | possible, using german wikipedia |
Proposed by | #Reaper (talk) |
I think everything should be clear. --#Reaper (talk) 20:21, 8 April 2013 (UTC)
- Support --Toru10 (talk) 17:00, 9 April 2013 (UTC)
- Comment is this property really applicable ? there is in general not a single way of releasing a creative work, some might have DRM, some might not have. It is not a feature of a creative work, it is a feature of one realease of some creative work (it can even depend on the distributing website) ... TomT0m (talk) 17:12, 9 April 2013 (UTC)
- This is the software section of creative works. Like the documentation above says, this property would be used mostly for software (video games).--CENNOXX (talk) 18:52, 9 April 2013 (UTC)
- I missed that, the notice is not clear, but it's true for software and video games as well as music or other kind of creative work. TomT0m (talk) 19:06, 9 April 2013 (UTC)
- Ah, ok, thats right. Then this property would only fit to software products, there normally would only one type/software of DRM be used. I corrected the domain. --#Reaper (talk) 14:23, 14 April 2013 (UTC)
- I missed that, the notice is not clear, but it's true for software and video games as well as music or other kind of creative work. TomT0m (talk) 19:06, 9 April 2013 (UTC)
- This is the software section of creative works. Like the documentation above says, this property would be used mostly for software (video games).--CENNOXX (talk) 18:52, 9 April 2013 (UTC)
- Comment examples are missing. What kind of items will this link to? --Tobias1984 (talk) 12:59, 4 August 2013 (UTC)
- I have added some examples. I think now it is ready to be created.--Micru (talk) 05:04, 17 August 2013 (UTC)
- Oppose creation. Maybe go for a more semantic title: "has digital right management system", "hat Kopierschutz". Also the new examples show that TomT0m's concerns apply. Computer games come out in so many different forms including download versions. The statement should only go with editions and not creative works. --Tobias1984 (talk) 09:43, 17 August 2013 (UTC)
- Comment Title changed accordingly.--Micru (talk) 19:33, 4 September 2013 (UTC)
- Hi there. Currently I'm not really sure how to use this property. The first example which has been added is in an other way as I though before. For Half-Life my opinion was "Steam" as the software (like example two), but product key (Q1268470) does seems to be correct as well. But otherwise product key (Q1268470) as value seems to be to "general" / to simple, too: Which protected game or software wouldn't be protected using a license key? What do you mean? Best regards, --#Reaper (talk) 15:41, 8 September 2013 (UTC)
- Comment Title changed accordingly.--Micru (talk) 19:33, 4 September 2013 (UTC)
- Oppose creation. Maybe go for a more semantic title: "has digital right management system", "hat Kopierschutz". Also the new examples show that TomT0m's concerns apply. Computer games come out in so many different forms including download versions. The statement should only go with editions and not creative works. --Tobias1984 (talk) 09:43, 17 August 2013 (UTC)
- I have added some examples. I think now it is ready to be created.--Micru (talk) 05:04, 17 August 2013 (UTC)
- Support Filceolaire (talk) 10:34, 17 August 2013 (UTC)
- Support Danrok (talk) 17:12, 28 August 2013 (UTC)
- Neutral I would support 'Digital Rights Management system" (note the capitalisation) as the leading 'has' implies that it is a boolean, which it is not. I would also only support it if it was only used to identify specific systems i.e. 'SafeDisc' not generic techniques such as 'product key' because as mentioned by Reaper35 practically every piece of commercial software has a licence key Macadamia1472 (talk) 07:53, 15 October 2013 (UTC)
- I have removed the product key example. A product key isn't a DRM system. --Danrok (talk) 12:34, 15 October 2013 (UTC)
- I think that this "digital rights management" (or "digital restrictions management") property should only apply to software (and maybe file formats?). πr2 (t • c) 02:14, 16 November 2013 (UTC)
@#Reaper, Toru10, TomT0m, CennoxX, Filceolaire, Danrok, Macadamia1472, PiRSquared17
Done--Micru (talk) 17:45, 22 November 2013 (UTC)
Film editor
Description | The film editor works with the raw footage, selecting shots and combining them into sequences to create a finished motion picture. |
---|---|
Data type | Item |
Template parameter | Infobox film : editing (Schnitt for dewiki) |
Domain | film, profession (person ?) |
Allowed values | items |
Example | Schindler's List => Michael Kahn |
Source | Infobox film (en) |
Robot and gadget jobs | Could be imported from English and German Wikipedia |
Proposed by | Okki (talk) |
- Discussion
We already have the cinematographer, but we lack the film editor, which is equally important. Okki (talk) 09:36, 29 October 2013 (UTC)
- Support (the only alternative solution I see would be creator (P170) + qualifier, but that would not be very convenient. --Zolo (talk) 20:58, 18 November 2013 (UTC)
- Support --Micru (talk) 17:46, 22 November 2013 (UTC)
- Support Pikolas (talk) 14:20, 23 November 2013 (UTC)
Done--Micru (talk) 17:59, 23 November 2013 (UTC)
page type / Seitentyp / /
Description | Type of Wikipedia page, in case of template, category, disambiguation, list, or other "non-item" pages. Can take "disambiguation page" over from P107. |
---|---|
Data type | Item |
Domain | everything, but only for certain Wikipedia page types |
Allowed values | template, category, disambiguation, list (potentially more) |
Example | any disambiguation page => |
Source | Wikipedia |
Robot and gadget jobs | Could be bot-maintained, to some degree |
Proposed by | Magnus Manske (talk) 15:53, 20 March 2013 (UTC) |
- Support Allen4names (talk) 17:17, 20 March 2013 (UTC)
- Oppose This property would be redundant with instance of (P31), or, perhaps more technically, subclass of (P279). One of the best features of those properties is that they are extensible ways to define an item's membership in a class. Because of that, there is no need to create new properties for different types of items. One could just say 'Object (Q2011843) instance of Wikipedia disambiguation page'. Emw (talk) 02:01, 21 March 2013 (UTC)
- Comment instance of refers to the item described on the Wikipedia page, not the Wikipedia page itself. P31/P279 sometimes referring to the described item, sometimes to the page itself, introduces ambiguity that will come back and bite us later. This would also be a subclass of "Template", no? --Magnus Manske (talk) 08:59, 21 March 2013 (UTC)
- The Wikipedia page itself is a thing that's being described by a Wikidata item, so I don't see an ontological difference that causes P31 or P279 to not apply there. Yes, Template_(word_processing) (Q3307269) would be a subclass of "Template" (a kind of software), but a Wikipedia disambiguation page Template (Q4167410) seems like would be an instance or subclass of, say, Wikipedia:Disambiguation (Q4167410) just the same. I see the ambiguity as resolvable by simply inspecting the statement's object to see if the item is an instance or subclass of a class of Wikipedia page, just like resolving any other item's type. Emw (talk) 03:14, 22 March 2013 (UTC)
- Support per Magnus Manske. Macadamia1472 (talk) 09:40, 16 October 2013 (UTC)
- The Wikipedia page itself is a thing that's being described by a Wikidata item, so I don't see an ontological difference that causes P31 or P279 to not apply there. Yes, Template_(word_processing) (Q3307269) would be a subclass of "Template" (a kind of software), but a Wikipedia disambiguation page Template (Q4167410) seems like would be an instance or subclass of, say, Wikipedia:Disambiguation (Q4167410) just the same. I see the ambiguity as resolvable by simply inspecting the statement's object to see if the item is an instance or subclass of a class of Wikipedia page, just like resolving any other item's type. Emw (talk) 03:14, 22 March 2013 (UTC)
- Comment instance of refers to the item described on the Wikipedia page, not the Wikipedia page itself. P31/P279 sometimes referring to the described item, sometimes to the page itself, introduces ambiguity that will come back and bite us later. This would also be a subclass of "Template", no? --Magnus Manske (talk) 08:59, 21 March 2013 (UTC)
Not done On this RFC it has been stated that there is the wish of merging items that now are linked with categories to items that now are linked only to articles. When that happens this property would become useless.--Micru (talk) 17:42, 23 November 2013 (UTC)
is grapheme of / est un graphème de
Description | instead of "is instance of" <Latin script letter> or "is instance of" <Canadian aboriginal syllabics syllable> it would be useful to have a specific property for a relation between graphemes (letters, syllables, etc.) and the script/writing systems they belong to. This property could also be used between graphemes and language orthographies or other, like Q1493494 Pan-Nigerian alphabet or Q1271025 Lithuanian alphabet. |
---|---|
Data type | Item |
Template parameter | not known at the moment |
Domain | type of items that may have this property |
Allowed values | linked items should be graphemes and scripts/writing systems |
Example | Q9659 "A" is a grapheme of Q41670 "Latin script" |
Source | There are various articles, templates and categories for these. Unicode or CLDR data could also be used for this. |
Robot and gadget jobs | bots could collect the data from w:fr:Modèle:Palette Alphabet latin, other templates w:fr:Catégorie:Palette de navigation alphabet, or categories like w:fr:Catégorie:Lettre latine or w:en:Category:Latin letters and parent/sibling categories. Unicode or CLDR data could be collected for these. |
Proposed by | Moyogo (talk) 08:27, 21 March 2013 (UTC) |
- Question
OpposeIt seems instance of (P31) and subclass of (P279) -- or at least the rdf:type and rdfs:subClassOf relations they are synonymous with -- were sufficient in a very similar project of the General Ontology for Linguistic Description community; see e.g. https://github.com/sofarrar/e-linguistics/tree/master/goldcomm/gold/cope/oats. Given that, this proposed property seems redundant with at least P31. (I like the idea of classifying graphemes on Wikidata, though!) Emw (talk) 03:42, 22 March 2013 (UTC)- Hmm, the letter A is not an instance of Latin Script, it's an element of it. I'm not sure "subclass of" is appropriate either (the English alphabet is a subclass of the Latin script, A is not a subclass of the Latin script). I can see how a "grapheme" property might be too specific, but "element of" would be more appropriate. The original request was done because Q7770981 ("Latin alphabet letter", which should have been "Latin script letter") was deleted, I had created it to have <A> "instance of" <Latin script letter>. Am I misunderstanding something? --Moyogo (talk) 20:04, 22 March 2013 (UTC)
- That's a good point. I would phrase 'element of' slightly differently -- the letter A is part of (P361) Latin script. The resource I linked from the General Ontology for Linguistic Description classifies niche writing systems, but I think the same properties are applicable to more common writing systems like Latin. Consider how they ontologized a letter from the Maninka language language (which they title 'maninka-kan'):
- Hmm, the letter A is not an instance of Latin Script, it's an element of it. I'm not sure "subclass of" is appropriate either (the English alphabet is a subclass of the Latin script, A is not a subclass of the Latin script). I can see how a "grapheme" property might be too specific, but "element of" would be more appropriate. The original request was done because Q7770981 ("Latin alphabet letter", which should have been "Latin script letter") was deleted, I had created it to have <A> "instance of" <Latin script letter>. Am I misunderstanding something? --Moyogo (talk) 20:04, 22 March 2013 (UTC)
<rdf:Description rdf:about="http://linguistics-ontology.org/ns/scriptemes/mwk_ɔ">
<rdf:type rdf:resource="http://linguistics-ontology.org/ns/scriptemes/Scripteme"/>
<_3:hasCanonicalForm>ɔ</_3:hasCanonicalForm>
<_4:hasGraphemes rdf:resource="http://linguistics-ontology.org/ns/graphemes/0254"/>
<_6:hasExtraInformation>maninka-kan</_6:hasExtraInformation>
</rdf:Description>
- That's from https://raw.github.com/sofarrar/e-linguistics/master/goldcomm/gold/cope/oats/output.rdf. That rdf:Description element is analogous to a Wikidata item. Since rdf:type is closest to instance of (P31), it's clear that that property was used widely throughout that grapheme/scripteme classification document. So, returning back to the question of whether the letter A is an instance of Latin script, it seems it is. It's probably worth noting that the Maninka transcription system is its own rdf:Description element (/ potential Wikidata item):
<rdf:Description rdf:about="http://linguistics-ontology.org/ns/phonetics/129_mwk">
<rdf:type rdf:resource="http://linguistics-ontology.org/ns/phonetics/TranscriptionSystem"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_ɔ"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_ɲ"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_c"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_h"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_e"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_w"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_r"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_f"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_k"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_t"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_n"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_y"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_gb"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_u"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_b"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_p"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_d"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_o"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_l"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_j"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_ɛ"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_g"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_s"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_m"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_i"/>
<_6:hasScriptemes rdf:resource="http://linguistics-ontology.org/ns/scriptemes/mwk_a"/>
<_3:Title>maninka-kan</_3:Title>
</rdf:Description>
- Given that, it seems reasonable that the Latin script (i.e. the Latin writing system) could be its own rdf:Description element (Wikidata item) too. As shown in that resource from the General Ontology for Linguistic Description (GOLD), the 'instance of' property plays an important role.
- But this property is about how to specify the writing system that a grapheme (/scripteme) is a member of. The property used for that by GOLD -- hasExtraInformation -- seems like it could be much better worded. Something like 'is grapheme of' seems like it would be such a better wording, and I think I've established how such a property would actually not be redundant with 'instance of' (since 'A' would be an instance of 'grapheme' or 'scripteme'). What do you think? Emw (talk) 02:13, 23 March 2013 (UTC)
- GOLD is doing some interesting things, in the example maninka-kan has several scriptemes of which mwk_ɔ, mwk_ɔ itself has the grapheme ɔ, and there is also a mapping between mwk_ɔ and ipa_ɔ. There's a graph modeling this in [1]. I'm confused as to what that should be here. --Moyogo (talk) 10:50, 23 March 2013 (UTC)
- Couldn't part of (P361) do this job? Filceolaire (talk) 22:00, 4 September 2013 (UTC)
Not done No consensus.--Micru (talk) 17:37, 23 November 2013 (UTC)
contains part of administrative unit (en)
Description | (list of) lower-level units wich are partly included in the administrative unit |
---|---|
Data type | as of contains the administrative territorial entity (P150)-invalid datatype (not in Module:i18n/datatype) |
Template parameter | as of contains the administrative territorial entity (P150) |
Domain | as of contains the administrative territorial entity (P150) |
Allowed values | as of contains the administrative territorial entity (P150) |
Example | Prague 10 (Q2444921) => Vinohrady (Q662985), Strašnice (Q2297365), Záběhlice (Q3499406), Malešice (Q3490702), Hrdlořezy (Q2533951), Hloubětín (Q2320562), Michle (Q2623877), Žižkov (Q378120) |
Format and edit filter validation | as of contains the administrative territorial entity (P150) |
Source | as of contains the administrative territorial entity (P150) |
Robot and gadget jobs | search for non-assemblable units (units which are linked by P150 from two or more units or which have P131 with two or more links) |
Proposed by | ŠJů (talk) 23:34, 12 August 2013 (UTC) |
- Discussion
Alternative of contains the administrative territorial entity (P150) for non-assemblable subdivision.
- Wikidata talk:Country subdivision task force#Assemblability of administrative units
- Wikidata:Project chat#A Q about geographic inheritance
Support Filceolaire (talk) 23:06, 18 August 2013 (UTC)Oppose Use contains the administrative territorial entity (P150) with qualifier applies to part, aspect, or form (P518). Filceolaire (talk) 18:07, 10 October 2013 (UTC)- No, per my reasonings at the deletion request for P150. --Izno (talk) 14:39, 2 September 2013 (UTC)
Not done Consensus not reached.--Micru (talk) 17:34, 23 November 2013 (UTC)
partly is in the administrative unit (en)
Description | part of the item is located on the territory of the following administrative unit |
---|---|
Data type | as of located in the administrative territorial entity (P131)-invalid datatype (not in Module:i18n/datatype) |
Template parameter | as of located in the administrative territorial entity (P131) |
Domain | as of located in the administrative territorial entity (P131) |
Allowed values | as of located in the administrative territorial entity (P131) |
Example | Vinohrady (Q662985) => Prague 2 (Q2444636), Prague 3 (Q2598899), Prague 10 (Q2444921), Prague 1 (Q973974), Prague 4 (Q2686587) |
Format and edit filter validation | as of located in the administrative territorial entity (P131) |
Source | as of located in the administrative territorial entity (P131) |
Robot and gadget jobs | search for non-assemblable units (units which are linked by P150 from two or more units or which have P131 with two or more links) |
Proposed by | ŠJů (talk) 23:34, 12 August 2013 (UTC) |
- Discussion
Alternative of located in the administrative territorial entity (P131) for non-assemblable subdivision.
- Wikidata talk:Country subdivision task force#Assemblability of administrative units
- Wikidata:Project chat#A Q about geographic inheritance
Support Filceolaire (talk) 23:08, 18 August 2013 (UTC)Oppose Use located in the administrative territorial entity (P131) with qualifier applies to part, aspect, or form (P518). Filceolaire (talk) 18:08, 10 October 2013 (UTC)- Very interesting thought!!! But it will be a h--l of a problem to find a good item for P518 in many cases. -- Lavallen (talk) 17:14, 12 October 2013 (UTC)
- That is an interesting thought. Any examples, Lavallen, that you can think of where this might be a viable or unviable solution? --Izno (talk) 00:55, 14 October 2013 (UTC)
- Lets take Skutskär (Q59052) as an example. It's partly located in Gävle Municipality (Q510010) (0,35 km2 and 699 persons) and Älvkarleby Municipality (Q59858) (3,08 km2 and 5767 persons as of 2010). I have no item to simply describe the Gälve-part of Skutskär, and no item to describe the Älvkarleby-part of Skutskär. It is also partly in Provinces: Uppland (Q203509) and Gästrikland (Q183459). The borders of the Provinces sometimes follow the borders of the municipalities and counties, but in this case, it does it only partly. The mansion of Fleräng is for example in "wrong" county compared with the province. The mansion itself is not a part of Q59052, but some of the buildings in it's neighbourhood is. The Geoshape of Skutskär is changing every five years, and currently I only have sources (maps) to describe it from 1990. It was divided between two municipalites, two counties and two provinces already 120 years ago, and it will be impossible to find those geoshapes.
- Hälledal (Q2118164) is an example in my nighbourhood. It's little absurd: 1 building, 2 persons and 0,02 km2 is located in Kramfors Municipality, the rest in Härnösand Municipality.
- The most complicated thing to describe is Stockholm urban area (Q94385) with 11 municipalities and two provinces. Localities 2010 (Q14907217) can be used as source for the numbers as of 2010, and you can find the maps here. (The maps are copyrighted, and wmse is today trying to make the goverment provide the goeshapes with a copyleft-compatible licence.)--- Lavallen (talk) 12:28, 14 October 2013 (UTC)
- That is an interesting thought. Any examples, Lavallen, that you can think of where this might be a viable or unviable solution? --Izno (talk) 00:55, 14 October 2013 (UTC)
- Very interesting thought!!! But it will be a h--l of a problem to find a good item for P518 in many cases. -- Lavallen (talk) 17:14, 12 October 2013 (UTC)
- Support Lavallentalk(block) 10:14, 2 September 2013 (UTC)
- An alternative would maybe be to have a property: "is in administrative unit (property-inheritance not applied)". -- Lavallentalk(block) 10:17, 2 September 2013 (UTC)
- I'm not sure this is necessary, as it does not give us any more information than the claim P131 does. --Izno (talk) 14:37, 2 September 2013 (UTC)
- Oppose Redundant, we can add two values to a p131 claim. --Jakob (Scream about the things I've broken) 00:39, 12 September 2013 (UTC)
- Yes, but it does not solve the problem with property-inheritance. -- Lavallentalk(block) 07:53, 12 September 2013 (UTC)
- Lavallen, remind me in the next couple of days to come back to our discussion. --Izno (talk) 03:24, 17 September 2013 (UTC)
- Yes, but it does not solve the problem with property-inheritance. -- Lavallentalk(block) 07:53, 12 September 2013 (UTC)
Not done Consensus not reached.--Micru (talk) 17:34, 23 November 2013 (UTC)
Parent Wikiproject (en)
Description | This property is for Wikiproject items. Many Wikiprojects have parent wikiproject like Wikiproject Sports is parent of Wikiproject Tennis. We will be able to connect wikiprojects by this property and will be able create directory of them. If this property gets community nod, I will propose same Daughter/Sister wikiproject properties. Also would propose Related Portal property. |
---|---|
Data type | Item |
Template parameter | no |
Domain | Wikiprojects items distinguished by instance of instance of (P31)=Wikipedia:WikiProject (Q4234303) |
Example | In WikiProject Tennis (Q5530169)==>Parent Wikiproject=WikiProject Sports (Q8001410) |
Source | Wikiprojects home page |
Proposed by | Nizil Shah (talk) 19:33, 2 September 2013 (UTC) |
- Discussion
- Comment could 'part of (P361)' do this job? Filceolaire (talk) 21:54, 4 September 2013 (UTC)
- "part of" is a multi purpose property. We would be able to specifically join Wikiprojects by this property or create directory. By different property we would be able to distinguished between properties for projects and other items. In that way even we can use "Parent/daughter" properties same way as "part of" property. What you think? -Nizil Shah (talk) 16:57, 7 September 2013 (UTC)
- Oppose - has to be more general. --Nightwish62 (talk) 18:19, 6 September 2013 (UTC)
- what do you mean by more general? Can you explain? Thanks and regards-Nizil Shah (talk) 16:57, 7 September 2013 (UTC)
- I think (s)he means "more general" like "a multi purpose property" per above. -- Lavallentalk(block) 07:50, 12 September 2013 (UTC)
- what do you mean by more general? Can you explain? Thanks and regards-Nizil Shah (talk) 16:57, 7 September 2013 (UTC)
- Oppose: The biggest problem with adding metadata like this (and this isn't the first time similar has been proposed) is that WikiProjects in some languages will have different parents/sisters/children than in others. --Izno (talk) 03:23, 17 September 2013 (UTC)
Not done Consensus not reached.--Micru (talk) 17:26, 23 November 2013 (UTC)
Self-references description
Description | used to avoid self-references |
---|---|
Data type | Multilingual text (not available yet) |
Example | male (Q6581097) => use with Property:P21 "sex", Q11651459 => used with Property:Instance of (P31) to indicate that the subject is about similar names or a disambiguation page (but this item is to be beleted) |
Proposed by | GZWDer (talk) |
- Discussion
Motivation. GZWDer (talk) 06:01, 26 September 2013 (UTC)
Not done Not enough support.--Micru (talk) 17:26, 23 November 2013 (UTC)
Work location (en)
Description | Commons:Template:Creator |
---|---|
Data type | Item |
Proposed by | GZWDer (talk) 10:48, 18 June 2013 (UTC) |
- Discussion
- Support Filceolaire (talk) 23:24, 18 August 2013 (UTC)
- Comment is this the location where the work was created? Danrok (talk) 22:16, 27 August 2013 (UTC)
- Support according to the description in the template which is "Location(s) where the creator was active." Danrok (talk) 21:38, 30 August 2013 (UTC)
address (en)
Description | voy:Template:Listing |
---|---|
Data type | Multilingual text (not available yet) |
Proposed by | GZWDer (talk) 10:39, 18 June 2013 (UTC) |
- Discussion
- Here I propose to use the string datatype because adresses are not really multilingual. Maybe we can also use different properties for the street, house number etc. --Pyfisch (talk) 05:39, 27 June 2013 (UTC)
- Support but change the datatype back to 'string'. Use qualifiers for 'transliteration', 'street' (if the street has an item). The item should have 'is in administrative unit' and 'geo-coordinates' too.
elevation (in meters)
Description | elevation of a geographical feature, e.g. a mountain peak, city etc. |
---|---|
Data type | Number (not available yet) |
Template parameter | "elevation", "elevation_m" and "elevation_ft" in Template:Infobox mountain |
Domain | place |
Allowed values | strings representing positive numbers (possibly fractional), followed by a unit |
Example | Mount Everest (Q513) => "8848 m"; La Paz (Q1491) => "11913 ft" |
Proposed by | Schneelocke (talk) 18:13, 10 August 2013 (UTC) |
- Discussion
- Suprised that something like this hasn't been discussed yet. I support it, even if it technically can be found in the coordinate-datatype. -- Lavallentalk(block) 19:40, 10 August 2013 (UTC)
- Oppose It would also be better to wait for the right datatype to appear, so we know what were dealing with and can try out different approaches in the sandbox. String is definitely not appropriate for this. Also we don't know how physical units are going to be attached to the number-datatype. To keep internal coherency of the data all entries in US-measurement systems should be forbidden because that usually means they were already converted and rounded once (all surveys work with SI-system), which increases the error when converting and rounding back to SI-system. --Tobias1984 (talk) 13:47, 11 August 2013 (UTC)
- Support. Datatype should be "Number (with dimension)". Where the source only gives the height in feet we should record that because that is what the source says. Filceolaire (talk) 20:05, 15 August 2013 (UTC)
- Support as is. Can be converted later if ever. -- Docu at 10:46, 24 August 2013 (UTC)
- Oppose You loose information if you enter elevation now. There's no float datatype at the moment, so wait a few weeks and then I'll give my Pro to this! --A.Bernhard (talk) 16:32, 4 October 2013 (UTC)
Not done New discussion to be started when the right datatype is available.--Micru (talk) 11:32, 24 November 2013 (UTC)
Sockets Supported
Description | The names of the sockets that the CPU was designed for. |
---|---|
Data type | Item |
Domain | CPU |
Example | Core2 Duo E8200 (Q15219262): LGA 775 (Q610702) |
Source | Intel website, for Intel processors |
Robot and gadget jobs | Robots can gather info on the Intel website and fill the property with it. |
Proposed by | MisterSanderson (talk) |
- Discussion
I want to add information to the CPU items, but there aren't enough properties to that. MisterSanderson(talk) 17:18, 21 November 2013 (UTC)
- Support I changed datatype to item, as in the example. --Tobias1984 (talk) 20:30, 21 November 2013 (UTC)
Done --Tobias1984 (talk) 16:09, 27 November 2013 (UTC)
ZDB identifier
Description | Identifier for journals by the German Union Catalogue of Serials (Q186844) (ZDB). Use if ISSN (P236) is not available. |
---|---|
Data type | String |
Template parameter | de:Vorlage:ZDB (1000+) |
Domain | work (journals) |
Example | Pubblicazioni della Società Italiana per la Ricerca dei Papiri Greci e Latini in Egitto = ZDB-ID 990976-x |
Source | ZDB (en) |
Proposed by | Kolja21 (talk) |
- Discussion
The names of journals are often ambiguous. The German Union Catalogue of Serials contains the names of more than 1.5 million serials worldwide. Kolja21 (talk) 00:11, 23 November 2013 (UTC)
- Support. Good one. Pikolas (talk) 01:47, 23 November 2013 (UTC)
- Support I18n (talk) 16:46, 27 November 2013 (UTC)
- Support John Vandenberg (talk) 11:14, 30 November 2013 (UTC)
Catholic Hierarchy ID (person)
Description | ID of the person on the Catholic Hierarchy website |
---|---|
Data type | String |
Template parameter | « ch » dans fr:Modèle:Infobox Prélat catholique |
Domain | personne |
Example | Benedict XVI (Q2494) => ratz |
Source | www.catholic-hierarchy.org |
Proposed by | — Ayack (talk) |
- Discussion
- Support--Micru (talk) 10:22, 5 December 2013 (UTC)
detection method / discovery method
Description | discovery method of an extrasolar planet |
---|---|
Data type | Item |
Template parameter | Template:Infobox planet discovery_method |
Domain | extrasolar planet |
Allowed values | a limited number of items as for example Doppler spectroscopy (Q2273386), transit method (Q2069919), transit-timing variation (Q2945337), gravitational microlensing (Q1028022), polarimetry (Q899381), astrometry (Q181505) |
Example | Kepler-41b (Q15114570) detection method transit method (Q2069919) |
Source | The Extrasolar Planets Encyclopaedia |
Proposed by | Paperoastro (talk) |
- Discussion
Infobox planet need this property. See this discussion for the decision to not use determination method or standard (P459). --Paperoastro (talk) 08:48, 27 November 2013 (UTC)
- Support. --Art-top (talk) 15:16, 27 November 2013 (UTC)
- Support — Ivan A. Krestinin (talk) 17:47, 27 November 2013 (UTC)
- Support Maybe it can be applied to more subjects.--Micru (talk) 18:22, 27 November 2013 (UTC)
- @Paperoastro, Art-top, Ivan A. Krestinin, Micru: Done, but since I accidently created this a few hours before the 7-day mark, more discussion is welcome.--Jakob (Scream about the things I've broken) 16:37, 3 December 2013 (UTC)
- Hi, Jakob. For me it is ok. ;-) --Paperoastro (talk) 18:02, 3 December 2013 (UTC)
chromosome
Description | the chromosome on which an entity is localized |
---|---|
Data type | Item |
Domain | any item that can be localized to a set of genomic coordinates, e.g. a gene (Q7187), sequence variant (Q15304597), etc |
Allowed values | any item for which subclass of (P279) chromosome (Q37748) is true |
Example | RELN (Q414043) chromosome human chromosome 7 (Q657319), rs267601217 (Q15304616) chromosome human chromosome 7 (Q657319), Reln (Q14331135) chromosomemouse chromosome 5 (Q15304656) |
Source | external reference, Wikipedia list article (either infobox or source) |
Robot and gadget jobs | To be populated by the Gene Wiki bot |
Proposed by | Emw (talk) |
- Discussion
We've got P643 (P643), but it should be of datatype 'item' instead of 'string'. Chromosomes are distinct objects that have properties like 'accession', 'length', etc. and would thus be better represented as items. Also, the property should not be explicitly tied to the UCSC Genome Browser. Genomic coordinates come from genome annotations (from e.g. RefSeq and Ensembl), which are then used by genome browsers like the one from UCSC. In other words, a specific genome annotation (e.g. RefSeq Homo sapiens Annotation Release 105, Ensembl release 74) and not a genome browser should be used as in source values for this property. Emw(talk) 20:51, 14 December 2013 (UTC)
- Support sounds like an improvement. --Tobias1984 (talk) 12:42, 15 December 2013 (UTC)
- Support definitely an improvement in my view... Cheers, Andrew Su (talk) 01:25, 17 December 2013 (UTC)
- WikiProject Molecular biology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Tobias1984 (talk) 18:13, 16 December 2013 (UTC)
- Support Looks good to me too. --Daniel Mietchen (talk) 14:06, 17 December 2013 (UTC)
- Support --Chinmay26 (talk) 17:04, 17 December 2013 (UTC)
- Support John Vandenberg (talk) 14:04, 23 December 2013 (UTC)
- Done --Tobias1984 (talk) 23:14, 24 December 2013 (UTC)
Austrian municipality number
Description | identifier for municipalities and Statutarstädte in Austria (also for the districts of Vienna) |
---|---|
Data type | String |
Template parameter | "Gemeindekennzahl" in de:Template:Infobox_Gemeinde_in_Österreich |
Domain | (administrative) type is municipality of Austria (Q667509), statutory city of Austria (Q262882), or district of Vienna (Q261023) |
Example | Q427008 => "32002" |
Format and edit filter validation | \d{5} |
Source | de:Amtlicher_Gemeindeschlüssel#.C3.96sterreichischer_Gemeindeschl.C3.BCssel:_Aufbau_der_Gemeindekennziffer_.28-kennzahl.29, [2], [3] |
Proposed by | Zuphilip (talk) |
- Discussion
Motivation: Wikidata:Country_subdivision_task_force/Austria. Zuphilip (talk) 13:23, 2 November 2013 (UTC)
Huch, it is already there Austrian municipality key (P964). Why haven't I found it? Well, I will add some more aliases and discuss some changes of the constraints there.... Sorry! --Zuphilip (talk) 13:55, 2 November 2013 (UTC)
Not done Duplicate.--Micru (talk) 12:56, 25 November 2013 (UTC)
SWB catalog (editions only)
Description | The identifier for an edition (a single book, CD etc.) in the catalog of the South-West German Library Network (Q1684093) (SWB). |
---|---|
Data type | String |
Domain | edition (see Wikidata:Books task force#Edition item properties) |
Example | Die natürlichen Pflanzenfamilien, 2nd edition (Q5805827) => 000619612 |
Source | SWB-Online Katalog |
Proposed by | Kolja21 (talk) |
- Discussion
- The SWB runs one of the main union catalogs in Europe. Kolja21 (talk) 21:01, 13 November 2013 (UTC)
- Support The library of the German Esperanto Association is located in the public library of the German town Aalen. They are part of SWB. It will be a great help to have edition references via this Wikidata property. לערי ריינהארט (talk) 22:13, 13 November 2013 (UTC)
- I think it is wise to call the property SWBedition reference. We should not mix abreviations between Wikidata and WMF projects. לערי ריינהארט (talk) 05:38, 19 November 2013 (UTC)
PSH
Description | id for authority database of czech technical library [4] |
---|---|
Data type | String |
Template parameter | MedieWiki_parameter_1 ({{{1}}}) in cs:template:PSH template calls |
Domain | objects, categories, terms |
Allowed values | numbers from the catalogue of technical library |
Example | {{PSH|5802}} at cs:Category:Fosfor, i. e. phosphorus (Q674) should have PSH value 5802 |
Source | [5], cs:special:Whatlinkshere/template:PSH |
Robot and gadget jobs | bots or gadgets can do do any task with this. List of available inputs in czech are at http://pshmanager.techlib.cz/psh_csv |
Proposed by | Limojoe (talk) |
- Discussion
Motivation. Get Polythematic Structured Subject Heading System into wikidata.Limojoe (talk) 17:02, 16 November 2013 (UTC)
- -- Support the first 500 categories at cs: linking to template:PSH seems a lot of work already done
- Support Pikolas (talk) 01:49, 23 November 2013 (UTC)
- Support And changed to string (even if it is a number, it is not used as such, but as identifier).--Micru (talk) 10:20, 5 December 2013 (UTC)
- Done --Jakob (Scream about the things I've broken) 18:04, 9 December 2013 (UTC)
IDEO Job id
- Discussion
Motivation: part of the Professions and Occupations Taskforce. Will help us reference frwiki pages by adding a link to the job page on ONISEP's website. Teolemon (talk) 13:15, 21 November 2013 (UTC)
- Support Pikolas (talk) 01:49, 23 November 2013 (UTC)
- Support I18n (talk) 16:45, 27 November 2013 (UTC)
- Done @Teolemon, @Pikolas, @I18n --Jakob (Scream about the things I've broken) 14:42, 30 November 2013 (UTC)
medical condition
Description | disease or physical ailment affecting an individual human or animal |
---|---|
Data type | Item |
Template parameter | "disability" in en:template:Infobox sportsperson; "name" on en:Template:Infobox disease |
Domain | instances of human (Q5) and animal (Q729) |
Allowed values | any subclass of (P279) health problem (Q15281399) |
Example | Petchara Chaowarat (Q6665137) => blindness (Q10874); Sarah Vinci (Q7422869) => spina bifida (Q844717) |
Robot and gadget jobs | I don't anticipate using automation to populate this property |
Proposed by | John Vandenberg (talk) |
- Discussion
Disabilities/impairment/medical conditions/differences are important parts of a persons identity, and sometimes are the basis for notability (such as Ed Roberts (Q537832). Disability is a core component of Paralympic sport data that I am working on, but I think that we should also plan to include other attributes such as colour blindness, and animal diseases, including injuries that can be recovered from such as Casino Drive (Q5048852) recovering from a stone bruise to race again. Also bear in mind that serious, 'permanent' impairments may be fully recovered from, such as Pat Rummerfield (Q7143978). This property may also be used in relation to military discharges for medical reasons.
There is also a related property that could be a qualifier, being the cause of impairment, which is sometimes 'birth' and could be annotated by the qualifier start date being equal to date of birth, or 'accident', and impairments can be the cause of other impairments. John Vandenberg (talk) 10:08, 29 November 2013 (UTC)
- Comment Why not to name it "medical condition" and use it for all cases?--Micru (talk) 10:20, 29 November 2013 (UTC)
- That name would be perfect. John Vandenberg (talk) 10:38, 29 November 2013 (UTC)
- Note I have found significant event (P793), which does what I need (but the property name isnt ideal) and I have used it on Kevin Coombs (Q6396063). John Vandenberg (talk) 16:56, 29 November 2013 (UTC)
- Support After name change. I agree that significant event (P793) is not ideal for these kind of use, specially if the person is born with the condition.--Micru (talk) 18:13, 30 November 2013 (UTC)
- Support and we already have has cause (P828) which is used as a regular property for diseases but would be a good qualifier for people. --Tobias1984 (talk) 15:39, 30 November 2013 (UTC)
- I think the 'possible' in has cause (P828) makes it inappropriate to use in this context. If we add 'cause' as a fact to a person, typically the exact cause has been determined. I'll start a discussion at Property talk:P828. However, maybe we don't need 'cause', as the medical condition typically indicates whether it was a acquired disorder (Q3621717) or a congenital disorder (Q727096). See Leanne Del Toso (Q6509847), where I have listed two significant events; one is a subclass of congenital and the other is a subclass of acquired - I don't know the relationship between these two conditions (and it could be that one of the sources is wrong :/). John Vandenberg (talk) 05:03, 3 December 2013 (UTC)
- Support -- Yiyi .... (talk!) 20:30, 30 November 2013 (UTC)
- Comment worth considering, airplanes and buildings can also have accidents. A property for airplane accidents was requested here. John Vandenberg (talk) 04:49, 3 December 2013 (UTC)
- Comment "Medical condition" is essentially "phenotype". http://www.human-phenotype-ontology.org has a lot of vocabulary on this. Has anyone taken a look at that? The Human Phenotype Ontology project: linking molecular biology and disease through phenotype data has more information. It'd be good to have our vocabulary align with theirs; my concern here is that we overlook useful precedents and semantically drift from professionally curated properties. Emw (talk) 05:05, 3 December 2013 (UTC)
- Hmm... not really. From my understanding of both words, phenotype is the physical representation of the genotype. A condition like downs syndrome (is that even a condition?) could be a phenotype, but something like cancer (if that's a condition) wouldn't be. If that make sense... Ajraddatz (Talk) 05:07, 3 December 2013 (UTC)
- Cancer is inherently genetic, so it would be a phenotype in that sense. It's worth noting that the Human Phenotype Ontology seems to interpret "phenotype" quite liberally, for example including concepts like Caesarean section. Emw (talk) 05:34, 3 December 2013 (UTC)
- Fair enough, actually. Didn't think about cancer that way. While the Human Phenotype Ontology might interpret it liberally, we don't need to by necessity - I know from my studies that a less liberal definition tends to be used, and it would be good to follow that trend I think. I don't have an opinion strongly one way, more that it seems weird to define something which isn't a (direct) result of the genotype as a phenotype. Ajraddatz (Talk) 06:03, 3 December 2013 (UTC)
- Ajraddatz, thinking about this a bit more, your original point is a good one -- saying "medical condition is essentially phenotype" as I did is an oversimplification at best. Many medical conditions are clearly not phenotypes (and many phenotypes are not medical conditions). Emw (talk) 13:40, 6 December 2013 (UTC)
- Fair enough, actually. Didn't think about cancer that way. While the Human Phenotype Ontology might interpret it liberally, we don't need to by necessity - I know from my studies that a less liberal definition tends to be used, and it would be good to follow that trend I think. I don't have an opinion strongly one way, more that it seems weird to define something which isn't a (direct) result of the genotype as a phenotype. Ajraddatz (Talk) 06:03, 3 December 2013 (UTC)
- Cancer is inherently genetic, so it would be a phenotype in that sense. It's worth noting that the Human Phenotype Ontology seems to interpret "phenotype" quite liberally, for example including concepts like Caesarean section. Emw (talk) 05:34, 3 December 2013 (UTC)
- Hmm... not really. From my understanding of both words, phenotype is the physical representation of the genotype. A condition like downs syndrome (is that even a condition?) could be a phenotype, but something like cancer (if that's a condition) wouldn't be. If that make sense... Ajraddatz (Talk) 05:07, 3 December 2013 (UTC)
- Thanks Emw and Ajraddatz for your helpful comments here. The far end of the spectrum is voluntary body modifications, for body functions either as a remedy (such as artificial pacemaker (Q372713)) or improvement (cyborg (Q235799)), or culture (tattooing (Q43006)), or psychological problems (body integrity identity disorder (Q890069)). i am no expert here (I only understand half of half the words), but I dont see any of these in the Human Phenotype Ontology. DBpedia has.tattoo, piercing, & disease (which includes amputations; see http://live.dbpedia.org/page/Arunima_Sinha). As I asked at w:Wikipedia_talk:WikiProject_Medicine#Wikidata_-_medical_condition_and_voluntary_body_modification: Is ICD10 L81.8 the code for a typical voluntary tattoo? Is there a code for horns (or, how to describe The Enigma (Q2411092))? ;-) John Vandenberg (talk) 10:35, 3 December 2013 (UTC)
- Not sure. I came here from and I would give input into these things but I still do not understand Wikidata properties or what sorts of opinions might be useful. Blue Rasberry (talk) 16:42, 5 December 2013 (UTC)
- Hi Bluerasberry. Wikidata has data items for medical conditions and procedures, with properties to classify them and link them to other medical terms and authorities. Wikidata doesnt have any properties to associate those medical procedures or conditions with a person. The most basic question in my head is whether body modification performed on a person that are voluntary and not in response to a medical diagnosis can (or should) be the part of the same relationship as those performed due to a medical diagnosis. Does a tattooing (Q43006) acquired for visual arts (Q36649) reasons belong in the same property as a hysterectomy (Q550675) in response to placenta accreta (Q517856)? They may seem very unrelated, but it becomes more controversial with breast augmentation (Q3866920), which can be a medical remedy or subjective reasons like aesthetic or performance reasons which I feel are fall under a inclusive fitness (Q1005215) taxonomy. The procedures possible now include nanotech and biotech, which can be performance enhancing (a growing concern for the Olympics), or function restoring (such as Jennifer French (Q15280440) winning gold medals after being paralyzed in a snowboarding accident causing a C6-7 incomplete spinal cord injury (Q1415275) and receiving a functional electrical stimulation (Q1327643) implant[6]), but as technology improves these implants will provide the person with greater performance than is natural (which turns Paralympics into a technology expo). Another question I havent yet mentioned is whether cause of death needs to be included, given than many conditions are terminal, but a person diagnosed with a terminal condition may die of something else, and again voluntary reasons come into play with euthanasia (Q100159). I am only interested in disabilities in sport, and lack the domain knowledge, but like Emw I want to avoid semantically drift from professionally curated properties, so I raise this other issues in the hope that we can find the right set of properties that are used by the appropriate set of professionals. John Vandenberg (talk) 05:13, 6 December 2013 (UTC)
- Support
CommentI would support this property if its 'domain' and 'allowed values' were updated. The domain is currently listed as "Domain: person (and animals), organization, & event". "Person (and animals)" is a decent domain, but it would be better (more precise) to say "instances of human (Q5) (and animal (Q729))" Also, organizations and events don't have medical conditions. The proposed 'allowed values' -- "items with a ICD-10 code" -- is also too restrictive. I think it would be better to update the 'allowed values' to 'any subclass of (P279) health problem (Q15281399)'. (Note that the ICD-10's official title is "International Statistical Classification of Diseases and Related Health Problems 10th Revision (ICD-10) Version for 2010".) All items that have an ICD-10 code should have fulfill the statement 'subclass of (P279) health problem (Q15281399)' (though it would likely be a more specific subclass and fulfill that statement by deduction). However, there may be medical conditions that have their own items that don't match/map to the ICD-10 -- e.g. by being terms from another classification -- which would still be valid values for 'medical condition'. Emw (talk) 13:32, 6 December 2013 (UTC)- I agree with removing organisations & events as they are not relevant here, and thank you for providing a better definition for the allowed values. I have made those modifications. John Vandenberg (talk) 14:23, 6 December 2013 (UTC)
- Supported. Thanks for shepherding this property through, John. I think it will be very valuable. Emw (talk) 01:21, 7 December 2013 (UTC)
- Created as Property:P1050. Sven Manguard Wha? 02:11, 7 December 2013 (UTC)
resource produced
Description | Used for mines, quarries and possibly industrial sites (Please discuss below) |
---|---|
Data type | Item |
Template parameter | e.g. Template:Infobox mine (Q6157431) "products =" |
Domain | chemical elements, metals, rocks, oil & gas (= natural resources) |
Example | Jaduguda Uranium Mine (Q15229130) = uranium (Q1098) Groningen gas field (Q2069152) = natural gas (Q40858) & qualifier for rock in which the resource is found Slochteren Formation (Q15229183) |
Format and edit filter validation | Constraint can include a list of resources that can be expanded as needed |
Source | Mostly various websites and some fact books. |
Robot and gadget jobs | Initial import of infobox Template:Infobox mine (Q6157431) |
Proposed by | Tobias1984 (talk) |
- Discussion
Improve items about mines. Tobias1984 (talk) 12:04, 25 November 2013 (UTC)
- Support--Micru (talk) 22:41, 25 November 2013 (UTC)
Another Example: Hyllestad quernstone quarries (Q11982659) produces quern-stone (Q1543947) and millstone (Q670985) --Tobias1984 (talk) 09:02, 19 December 2013 (UTC)
- Support Emw (talk) 17:27, 22 December 2013 (UTC)
- Oppose at the current proposition but agree for the concept. Better use a more general term like "product" which can be used for mines, but for other topics too like industrial site, compagnies,... Snipre (talk) 19:49, 22 December 2013 (UTC)
- @Snipre: Ok, lets go with "produces" and see where it goes after we have a few 1000 statements and a feeling for how people will use it. --Tobias1984 (talk) 19:56, 22 December 2013 (UTC)
- @Tobias1984, Micru, Emw, Snipre: Done as "produces". --Jakob (talk) 00:02, 23 December 2013 (UTC)
- Listed under Wikidata:List of properties/Organization instead is Wikidata:List of properties/Generic. --Jakob (talk) 00:08, 23 December 2013 (UTC)
NDL catalog (editions only)
Description | The identifier for an edition (a single book, CD etc.) in the catalog of the National Diet Library (Q477675). |
---|---|
Data type | String |
Domain | edition (see Wikidata:Books task force#Edition item properties) |
Example | The Master of Go (1973) (Q15231929) => Record ID No. 022977783 |
Source | NDL Search, NDL OPAC |
Proposed by | Kolja21 (talk) |
- Discussion
Till now we have only European and US library catalogs. Japan would be a good addition. Not to be confused with NDL Authority ID (P349). Kolja21 (talk) 04:28, 26 November 2013 (UTC)
- Support I18n (talk) 16:42, 27 November 2013 (UTC)
- Support --Micru (talk) 10:26, 5 December 2013 (UTC)
- @Kolja21, I18n, Micru: Done. --Jakob (Scream about the things I've broken) 20:17, 14 December 2013 (UTC)
NCL
Description | authority control number of the National Central Library (Q618340) (NCL) |
---|---|
Data type | String |
Template parameter | zh:Template:Authority control/NCL |
Domain | works |
Example | Wu Cheng'en (Q228889) => 000190369 |
Source | www.ncl.edu.tw, nbinet3.ncl.edu.tw |
Proposed by | Kolja21 (talk) |
- Discussion
Used by the Chinese Wikipedia. Not in VIAF. Kolja21 (talk) 08:18, 27 November 2013 (UTC)
- Support I18n (talk) 16:40, 27 November 2013 (UTC)
- Support --Micru (talk) 10:27, 5 December 2013 (UTC)
- Support. Emw (talk) 04:25, 3 January 2014 (UTC)
Portuguese Job Code CPP-2010
Description | Portuguese classification of occupations CPP-2010 maintained by the Portuguese iefp, with an established correspondance with the international ISCO standard. |
---|---|
Data type | String |
Template parameter | none so far |
Domain | profession (Q28640),occupation (Q13516667), jobs |
Allowed values | 5 digit number, with a period before the last one. |
Example | astronomer (Q11063) => 2111.2 |
Format and edit filter validation | 5 digit number, with a period before the last one. |
Source | http://www.iefp.pt/formacao/CNP/Paginas/CNP.aspx |
Robot and gadget jobs | Import from the official nomenclature using label matching would be welcome |
Proposed by | Teolemon (talk) |
- Discussion
Needed by the Occupation and Professions Taskforce. Teolemon (talk) 21:58, 29 November 2013 (UTC)
- Support Pikolas (talk) 13:13, 3 December 2013 (UTC)
- Support--Micru (talk) 10:18, 5 December 2013 (UTC)
- @Teolemon, Pikolas, Micru: Done --Jakob (Scream about the things I've broken) 23:10, 9 December 2013 (UTC)
Mathematics Genealogy Project
Description | Mathematics Genealogy Project (Q829984), http://www.genealogy.ams.org/id.php?id=xxx |
---|---|
Data type | String |
Allowed values | /d* |
Example | Alonzo Church (Q92741)=>8011 |
Proposed by | GZWDer (talk) |
- Discussion
Motivation. GZWDer (talk) 12:24, 26 December 2013 (UTC)
Does already exist: Mathematics Genealogy Project ID (P549)! -- Gymel (talk) 10:49, 28 December 2013 (UTC)
- closed.--GZWDer (talk) 13:55, 1 January 2014 (UTC)
ResearcherID
Description | an identifying system for scientific authors which was introduced in January 2008 by Thomson Reuters. Used in en:Template:Authority control. |
---|---|
Data type | String |
Example | Frederic Y. Bois (Q5497170) => E-9241-2012 |
Proposed by | GZWDer (talk) |
- Discussion
Motivation. GZWDer (talk) 16:07, 2 December 2013 (UTC)
- Support Definitely. Thanks for proposing this; you beat me to it. John Vandenberg (talk) 17:03, 2 December 2013 (UTC)
- Support Complementary with ORCID iD (P496).--Micru (talk) 10:33, 5 December 2013 (UTC)
- Support Pikolas (talk) 13:55, 11 December 2013 (UTC)
- @Pikolas, Micru, GZWDer, John Vandenberg: Done. If there's a link to be added to the AuthorityControl gadget, is it http://www.researcherid.com? Thanks, --Jakob (Scream about the things I've broken) 17:21, 13 December 2013 (UTC)
- Thanks Jakob; I have added an example of a link here and on Property talk:P1053. John Vandenberg (talk) 18:25, 13 December 2013 (UTC)
NLM ID
Description | Catalog of the United States National Library of Medicine (Q611833). |
---|---|
Data type | String |
Domain | creative work |
Example | The Journal of the American Medical Association (Q1470970) => 7501160 |
Source | external reference, Wikipedia list article (either infobox or source) |
Proposed by | John Vandenberg (talk) |
- Discussion
NLM is very comprehensive for many disciplines. It wasnt added to the infobox on enwp as it does not add much to the general reader w:Template talk:Infobox journal#Add NLM ID?, but wikidata can have all of them. A string will be an acceptable datatype. John Vandenberg (talk) 06:52, 5 December 2013 (UTC)
- Support good source. Addition to ISSN (P236) and ZDB ID (P1042). --Kolja21 (talk) 10:10, 5 December 2013 (UTC)
- Support as a string, but Oppose as an integer. --Jakob (Scream about the things I've broken) 14:55, 6 December 2013 (UTC)
- Changed to a string. Thx John Vandenberg (talk) 06:10, 7 December 2013 (UTC)
- Thanks for changing it. --Jakob (Scream about the things I've broken) 18:05, 9 December 2013 (UTC)
- Changed to a string. Thx John Vandenberg (talk) 06:10, 7 December 2013 (UTC)
fictional analog of
Description | used to link a class of items appearing in a creative work with the equivalent class of objects in the real word |
---|---|
Data type | élément-invalid datatype (not in Module:i18n/datatype) |
Domain | generic, every concept (class) used in a fiction (for example, a sword) |
Example | Example : Starship Enterprise (Q989888) is a subclass of <fictional spacecrafts>. This item, <fictional spacecraft> fictional equivalent of <spacecraft> |
Source | Référence externe, article de liste de Wikipédia (soit infobox, soit source) |
Proposed by | TomT0m (talk) |
- Discussion
Suppose we want to build a query to find all the instances of spacecrafts in Wikidata. We probably do not want to mix real spacecrafts such as the International Space Station and the Star Trek spacecrafts. This is a proposition to maintain a clear separation beetween the trees for those classes of items with keeping a connection beetween them. TomT0m (talk) 18:24, 22 December 2013 (UTC)
- Support sounds reasonable --Shisma (talk) 15:51, 27 December 2013 (UTC)
- Support The other day I was wondering how to link a fictional entity to it's type without including it in searches of the type. This is a good solution. --Arctic.gnome (talk) 15:12, 3 January 2014 (UTC)
- Support
CommentThe conventional way to declare that fictional entities are not (real) entities would be to state fictional entity (Q14897293) disjoint with entity (Q35120). This would entail that no instances of 'fictional entity' are instances of 'entity'. But I agree with TomT0m that we need a way to capture the fact that certain fictional entities are more or less similar to certain real entities.
- My only concern with this property is that "equivalent" does not merely imply a "link" or that two things are "more or less similar". "Equivalent" a strong word, and this property is capturing something looser. In English, we have a word for that: analog. I recommend changing the label of this property from 'fictional equivalent of' to 'fictional analog of'. If that were done then I would support this proposal. Other than that, I think this property is an excellent idea. Emw (talk) 14:53, 4 January 2014 (UTC)
- The same word exists in french, I changed the label. TomT0m (talk) 17:22, 8 January 2014 (UTC)
- TomT0m, thanks, supported. Emw (talk) 17:38, 18 January 2014 (UTC)
- The same word exists in french, I changed the label. TomT0m (talk) 17:22, 8 January 2014 (UTC)