Wikidata:Property proposal/Archive/5
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
Time zone / Zeitzone / Fuseau horaire
- Description: Time zone of the country
- Datatype: Item
- Domain: Places (countries and states)
- Allowed values: Time zones
- Source:
- Infobox parameter:
- Comments: --Stryn (talk) 07:03, 5 February 2013 (UTC)
- Support Of general interest. --Kolja21 (talk) 07:10, 5 February 2013 (UTC)
- Support Common infobox parameter for all places. Del♉sion23 (talk) 01:37, 6 February 2013 (UTC)
- Sure, but where do we add it ? probably not for every single village. --Zolo (talk) 07:55, 6 February 2013 (UTC)
- Comment This seems like something that the software should be able to handle for us with a little bit of coding, based off of specified geolocation coordinates.Sven Manguard Wha? 04:25, 7 February 2013 (UTC)
- Comment only for countries or states, provinces or other subsections with own timezones, not for counties, individual cities, islands, settlements, mountains, rivers, oceans, roads or landmarks.--Giftzwerg 88 (talk) 23:57, 9 February 2013 (UTC)
- Oppose, per Sven. This should be handled by the software. --Yair rand (talk) 11:39, 7 February 2013 (UTC)
- Oppose +1 for software, also I think Item is the wrong datatype. --Faux (talk) 19:43, 18 February 2013 (UTC)
- Comment actually timezone do not always follow coordinates (e.g. China, India...) etc. so I think the best solution is using a property rather than a quite complex parser for coordinates. --Vituzzu (talk) 13:32, 21 February 2013 (UTC)
- Support Cannot be "calculated". Time zones are determined by humans (political decisions), not coordinate data. Danrok (talk) 21:28, 23 February 2013 (UTC)
- Strong Support in some form. Agree that calculation is difficult if not impossible, and we can't make property decisions based on software "what-if"s! What type of item would this property take as a value that would capture the political time zone and daylight savings aspects? I was looking at the article en:tz database, which seems to have it down to a science. Could we use values based on that database's entities (a complex undertaking by the look of it)? Espeso (talk) 02:33, 24 February 2013 (UTC)
- Comment I think that goes beyond what's needed, looks like it is a method to determine what time it was, in given locations, at exact points in history. All we need are two fields; one for standard time, one for daylight saving (if there is one). For the United Kingdom the two values would be 0 and 1 which are the values for UTC adjustment. For China it would be 8 and null because they have unified time. Danrok (talk) 03:42, 24 February 2013 (UTC)
- ...and for the US there would be at least eleven options. I wonder if simply referring out to the identifer in the tz database would be the best approach here? We can trivially do a numerical calculation based on that. Andrew Gray (talk) 10:41, 27 February 2013 (UTC)
- ... but those time zone borders cut through states and even through counties, the same in Canada and possibly elsewhere – especially for countries with territories overseas, eg. France, Netherlands, UK. For some countries this must be done for every village on it's own. --Matthiasb (talk) 13:51, 7 March 2013 (UTC)
- ...and for the US there would be at least eleven options. I wonder if simply referring out to the identifer in the tz database would be the best approach here? We can trivially do a numerical calculation based on that. Andrew Gray (talk) 10:41, 27 February 2013 (UTC)
- Comment I think that goes beyond what's needed, looks like it is a method to determine what time it was, in given locations, at exact points in history. All we need are two fields; one for standard time, one for daylight saving (if there is one). For the United Kingdom the two values would be 0 and 1 which are the values for UTC adjustment. For China it would be 8 and null because they have unified time. Danrok (talk) 03:42, 24 February 2013 (UTC)
- Oppose. Agree this should be handled by the software. It should be possible to look up the value by supplying a tz database code or some other similar identifier.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 8, 2013; 19:21 (UTC)
- Support for states/provinces/etc and populated places as well as countries, so we can support the time zones used in infoboxes like en:Template:Infobox settlement and en:Infobox Province or territory of Canada. Note that these can display multiple time zone values, e.g. as in en:Ontario. I'd have no objection to a separate property based on automated application of tz database information, say, but let's start with a human-readable and human-editable one first. --Avenue (talk) 08:13, 13 March 2013 (UTC)
- Support, but no creation until infobox parameter or external source is provided. Mange01 (talk) 19:16, 13 March 2013 (UTC)
- Oppose, per Sven. --Yair rand (talk) 00:31, 20 March 2013 (UTC)
- Support, per Danrok. --NormanB (talk) 00:10, 22 March 2013 (UTC)
- Comment: Wikipedia has UTC+8 and Eastern Time Zone, so items is a reasonable datatype of the property. --NaBUru38 (talk) 20:09, 27 March 2013 (UTC)
- Done This was created by an IP at Property:P378 with string datatype. As it's currently an infobox parameter, handling it through the software doesn't seem to be an option for Wikipedia. Items for seem available. Created as Property:P421. -- Docu at 12:59, 14 April 2013 (UTC)
shoots (left / right)
Description | Whether the hockey player shoots left or right |
---|---|
Data type | wikibase-item or string?-invalid datatype (not in Module:i18n/datatype) |
Template parameter | put infobox parameter here if existing, e.g. en:Template:Infobox ice hockey player shoots |
Domain | sportsperson |
Allowed values | left / right |
Example | Joe Thornton <shoots> left |
Source | Infobox I guess |
Robot and gadget jobs | My bot is ready to import this data for all hockey players. |
Proposed by | Legoktm (talk) 06:40, 1 April 2013 (UTC) |
- Comment We should use a boolean-like datatype, or two apposite items. --Ricordisamoa 08:06, 1 April 2013 (UTC)
- Well, except that some players use both, so you could use Ambidexterity? Legoktm (talk) 10:39, 2 April 2013 (UTC)
- I think we should avoid using strings for things like "left" or "right". --Ricordisamoa 11:13, 2 April 2013 (UTC)
- How about Q789447 and Q457332? --NaBUru38 (talk) 16:52, 11 April 2013 (UTC)
- Ok for me. But for "right" players...? --Ricordisamoa 08:25, 13 April 2013 (UTC)
- For "right" is Q3039938. --Stryn (talk) 15:14, 14 April 2013 (UTC)
- Ok for me. But for "right" players...? --Ricordisamoa 08:25, 13 April 2013 (UTC)
- How about Q789447 and Q457332? --NaBUru38 (talk) 16:52, 11 April 2013 (UTC)
- Comment We should use a boolean-like datatype, or two apposite items. --Ricordisamoa 08:06, 1 April 2013 (UTC)
Wikimedia language code
- Description: language code as used by Wikimedia projects, e.g. ja for Japanese
- Datatype: string
- Comments: would be very useful for analysis or tools dealing with Wikipedia languages, if we could resolve our own projects in this place and how they match to a language. In short, imagine that you can get the French label for the language of min.wikipedia.org automatically -- wouldn't that be cool?
- Support as requester --Denny (talk) 20:37, 7 March 2013 (UTC)
- Comment Is there a big difference to ISO 639-1 (Property:P218): ja for Japanese? I do get the French label for all languages automatically since I have added French to my babel template. --Kolja21 (talk) 00:41, 8 March 2013 (UTC)
- Many of them are the same as ISO, but it is not done in a consistent way. Some language codes have two letters, some three, and a few even more. And there are also a few cases where it is completely different (als: ISO: tosk Albanian, Wikimedia: Alemannic) --Zolo (talk) 17:36, 10 March 2013 (UTC)
- As Zolo says, unfortunately they are not equal. So Wikimedia has its own set of language codes, and it would be good to have them in Wikidata too. --Denny (talk) 18:02, 10 March 2013 (UTC)
- Support, we need to have that somewhere. --Zolo (talk) 07:25, 11 March 2013 (UTC)
- Support MichaelSchoenitzer (talk) 01:38, 20 March 2013 (UTC)
- I'll create this property. Any idea what references (if any) should be added ? https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=languages/Names.php;hb=HEAD ? --Zolo (talk) 08:01, 8 April 2013 (UTC)
- Done as Property:P424 -- Docu at 15:12, 14 April 2013 (UTC)
- Description:
- Datatype: string
- Comments: Suggested by Visite fortuitement prolongée (talk • contribs • logs) on my talk page. It seems rather similar to Wikimedia language code. --Zolo (talk) 17:36, 10 March 2013 (UTC)
- Property:P305 Visite fortuitement prolongée (talk) 21:21, 20 March 2013 (UTC)
Openstreetmap Relation ID
Description | the ID of the relation of this place/object in opensteetmap |
---|---|
Data type | String |
Domain | streets, countries, states, buildings, places, everything with a geocordinate |
Example | Q64 (Berlin) would have the ID 62422 so it can be linked with this page or this map |
Proposed by | Shisma (talk) 11:43, 4 April 2013 (UTC) |
- Comment Relations are the most stable entities in the Openstreetmap database and they is used for more complex objects like country borders, building complexes or even long streets. --Shisma (talk) 08:05, 4 April 2013 (UTC)
- Support This seems the simplest way to link to borders for administrative units, lakes, watersheds etc. Are these compatible with WikiMiniAtlas? Filceolaire (talk) 19:51, 6 April 2013 (UTC)
- Done Property:P402--FischX (talk) 15:11, 7 April 2013 (UTC)
- Oppose OSM IDs are not so stable as it seems. I would prefer to link from OSM to Wikidata with http://wiki.openstreetmap.org/wiki/Key:Wikipedia . There already over 200.000 links exist and we use these in WikiMiniAtlas over WIWOSM. Other advantage is that the link is humanreadable and can apply on node, ways and relations and also on more than just one. A lots of objects like street have in OSM no relation. With access to OSM database on toolserver and later (hopefully) Wikilabs, it's very easy to everyone to use these links. If Wikidata have later a entries without an Wikipedia article it's possibble to use: Wikidata-Tag. --Kolossos (talk) 17:11, 7 April 2013 (UTC)
- Comment Little bit late ;-) relations are stable enough in the way that they can be deleted but not replaced, they are more unique than wikipedia articles. Human readability is not a valid argument for an database and there are many Properties who are not only work in one way (mother / child ect.) anyway the solution with Wikipedia links does not work with Wikidata because Wikidata should not be only a Wikipedia backend. Relations for roads can be created look at, Property:P15 from Q34444 for example - linking to an PNG or SVG is not realy data friendly integrating somesthing like [1]would be a userfrienldy solution. Maybe in the long run OSM can be joined into Wikidata. --FischX (talk) 22:02, 7 April 2013 (UTC)
- Comment I launch Wikidata:Properties_for_deletion#Property:P402 yesterday. I fact some relations are stable, like countries, but some are less : buildings, roads, forests... and it would be humanly impossible to keep it updated. Otourly (talk) 16:12, 18 April 2013 (UTC)
Rijksmonument identifier / Rijksmonumentnummer
Description | The (unique) identifier of a Rijksmonument |
---|---|
Data type | String |
Template parameter | nl:Sjabloon:Infobox kerk / nl:Sjabloon:Infobox molen / (and more) monumentnummer |
Domain | Instance of Rijksmonument |
Allowed values | 1 - 500000 at the moment |
Example | Q1545193 -> 19264 |
Source | Assigned by the Rijksdienst voor het Cultureel Erfgoed |
Proposed by | Multichill (talk) 17:00, 23 March 2013 (UTC) |
- I obviously support, but should we have it more broad, with two parameters: The name of the register the monument listed in, and the identifier in the register? In this way, we could use the same property not just for Dutch Rijksmonumenten, but for every recognized cultural monument.--Ymblanter (talk) 17:40, 23 March 2013 (UTC)
- I'm not sure if that's possible in the current data model. Multichill (talk) 18:25, 23 March 2013 (UTC)
- That will probably be possible once qualifiers are in place, but that may be a bit error-prone, and might lead us into lengthy discussions about which one should be included here, which one should rather be in another. The way it is currently done for authority controls is one database = 1 property, and I much prefer it this way. We can easily list all such properties, and add them in tools like User:Ricordisamoa/AuthorityControl.js. Znd if one day, Wikidata supports sitelinks to non-Wikimedia websites, it will be very easy to switch to the new format. --Zolo (talk) 19:20, 23 March 2013 (UTC)
- THis is my fault, I meant one thing but wrote smth else. I mean we should have two property, one saying in what register the monument is in (this could be Monumentenregister as well), and another one, which Maarten suggests, is a ID of the monument in that register. I do not think we need hundred distinct properties for different countries/administrative divisions.--Ymblanter (talk) 19:49, 23 March 2013 (UTC)
- I am not sure to understand what you are suggesting. I agree we should have two things:
- The protection status of the monument. In France that can be either protected building or semi-protected building, and in additionnally, there may be some other protection regulation. For that I think we shoud either use instance of or a dedicated "protection status" property.
- the ID of the monument in a database. That may not always be related to the protection status. For instance, the main French State database for listed buildings contains many non-protected buildings that are only there for documentary purposes. I think the simplest way to handle that is to have one separate property per database. If that means 100s of them, I am fine with it. I do not think it will make things harder to maintain than alternative solutions. --Zolo (talk) 21:07, 23 March 2013 (UTC)
- I am not sure to understand what you are suggesting. I agree we should have two things:
- THis is my fault, I meant one thing but wrote smth else. I mean we should have two property, one saying in what register the monument is in (this could be Monumentenregister as well), and another one, which Maarten suggests, is a ID of the monument in that register. I do not think we need hundred distinct properties for different countries/administrative divisions.--Ymblanter (talk) 19:49, 23 March 2013 (UTC)
- That will probably be possible once qualifiers are in place, but that may be a bit error-prone, and might lead us into lengthy discussions about which one should be included here, which one should rather be in another. The way it is currently done for authority controls is one database = 1 property, and I much prefer it this way. We can easily list all such properties, and add them in tools like User:Ricordisamoa/AuthorityControl.js. Znd if one day, Wikidata supports sitelinks to non-Wikimedia websites, it will be very easy to switch to the new format. --Zolo (talk) 19:20, 23 March 2013 (UTC)
- I'm not sure if that's possible in the current data model. Multichill (talk) 18:25, 23 March 2013 (UTC)
- Done created Property:P359. Multichill (talk) 20:18, 26 March 2013 (UTC)
KGS id
Description | identifier for cultural properties in Switzerland. As Wikidata:Property proposal/Place#Rijksmonument identifier / Rijksmonumentnummer above. |
---|---|
Data type | String |
Source | en:Swiss Inventory of Cultural Property of National and Regional Significance |
Proposed by | see Wikidata:Project_chat#Monuments_database |
Done : Property:P381. Ayack (talk) 11:46, 2 April 2013 (UTC)
Mérimée identifier / / identifiant Mérimée
Description | identifier for cultural properties in France. As Wikidata:Property proposal/Place#Rijksmonument identifier / Rijksmonumentnummer above. |
---|---|
Data type | String |
Domain | instance of Monument historique |
Source | http://www.culture.gouv.fr/culture/inventai/patrimoine/ |
Proposed by | Ayack (talk) 13:03, 29 March 2013 (UTC) |
Done : Property:P380. Ayack (talk) 11:45, 2 April 2013 (UTC)
Field of profession
Description | Field corresponding to profession |
---|---|
Data type | Item |
Domain | profession |
Allowed values | field |
Example | sculptor has property "field of profession" with value sculpture. |
Source | Discussed at Talk:Q28640 (profession). |
Proposed by | Superm401 (talk) 00:57, 2 April 2013 (UTC) |
This allow connecting a profession to the field they work in. Another example would be lawyer should have "field of profession" law. Superm401 (talk) 00:57, 2 April 2013 (UTC)
- Support. And this property should be bi-directional (with "done by" as inverse). Infovarius (talk) 19:50, 2 April 2013 (UTC)
- Comment What infobox is using this property? Likelihood of confusion: "field of work" (Property:P101). --Kolja21 (talk) 03:03, 3 April 2013 (UTC)
- I don't know of an infobox using it. Field of work is similar (the value side seems to be the same), but the domain for that seems to be person. Does it make sense to reuse that for a domain of profession too? Superm401 - Talk 04:58, 3 April 2013 (UTC)
Aircraft registration
- Description: A plane's registration
- Type: String
- Description: Aircraft registration is a unique alphanumeric string that identifies a civil aircraft. In accordance with the Convention on International Civil Aviation all aircraft must be registered with a national aviation authority and they must carry proof of this registration in the form of a legal document called a Certificate of Registration at all times when in operation.
- Type: String, possibly with validation of the prefix
- Done Property:P426. -- Docu at 17:20, 15 April 2013 (UTC)
Quote
- Description: quote supporting the claim
- Datatype: string
- Links:
- Infobox parameter example: en:Template:Cite book
- Comments: Zolo (talk) 16:03, 26 March 2013 (UTC)
- Done, as P:P387--Zolo (talk) 07:57, 4 April 2013 (UTC)
Taxonomic type
- Description: The species which defines this genus, or the genus which defines this family. For example, the type genus of Drosophilidae is Drosophila, and the type species of Drosophila is Drosophila funebris.
- Datatype: Link?
- Links:
- Infobox parameter example:
- Comments:
- Support Data type should be "Item" Inductiveload (talk) 15:02, 25 February 2013 (UTC)
- Support Of course. Needed Liné1 (talk) 08:05, 8 March 2013 (UTC)
- Support. Useful. Hexasoft (talk) 08:51, 8 March 2013 (UTC)
- Support Used in every taxobox Amphicoelias (talk) 21:03, 8 March 2013 (UTC)
- Support. --Salixen (talk) 15:10, 13 March 2013 (UTC)
- Question What should be the datatype? Item? -- MichaelSchoenitzer (talk) 01:40, 20 March 2013 (UTC)
- Support Type should be item. Superm401 - Talk 01:15, 6 April 2013 (UTC)
- Done Property:P427. -- Docu at 17:30, 15 April 2013 (UTC)
botanist author abbreviation
Description | official abbreviation used in taxonomy |
---|---|
Data type | String |
Domain | botanists |
Example | Carl Linnaeus, L. |
Source | w:List of botanists by author abbreviation |
Proposed by | 23PowerZ (talk) |
See Wikidata:Property_proposal/Term#Taxon_author 23PowerZ (talk) 08:37, 8 April 2013 (UTC)
- Support. I hope it'll be possible to use it as label of the link to the author. Tpt (talk) 09:25, 8 April 2013 (UTC)
- Support. Useful, and there are clear sources (The International Plant Names Index and Index Fungorum). Superm401 - Talk 18:08, 8 April 2013 (UTC)
- Support. See also en:Template:IPNI author (4 transclusions) and de:Template:IPNI (~1400 transclusions) for possible sources. -- Gymel (talk) 20:17, 8 April 2013 (UTC)
Price
Description | The price of an item |
---|---|
Data type | Quantity |
Domain | Any item that is a commodity |
Allowed values | A quantity formatted in the relevant currency. Source information and qualifiers for time and place required. |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | Nashev (talk) 23:58, 23 March 2013 (UTC) |
- Support This is an important property that applies beyond creative works. Use with qualifiers for time and place should be encouraged where applicable. Emw (talk) 02:20, 27 March 2013 (UTC)
- Oppose - Are we listing prices of telephones, cars, airplane tickets? Which countries will we be listing prices? Each model often has several versions. This will be a mess, and nobody will check them here. --NaBUru38 (talk) 19:56, 27 March 2013 (UTC)
- Why not list prices of things, as long as sources and qualifiers for time and place are strongly encouraged? Price is an important piece of structured data. Of course price will vary by model -- but Wikidata will presumably contain an item for each model. Emw (talk) 01:23, 28 March 2013 (UTC)
- Oppose: Almost no wiki uses this property. And there would be to many informations. --Toru10 (talk) 10:46, 28 March 2013 (UTC)
- Comment: I didn't like to have (in most cases) prices in the Wikipedia also, but I can imagine this property could be used for Wikivoyage. --Nightwish62 (talk) 15:06, 30 March 2013 (UTC)
- Oppose: information of limited value (no pun intended) and almost impossible to document with any sort of precision. Pichpich (talk) 17:04, 30 March 2013 (UTC)
- Huh? Price information is quite valuable for historians and economists (and consumers!). A few sources for price information immediately come to mind:
- CPI data for various classes of items
- MSRP: not pin-point precise, but often reasonably accurate for many classes of items
- KBB: for vehicles
- Retailer websites, e.g. http://www.amazon.com/
- This data will obviously be specific to a place and time, but strongly encouraging qualifiers seems like it could address that. The sources would address the fact prices vary by source. Emw (talk) 19:28, 30 March 2013 (UTC)
- Huh? Price information is quite valuable for historians and economists (and consumers!). A few sources for price information immediately come to mind:
- Oppose Not fixed qualities of items, subject to all kinds of fluctuations and variations and changes over time. Utterly unworkable, it seems to me. Shawn in Montreal (talk) 22:06, 30 March 2013 (UTC)
- Comment I've moved this proposal up to the top level, since it doesn't seem like anyone asserts this property would only apply to software. I've also adjusted fields in the proposal to reflect that (and miscellaneous copyediting). Emw (talk) 15:54, 31 March 2013 (UTC)
- Oppose I think this should be out of scope. It will be hard to determine which retailers/wholesalers/manufacturers to include (basically a whole notability discussion just for this property), and even for a single retailer and general item (e.g. a software program), there can be different prices for e.g. bulk discounts, students, etc. Some items (e.g. commodities) fluctuate extremely rapidly, so we would either be deluged with prices or need to make arbitrary decisions about how frequently to sample. It quickly becomes over-complicated. Superm401 - Talk 06:23, 12 April 2013 (UTC)
- Not done per consensus against its creation. — ΛΧΣ21 00:29, 14 April 2013 (UTC)
- Language of the original work or of one edition? --Kolja21 (talk) 18:07, 2 February 2013 (UTC)
- Language of the book so of the edition not the original work. There will be different items for different editions. Snipre (talk) 00:12, 4 February 2013 (UTC)
- I've put a note on top, that the term "book" is used in the meaning of edition. --Kolja21 (talk) 00:58, 4 February 2013 (UTC)
- Support Danrok (talk) 02:50, 26 February 2013 (UTC)
- Support Wikijunkie (talk) 00:28, 11 March 2013 (UTC)
- Support I don't know how useful it is for books, since the most books are translated in many languages. But it would be very useful for deeds and charters like e.g. Q662637 --Nightwish62 (talk) 23:09, 12 March 2013 (UTC)
- Created at Property:P407. I used "language of a work" as description, mainly because I think that it can also be used for films, albums, and other types of works to specify its version-specific language. — ΛΧΣ21 06:52, 10 April 2013 (UTC)
Should be included somehow ... --Kolja21 (talk) 01:29, 4 February 2013 (UTC)
- I dont think it is necessary. The first title of a book is almost in every case the original title. So we have two properties for one thing. It is probably possible to give several titles in every additional languange and for each new edition. So the original title is always the first title of the first edition and will remain unchanged no regards if there are translations or not.--Giftzwerg 88 (talk) 18:24, 7 February 2013 (UTC)
- this isn't for editions, just for translation, when the reference is given to the translated work. Libraries usually use a concept "Uniform title" for this, but that;s very complicated and includes more than the title. Uniform title is one of the things we should not be getting into. DGG (talk) 16:16, 15 February 2013 (UTC)
- Most probably we will have a multilanguage item of this work, with titles in the available languages. For Example Q274744 has titles in many languages, even beyond that, in some languages there are several different translations with different titles.--Giftzwerg 88 (talk) 10:39, 16 February 2013 (UTC)
- this isn't for editions, just for translation, when the reference is given to the translated work. Libraries usually use a concept "Uniform title" for this, but that;s very complicated and includes more than the title. Uniform title is one of the things we should not be getting into. DGG (talk) 16:16, 15 February 2013 (UTC)
- Support, but shouldn't this be MonolingualTextValue? --OldakQuill (talk) 17:56, 6 March 2013 (UTC)
Support but change the description because this is an important property for films and video games, too. Then it can be used for all of them. --Toru10 (talk) 14:58, 26 March 2013 (UTC)
- Oppose A better solution would be a "translation of" property. Then if T and O are books and "T translation of O", you can get the original title of T by looking up the title of O. Silver hr (talk) 03:48, 31 March 2013 (UTC)
- Support Datatype should be MonolingualTextValue. @Silver hr: I don't get what you mean. Do you think a translation of an item is another item?--CENNOXX (talk) 12:38, 31 March 2013 (UTC)
- Yes, that is what I meant. Silver hr (talk) 23:38, 12 April 2013 (UTC)
- Support Datatype should be MonolingualTextValue. @Silver hr: I don't get what you mean. Do you think a translation of an item is another item?--CENNOXX (talk) 12:38, 31 March 2013 (UTC)
- Done as P:P357. But I agree with silver hr: it seems to make sense to have separate items for translations, see Wikidata_talk:Books_task_force#Relations_between_books. That makes "original title" unncessary but a "title" property is still needed. Can I call the property "title", then ? See Property talk:P357 for more details. --Zolo (talk) 06:32, 5 April 2013 (UTC)
Last/Next album
Description | Link to Wikidata item to the following/preceding album in the chronological discography. |
---|---|
Data type | Item |
Template parameter | Used e.g. in w:it:Template:Album |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | ★ → Airon 90 13:04, 21 February 2013 (UTC) |
- Discussion
- Support, the data can be derived from other items. --NaBUru38 (talk) 23:21, 25 February 2013 (UTC)
- Well, Naburu, what about Property:P155 and Property:P156? --Viscontino talk 10:06, 2 March 2013 (UTC)
- I oppose both properties. Lists should be listed in a list, not with symmetric properties. --NaBUru38 (talk) 18:41, 8 March 2013 (UTC)
- I Oppose as well. --Stryn (talk) 17:15, 26 March 2013 (UTC)
- I oppose both properties. Lists should be listed in a list, not with symmetric properties. --NaBUru38 (talk) 18:41, 8 March 2013 (UTC)
- Oppose too. As NaBUru38 already said, information can be retrieved by other properties (even though not at moment and a query is needed). It's also unclear what exactly counts to be the 'next or previous album'. Does it a single? A compilation? A bootleg? A live album? --Nightwish62 (talk) 15:26, 30 March 2013 (UTC)
- Not done Per consensus against its creation. — ΛΧΣ21 06:52, 7 April 2013 (UTC)
Singles
Description | In album pages, list of singles extracted from that album |
---|---|
Data type | Item |
Template parameter | w:en:Template:Infobox album singles |
Proposed by | ★ → Airon 90 13:04, 21 February 2013 (UTC) |
- Discussion
- Support --Viscontino talk 10:08, 2 March 2013 (UTC)
- Done What about "Taken from", which is the opposite of "Singles" ("Singles": album → song. "Taken from": song → album)? --★ → Airon 90 10:27, 4 April 2013 (UTC)
CBS
- Description: statistical identification code for municipalities in the Netherlands, see: [2]
- Datatype:
ItemString - Source: http://www.cbs.nl/nl-NL/menu/methoden/classificaties/overzicht/gemeentelijke-indeling/2013/default.htm
- Domain: all municipalities in the Netherlands
- Infobox parameter: 'CBS=' , see nl:Sjabloon:Infobox gemeente Nederland
- Comments: Or just use a generic 'municipality code' property for all municipalities, independent of country?Michiel1972
- Full support. NormanB (talk) 19:20, 21 March 2013 (UTC)
- How would a "generic code" work with objects who can have more than one kind of code in the same item? Swedish urban areas exists of several kinds, and some of them can co-exist. Others can change from one kind to another from one census to the next. -- Lavallen (block) 21:08, 21 March 2013 (UTC)
- Full support. --Monsieurbecker (talk) 11:43, 26 March 2013 (UTC)
Done Property:P382 ( I've changed the datatype to string) Michiel1972 (talk) 13:01, 2 April 2013 (UTC)
French Municipality Key / Französischer Gemeindeschlüssel / Code commune (France)
- Description: number sequence for the identification of municipalities in France
- Datatype:
ItemString - Source: http://www.insee.fr/fr/methodes/nomenclatures/cog/documentation.asp
- Domain: all municipalities in France
- Infobox parameter: 'insee=' , see fr:Modèle:Infobox Commune de France
- Example value: 48095 (fr:Mende (Lozère))
--Monsieurbecker (talk) 12:55, 26 March 2013 (UTC)
- Support --NormanB (talk) 14:38, 28 March 2013 (UTC)
- Comment I've changed the datatype to string. --Monsieurbecker (talk) 07:13, 30 March 2013 (UTC)
Done Property:P374 --Monsieurbecker (talk) 08:00, 31 March 2013 (UTC)
Dantai code
Description | Q646425 全国地方公共団体コード Zenkoku chihō kōkyō dantai kōdo (lit. "Nationwide local public entity code"), unique number assigned to each municipality in Japan by Japanese interior ministry |
---|---|
Data type | String |
Template parameter | 'コード' in ja:Template:日本の市, ja:Template:日本の町村, etc.; 'Gemeindeschlüssel' in de:Vorlage:Infobox Ort in Japan; 'цифровой идентификатор' in ru:Шаблон:НП-Япония; '編號' in zh:Template:日本都市 |
Domain | municipalities in Japan |
Allowed values | exactly six digits, may begin with '0' |
Example | '011002' for City of Sapporo; '261009' for City of Kyoto |
Source | Japanese interior ministry (in Japanese) |
Proposed by | F705i (talk) 02:15, 6 April 2013 (UTC) |
Notes by the proposer: English label "Dantai code" for this property is provisional. The code consists of six digits, the first two digits represent the prefecture that the municipality belongs to (ISO 3166-2:JP), the following three digits are unique in the prefecture, and the final digit is a check digit. The code is sometimes written with a hyphen between the first five digits and the check digit, e.g. '01100-2' instead of '011002'. The first five digits coincide with the five-digit code standardized in JIS X 0402. --F705i (talk) 02:15, 6 April 2013 (UTC) (updated --F705i (talk) 04:58, 6 April 2013 (UTC))
- Support --Monsieurbecker (talk) 06:10, 6 April 2013 (UTC)
- Report A week has past since my proposal, so I've requested the admin for creating the Dantai code property at Wikidata:Administrators' noticeboard#Request for a new property. However, my request is left pending now. --F705i (talk) 13:07, 16 April 2013 (UTC)
Callsign / Rufzeichen
Description | The Callsign of an Airline in the funk traffic |
---|---|
Data type | String |
Template parameter | en:template:infobox airline Callsign |
Domain | Airlines |
Allowed values | the Callsign(s) of the Airline |
Example | <British Airways> → <SPEEDBIRD> |
Source | en:template:infobox airline Callsign |
Proposed by | Milad A380 talk? |
Would be useful for airline infoboxes. Milad A380 talk? 19:11, 8 April 2013 (UTC)
- Support --Kolja21 (talk) 19:27, 16 April 2013 (UTC)
Issue
- Description: Issue of a publication like scientific journal
- Datatype: Integer
- Links:
- Infobox parameter example: en:Template:Cite_journal
- Comments: String or number ?
See "edition" below.
edition / Ausgabe / numéro
Description | edition of a magazine/Ausgabe einer Zeitschrift/numéro du magazine |
---|---|
Data type | String |
Template parameter | de:Vorlage:BVK |
Domain | type of items that may have this property |
Allowed values | format <editon>/<year> or <editon> |
Example | example item and/or example value |
Source | External magazines |
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 | Pyfisch (talk) |
I want to transfer from the German Wikipedia informations about winners of the Order of Merit of the Federal Republic of Germany, with the source "Bundesanzeiger", when the person won the medall. Pyfisch (talk) 14:51, 16 April 2013 (UTC)
- We have edition and we already have the proposition for issue (see above). Could one of these two properties match your request? From my German understanding your proposal matches the property proposal "issue" (see for translation). If you agree to merge your proposal with the issue proposal I can create it now because the issue property is proposed since more than one week. Snipre (talk) 15:50, 17 April 2013 (UTC)
- You can merge it. --Pyfisch (talk) 16:37, 17 April 2013 (UTC)
German Municipality Key / Amtlicher Gemeindeschlüssel (Dtl.) / Code commune allemand
- Description: number sequence for the identification of municipalities and independent towns in Germany
- Datatype:
ItemString - Source: https://www.destatis.de/DE/ZahlenFakten/LaenderRegionen/Regionales/Gemeindeverzeichnis/Gemeindeverzeichnis.html
- Domain: all municipalities and indeptendent towns in Germany
- Infobox parameter: 'Gemeindeschlüssel=' , see de:Vorlage:Infobox Gemeinde in Deutschland
- Example value: 12060020 (de:Bernau bei Berlin)
--Monsieurbecker (talk) 11:40, 26 March 2013 (UTC)
- Support --NormanB (talk) 14:37, 28 March 2013 (UTC)
- Comment I've changed the datatype to string. --Monsieurbecker (talk) 07:13, 30 March 2013 (UTC)
- Done as P:P439 --Stevenliuyi (talk) 18:59, 19 April 2013 (UTC)
German District Key / Kreisschlüssel (Dtl.) / Code arrondissement allemand
- Description: number sequence for the identification of districts ("Landkreise") and independent towns in Germany
- Datatype: string
- Source: https://www.destatis.de/DE/ZahlenFakten/LaenderRegionen/Regionales/Gemeindeverzeichnis/Gemeindeverzeichnis.html
- Domain: all districts and indeptendent towns in Germany
- Infobox parameter: 'Kreisschlüssel=' , see de:Vorlage:Infobox Landkreis
- Example value: 07132 (de:Landkreis Altenkirchen (Westerwald))
--Monsieurbecker (talk) 11:40, 26 March 2013 (UTC)
- Support --NormanB (talk) 14:38, 28 March 2013 (UTC)
- Comment I've changed the datatype to string. --Monsieurbecker (talk) 07:13, 30 March 2013 (UTC)
- Support --Rudolph Buch (talk) 11:53, 15 April 2013 (UTC) (Changed "Districts Key" to singular form)
- Done as P:P440 --Stevenliuyi (talk) 19:01, 19 April 2013 (UTC)
licence plate code
Description | For countries: international licence plate country code or distinguishing sign of vehicles in international traffic. For other entities: distinguishing signs or parts of license plate associated with the entity. |
---|---|
Data type | String |
Template parameter | e.g. en:Infobox settlement field "registration_plate", en:Infobox District DE field "carsign" |
Example | Q846 (Qatar): Q |
Source |
|
Cheers. -- Docu at 16:54, 3 April 2013 (UTC)
- Support, could be useful for cases like Kansas and Oklahoma, which have two-letter license plate codes for each of their counties. —Scott5114↗ [EXACT CHANGE ONLY] 18:55, 15 April 2013 (UTC)
- Done as P:P395 two weeks ago by an IP user--Stevenliuyi (talk) 19:33, 19 April 2013 (UTC)
China administrative division code
Description | Administrative division codes of the People's Republic of China used by National Bureau of Statistics of the People's Republic of China |
---|---|
Data type | String |
Template parameter | e.g. zh:Infobox China County |
Domain | administrative divisions in China |
Example | Yangpu District: 310110 |
Proposed by | Stevenliuyi (talk) 23:28, 4 April 2013 (UTC) |
- Support, but we should wait with the creation of this property, because the datatype should be a numeric one which doesn't exist yet. As far as I know, the required datatype will be created soon. (Other division codes can have a leading zero which is part of the code, so they can't be numeric. In the list of this code here [3], there is no value with a leading 0.) --Monsieurbecker (talk) 06:40, 5 April 2013 (UTC)
- I think we should use string as datatype because Wikipedias (and other third parties) will do lots of string operations (concatenation, substring etc.) over these codes. For instance, if we have two codes "110101" and "110228", using
substring(code,3,4)
can easily tell us their administrative division types (substring(code, 3,4)
of the former is "01" so it's a district of Beijing, whilesubstring(code, 3,4)
of the latter is "02" so it's a county of Beijing). It's more difficult to do this kind of operations if the datatype is number.--Stevenliuyi (talk) 14:15, 13 April 2013 (UTC)
- I think we should use string as datatype because Wikipedias (and other third parties) will do lots of string operations (concatenation, substring etc.) over these codes. For instance, if we have two codes "110101" and "110228", using
- Done as P:P442--Stevenliuyi (talk) 19:48, 19 April 2013 (UTC)
was a(n) / war ein(e) / était un(e)
- Status: Not done
- Description: The subject was an instance of the object item in the past, but not necessarily is anymore.
- Infobox parameter:
- Datatype: Item
- Domain: Generic
- Allowed values: Term or Category.
- Source: Lists of former items (e.g. List of former Royal Air Force stations).
- Example item and value: <Bill Clinton> was a <Head of State>, <Bonn> was a <capital>, <RAF Abingdon > was a <Royal Air Force station>
- Robot and gadget jobs:
See discussion |
---|
Apparently we have to wait for qualifiers. Let's hope they are implemented soon, as coding historical information is now impossible. Not done -- NormanB (talk) 02:11, 3 April 2013 (UTC) |
element of / Element von / fr / Элемент
- Description: Element/instance of set
- Infobox parameter: -
- Datatype: Item
- Domain: Subject main type (person, organization, place, term, disambiguation) and category
- Allowed values: any object
- Source: Some categories or lists in Wikipedia
- Example item and value: human element of humanity
- Robot and gadget jobs: Consistency should be checked with another proposed proposed, e.g. "set of".
- It looks similar to P279... Infovarius (talk) 19:13, 15 March 2013 (UTC)
Oppose redundant to P:P31 or P:P279--Svebert (talk) 19:45, 15 March 2013 (UTC)- I think not - see example in the form. This relation can't be described by these 2 properties. Infovarius (talk) 13:41, 16 March 2013 (UTC)
- hm. ok. I have to reconsider.
- In general I think we need for these generic relation properties two branches. One for sets and one for concepts.
- Examples:
- human element of humanity OK
- human part of humanity OK
- human is a humanity Oppose not possible because a human is not an instance of the group of humans but an element of
- human generalized by humanity Opposenot possible
- Electron element of Lepton Oppose, but a single Electron is element of the group of all/some Leptons. But such items (=set of all instances of one concept) does not exist, I hope.
- Electron part of Lepton Oppose not possible
- Electron is a Lepton OK
- Electron generalized by Lepton OK
- China element of Asia Question if one considers Asia just as set of all countries on the continent asia, this would be possible
- China part of Asia OK
- China is a Asia Oppose not possible
- China generalized by Asia Oppose not possible
- I come to the conclusion that we need all 4 properties. But I think we should formulate general rules how these properties has to be used and also include examples and not-examples on the top of the specific property-discussion page.--Svebert (talk) 23:30, 16 March 2013 (UTC)
- I think not - see example in the form. This relation can't be described by these 2 properties. Infovarius (talk) 13:41, 16 March 2013 (UTC)
- Oppose This property is essentially an undifferentiated alias for instance of (P31) and subclass of (P279), and thus redundant. Those properties and this property are fundamentally set membership relations. Those properties differentiate between subjects that are instances and subjects that are classes; this one does not. A relevant discussion on this is ongoing at the is a -> instance of section on the P31 talk page. Emw (talk) 01:56, 19 March 2013 (UTC)
- Oppose The use of this property would be really specific. I think we should focus on some few generalization/specialization properties and do not create one property for each kind of situation.--Faux (talk) 08:12, 22 March 2013 (UTC)
- Comment Hyponymic relations like P31 (instance of) or P279 (subclass of) should by strictly distinguished from meronymic relations (part of, member of) and other most basic types of relations. --ŠJů (talk) 02:35, 31 March 2013 (UTC)
- Oppose --Nightwish62 (talk) 09:50, 31 March 2013 (UTC)
- Not done --Stevenliuyi (talk) 00:37, 20 April 2013 (UTC)
Pronunciation / Вимова
Description | name of a file on Commons with pronunciation |
---|---|
Data type | |
Domain | any |
Allowed values | a names of an existing audio file with pronunciation on Commons |
Example | Lviv.ogg |
Proposed by | DixonD (talk) 11:45, 2 April 2013 (UTC) |
- Oppose For which items? By default items are interlanguage, so common pronunciation not exist. Infovarius (talk) 20:21, 2 April 2013 (UTC)
- I changed the datatype. --DixonD (talk) 06:54, 3 April 2013 (UTC)
- Support as qualifier to Local Name or Official Name. I changed the datatype. Filceolaire (talk) 06:48, 5 April 2013 (UTC)
- For instance, the article en:Lviv has two pronunciations: Ukrainian and Polish. French Wikipedia (fr:Lviv) has French pronunciation. So the multilingual text datatype makes more sense than a qualifier to mentioned names as theoretically every language may have different pronunciation for some particular term. --DixonD (talk) 06:58, 5 April 2013 (UTC)
Discography Link
Description | Link to discography in artist or band page |
---|---|
Data type | Item |
Source | w:it:Template:Tracce |
Proposed by | ★ → Airon 90 13:04, 21 February 2013 (UTC) |
- Discussion
- Question: in many cases in English wikipedia we have discography wiki articles, too. Is there a way to work that in? Shawn in Montreal (talk) 04:30, 27 February 2013 (UTC)
- Support where the item is the discography article. Danrok (talk) 23:43, 28 February 2013 (UTC)
- Support As an example, Q42482 would link to Q836314. Linking to individual albums and singles etc should not be allowed. Del♉sion23 (talk) 22:39, 10 March 2013 (UTC)
- Support, rename to "works" to cover other creative works (buildings, films, etc). --NaBUru38 (talk) 19:36, 19 March 2013 (UTC)
- Support --Viscontino talk 10:21, 26 March 2013 (UTC)
Done, created Property:P358 - discography link. --Nightwish62 (talk) 18:20, 26 March 2013 (UTC)
- What about a link from "X's discography" to "X"? In "X" you need P358 to link to "X's discography" but there is no property (it seems) to link back. --★ → Airon 90 10:56, 29 March 2013 (UTC)
- I think we could use Property:P360 - this is a list of. What do you think? --Nightwish62 (talk) 16:20, 30 March 2013 (UTC)
- No, X's discography is not a "list of X", it's a "list of albums by X", so list of is not appropriate (also,there's not going to be a "album by X" item in almost all cases). Superm401 - Talk 00:30, 8 April 2013 (UTC)
- I think we could use Property:P360 - this is a list of. What do you think? --Nightwish62 (talk) 16:20, 30 March 2013 (UTC)
Should we create a "Discography of" property? --★ → Airon 90 22:05, 8 April 2013 (UTC)
belongs to
Description | album for which the album cover belongs |
---|---|
Data type | Item |
Domain | items about album covers |
Example | Colgando En Tus Manos (single cover) <belongs to> Colgando En Tus Manos |
Proposed by | — ΛΧΣ21 |
- Discussion
Now that we can have items for non-Commons (and mostly non-free) files, I think that we need this property to link the album covers with the albums they belong to. — ΛΧΣ21 07:30, 9 April 2013 (UTC)
- Oppose This is redundant with part of (P361). Emw (talk) 03:31, 10 April 2013 (UTC)
- Oppose I agree with Emw.--CENNOXX (talk) 12:10, 10 April 2013 (UTC)
soundtrack album
Description | link to the soundtrack album |
---|---|
Data type | Item |
Example | <Q487181> <soundtrack album> <Q4048188> |
Proposed by | Nightwish62 (talk) 20:55, 28 March 2013 (UTC) |
- Discussion
-
- Support Seems useful. I used part of to go the other direction, but that's not as clear. If and when we have bi-directional properties, this would be a candidate. Superm401 - Talk 02:35, 4 April 2013 (UTC)
- Done after one week of voting with no vote against. --Nightwish62 (talk) 19:18, 8 April 2013 (UTC)
- Done as Property:P406.
- Discussion
- Comment Does this property request not better fit to music section? --Toru10 (talk) 20:35, 29 March 2013 (UTC)
- Comment, I moved it. --Nightwish62 (talk) 15:43, 30 March 2013 (UTC)
- Support --Nightwish62 (talk) 15:43, 30 March 2013 (UTC)
- Support --FelGru (talk) 21:01, 4 April 2013 (UTC)
- Support --★ → Airon 90 18:47, 6 April 2013 (UTC)
- Support --Reosarevok (talk) 13:48, 18 April 2013 (UTC)
- Support --Mineo (talk) 13:55, 18 April 2013 (UTC)
- Done: Property:P434, Property:P435, Property:P436
musicBrainz Artist ID / musicBrainz Künstler-Identifikator
Description | ID Number in the musicBrainz open music encyclopedia |
---|---|
Data type | String |
Template parameter | ? |
Domain | Person, organisation |
Allowed values | 36 character Universally Unique Identifier |
Example | Q15862/Queen (British rock band) would be 0383dadf-2a4e-4d10-a46a-e9e041da8eb3 |
Proposed by | Shisma (talk) 12:12, 28 March 2013 (UTC) |
- Duplicate to above? -- MichaelSchoenitzer (talk) 16:17, 18 April 2013 (UTC)
MusicBrainz Work ID
Description | ID Number in the musicBrainz open music encyclopedia |
---|---|
Data type | String |
Template parameter | ? |
Domain | creative works |
Allowed values | 36 character Universally Unique Identifier |
Example | Q187745 would be 41c94a08-a551-3c86-bb17-d9a52e3a618b (in musicBrainz) |
Proposed by | Shisma (talk) 12:12, 28 March 2013 (UTC) |
MusicBrainz Release Group ID
Description | ID Number in the musicBrainz open music encyclopedia |
---|---|
Data type | String |
Template parameter | ? |
Domain | music albums |
Allowed values | 36 character Universally Unique Identifier |
Example | Q193477 would be 6b47c9a0-b9e1-3df9-a5e8-50a6ce0dbdbd (in musicBrainz) |
Proposed by | Shisma (talk) 12:12, 28 March 2013 (UTC) |
Video game publisher / Publisher
Description | Publisher of video games |
---|---|
Data type | Item |
Template parameter | en:template:Infobox video game: publisher |
Domain | Organisation, video games |
Example | TrackMania Nations, values: Digital Jesters (UK), Focus (France), Enlight (US), Buka (CIS), Steam (international) |
Source | en:template:Infobox video game: publisher |
Proposed by | #Reaper (talk) |
- Discussion
- The country of destionation (US, France, International, see brackets above) can't be mapped with an single item. I don't know if this can be solved or how. --#Reaper (talk) 21:29, 12 March 2013 (UTC)
- Now you can't, but you will in the future. The thing is called "qualifiers", that is, extra data about the fact. In the future you will be abled to add time periods too, for example -NaBUru38 (talk) 19:41, 19 March 2013 (UTC)
- Support, rename to "publisher / distributor" to allow books and films use it too. --NaBUru38 (talk) 19:41, 19 March 2013 (UTC)
- Oppose, as NaBUru38, should be 'merged' with Property:P123. I suggest to change the description in P123, so that it isn't only restricted to print media. --Nightwish62 (talk) 14:44, 30 March 2013 (UTC)
- I have changed the deffinition of Property:P123 to state that it accepts all types of subjects. — ΛΧΣ21 06:56, 7 April 2013 (UTC)
- Thank you (sry for late answer), I haven't seen, that there was already a suitable property. I've updated some aliases. --#Reaper (talk) 19:19, 8 April 2013 (UTC)
- Not done Property:P123 can be used. — ΛΧΣ21 07:09, 13 April 2013 (UTC)
computing platform / Plattform
Description | computing platform on which a software runs, e.g. PC, ARM, Xbox |
---|---|
Data type | Item |
Template parameter | en:template:Infobox software: platform. en:template:Infobox video game: platforms |
Domain | Term(?), software, video games |
Source | infobox |
Proposed by | #Reaper (talk) |
- Could lead to problems, because of usage of the parameter "platform", especially with video games. Information could be mixed there, as sample: "PC (Windows, Linux, Mas OS X), Xbox, PS3, Macintosh". I'm unaware because of this problem. --#Reaper (talk) 21:50, 12 March 2013 (UTC)
- Doesn't it repeat the information in "operating system"? I mean, platforms are Windows, Linux, Mac OS, iOS, PlayStation 1 / 2 / 3 / Vita, Xbox 1 / 360, Nintendo 64 / Wii / Gamecube / DS, etc. --NaBUru38 (talk) 19:44, 19 March 2013 (UTC)
- Support OS and platforms are not the same: operation systems: Windows, Linux, OS of the Xbox, iOS... . computing platforms: Computer, Xbox, iPhone... From the en:wikipedia: Typical platforms include a computer architecture, operating system, programming languages and related user interface (run-time system libraries or graphical user interface). So the OS is part of a (computing) platform but it`s not the same. --Toru10 (talk) 18:39, 20 March 2013 (UTC)
- I still think that having just one property is enough. --NaBUru38 (talk) 18:54, 20 March 2013 (UTC)
- CommentThe OS should only be used for computer programms such as itunes, Microsoft office etc. For computer/video games etc. platform is the better one. At least the english and german wikipedia use both.(example 1 example 2) Only in case if we decide to use only one i guess platform would be the better one. Because platforms also can be a software or a hardware platform. In my opinion it should either be used both, OS and computing platform, or we rename it to platform (without computing) so it can be used as software or hardware platform. To call a Playstation an OS sounds wrong for me because it`s definitly not a software. --Toru10 (talk) 19:08, 21 March 2013 (UTC)
- I still think that having just one property is enough. --NaBUru38 (talk) 18:54, 20 March 2013 (UTC)
- Actually, 'operating system' and 'platform' are not the same. 'platform' works for all types of software, while 'operating system' only applies for software developed for specific versions of Windows, Mac, or Linux. The former can be used for all kind of programs (including games and applications) while the latter can only be used for computer programs. This makes the two properties different in purpose. I have gone ahead and created the property: Property:P400. — ΛΧΣ21 07:06, 7 April 2013 (UTC)
License type
Description | MISSING |
---|---|
Data type | Item |
Domain | software |
Allowed values | Freeware, Shareware, Commercial etc |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | Nashev (talk) 23:58, 23 March 2013 (UTC) |
- There's also P275 (license): I think that this property should refer to licenses and not to software (if there's an item for that license). --Ricordisamoa 23:51, 25 March 2013 (UTC)
- Agree, there's no reason for a second property. --NaBUru38 (talk) 19:55, 27 March 2013 (UTC)
- Oppose: redundant with instance of (P31) and subclass of (P279). Emw (talk) 02:16, 27 March 2013 (UTC)
- There's also P275 (license): I think that this property should refer to licenses and not to software (if there's an item for that license). --Ricordisamoa 23:51, 25 March 2013 (UTC)
- Oppose --Toru10 (talk) 10:46, 28 March 2013 (UTC)
- Oppose for the same reason as Ricordisamoa. If we have the exact license already, it's possible to determine the license type also. No need for explicit store this information therefore. --Nightwish62 (talk) 15:01, 30 March 2013 (UTC)
- Oppose license is more precise. --FelGru (talk) 21:08, 4 April 2013 (UTC)
- Not done per consensus against its creation. — ΛΧΣ21 07:16, 7 April 2013 (UTC)
Discussion
The opinions above states that licence type is a property of a licence. This is true, except that an identifiable licence is not always easy to find, for example I doubt finding a licence for Microsoft Windows is an easy thing: there is probably not only one licence, there is many one, and many one for each version of windows ... It's a mess that can be easyly abstracted away by a licence type attached directly to a software. In the FOSS world there is a small number of licences, so just having the licence could work, I'm not sure it's true in the business of selling proprietary proprietary licences. Or other types of business either. TomT0m (talk) 10:53, 6 April 2013 (UTC)
Have feature
Description | For list of common features of software product |
---|---|
Data type | Item |
Domain | software |
Allowed values | many many any small ones |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | Nashev (talk) 23:58, 23 March 2013 (UTC) |
- Weak support Can be useful for some programs but potentially abused. --Ricordisamoa 23:59, 25 March 2013 (UTC)
- Oppose, this will be a mess. --NaBUru38 (talk) 19:57, 27 March 2013 (UTC)
- Oppose --Toru10 (talk) 10:46, 28 March 2013 (UTC)
- Oppose, I suggest clearer properties, that I doesn't bring about a mess. E.g. properties: 'game engine', 'graphic engine', 'physic engine', etc. This way it would be possible better query items later. --Nightwish62 (talk) 10:04, 29 March 2013 (UTC)
- Not done Per consensus against its creation. — ΛΧΣ21 07:18, 7 April 2013 (UTC)
game mode(s) / Spielmodi
Description | available game modes in a video game e.g. single-player, multiplayer |
---|---|
Data type | Item |
Template parameter | en:template:infobox video game |
Domain | video games |
Allowed values | single-player, multiplayer, cooperative |
Example | The Legend of Zelda: Ocarina of Time value: single-player |
Source | infobox |
Proposed by | Toru10 (talk) 10:46, 28 March 2013 (UTC) |
- Support --Nightwish62 (talk) 09:59, 29 March 2013 (UTC)
- Support --Ricordisamoa 19:32, 29 March 2013 (UTC)
- If no objections are made in 24h, I'll create it. --Ricordisamoa 22:28, 6 April 2013 (UTC)
- Done P404 --Toru10 (talk) 17:10, 7 April 2013 (UTC)
Amazon Standard Identification Number / Amazon Standard-Identifikationsnummer / numéro d'identification standard Amazon
Description | ID Number at amazon.com |
---|---|
Data type | String |
Domain | Creative work |
Allowed values | 10-character alphanumeric unique identifier |
Example | Q150901 could be be B004ZN9RWK and/or B000024D4P (multiple values should be allowed) |
Proposed by | Shisma (talk) 12:24, 28 March 2013 (UTC) |
See discussion |
---|
|
Preceded by / Succeeded by
Description | the subject that succeded, or preceeded, a subject |
---|---|
Data type | Item |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Proposed by | — billinghurst sDrewth 09:34, 29 March 2013 (UTC) |
Not sure how this one would be exactly set out, so I am just going to put forward the idea, and let others deal with it. To me there would seem to be numerous occasions of preceded by, and succeeded by scenarios, eg. people in positions, or administrative regions. It would be helpful to either to identify the progression of something, alternatively we may wish to identify that something is no longer in existence, eg. such and such an administrative unit is no longer in existence. It may be that we want to do both to say that one is defunct, and succeeded by. <shrug> Maybe the terms are predecessor, successor, incumbent with suitable aliases depending on how it is implemented. — billinghurst sDrewth 09:34, 29 March 2013 (UTC)
- preceded by and succeeded by already exist. ctrl+f for them on the list of properties page. They should probably be moved from the works section, as they do indeed apply to things other than works. --Izno (talk) 13:04, 29 March 2013 (UTC)
- I previously suggested this property here but opinion was that it should be a qualifier rather than a property. I'm still in favour of a property because it would make it easier to use in infoboxes than if it was a qualifier from what I've read of the docs. /Ch1902 (talk) 14:29, 29 March 2013 (UTC)
- Done already exists. I agree to Izno. The property should probably be moved from the works section --Toru10 (talk) 20:35, 29 March 2013 (UTC)
- Done (partially) I've moved the properties as suggested to the general section and tried to reword them a little. However, I am unable to figure the coding in the Tables section atop the properties list, so someone else will need to do that. Shawn in Montreal (talk) 23:00, 5 April 2013 (UTC)
- Done already exists. I agree to Izno. The property should probably be moved from the works section --Toru10 (talk) 20:35, 29 March 2013 (UTC)
- I previously suggested this property here but opinion was that it should be a qualifier rather than a property. I'm still in favour of a property because it would make it easier to use in infoboxes than if it was a qualifier from what I've read of the docs. /Ch1902 (talk) 14:29, 29 March 2013 (UTC)
- Property already exists, and the comments above have been dealt. — ΛΧΣ21 07:15, 13 April 2013 (UTC)
Unstable version
Description | code for the latest unstable version of the software |
---|---|
Data type | String |
Template parameter | it:Template:Software |
Domain | software |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | infobox |
Proposed by | ★ → Airon 90 10:49, 29 March 2013 (UTC) |
- Wrong datatype – has to bee string for the version and time for the date. -- MichaelSchoenitzer (talk) 18:54, 29 March 2013 (UTC)
- I've splitted and fixed them. --Ricordisamoa 19:18, 29 March 2013 (UTC)
- Comment I would rename it to latest preview version see en:template:Infobox web browser --Toru10 (talk) 20:35, 29 March 2013 (UTC)
- I've splitted and fixed them. --Ricordisamoa 19:18, 29 March 2013 (UTC)
- Oppose. I learned yesterdays about qualifiers and therefore I don't support two individual properties for 'stable' or 'unstable' anymore. We should better use a neutral 'version' and mark an entry with a qualifier if this version is stable or not. See an example of qualifiers here. --Nightwish62 (talk) 15:34, 30 March 2013 (UTC)
- Oppose--Toru10 (talk) 16:06, 30 March 2013 (UTC)
- Not done Per consensus against its creation. — ΛΧΣ21 17:08, 9 April 2013 (UTC)
Unstable version (date)
Description | date of publication of unstable version |
---|---|
Data type | Point in time |
Template parameter | it:Template:Software |
Domain | software |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | infobox |
Proposed by | ★ → Airon 90 10:49, 29 March 2013 (UTC) |
Support --Toru10 (talk) 20:35, 29 March 2013 (UTC)- Oppose. I learned yesterdays about qualifiers and therefore I don't support two individual properties for 'stable' or 'unstable' anymore. We should better use a neutral 'version' and mark an entry with a qualifier if this version is stable or not. See an example of qualifiers here. --Nightwish62 (talk) 15:34, 30 March 2013 (UTC)
- now Oppose --Toru10 (talk) 16:06, 30 March 2013 (UTC)
- Not done. --Stryn (talk) 10:34, 10 April 2013 (UTC)
Software genre
Description | genre of the software |
---|---|
Data type | Item |
Template parameter | it:Template:Software |
Domain | software |
Allowed values | some already defined: office suite, word processor, calculator, spreadsheet, ... |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | infobox |
Proposed by | ★ → Airon 90 10:49, 29 March 2013 (UTC) |
- Support --Toru10 (talk) 20:35, 29 March 2013 (UTC)
- Oppose, why not use the already existing generic 'genre'? --Nightwish62 (talk) 15:33, 30 March 2013 (UTC)
- Oppose Hooray generic properties! In other words, per Nightwish62. Emw (talk) 16:09, 30 March 2013 (UTC)
- Not done Per consensus against its creation. — ΛΧΣ21 19:37, 7 April 2013 (UTC)
Stable version date
Description | date and year of publication of stable version |
---|---|
Data type | Point in time |
Template parameter | it:template:Software |
Domain | software |
Example 1 | MISSING |
Example 2 | MISSING |
Example 3 | MISSING |
Source | infobox |
Proposed by | ★ → Airon 90 10:49, 29 March 2013 (UTC) |
- Oppose, wrong data type. Change it and you'll get my vote. --Nightwish62 (talk) 13:02, 29 March 2013 (UTC)
- I copied it from other template because I don't know hot to compile this template. What should I have to insert? --★ → Airon 90 15:25, 29 March 2013 (UTC)
- I've set it, never mind. It isn't supported yet, though. --Ricordisamoa 19:11, 29 March 2013 (UTC)
Support --Toru10 (talk) 20:35, 29 March 2013 (UTC)
- I've set it, never mind. It isn't supported yet, though. --Ricordisamoa 19:11, 29 March 2013 (UTC)
- Still Oppose. I learned yesterdays about qualifiers and therefore I don't support two individual properties for 'stable' or 'unstable' anymore. We should better use a neutral 'version' and mark an entry with a qualifier if this version is stable or not. See an example of qualifiers here. --Nightwish62 (talk) 15:32, 30 March 2013 (UTC)
- now Oppose --Toru10 (talk) 16:06, 30 March 2013 (UTC)
- Not done Per consensus against its creation. — ΛΧΣ21 19:36, 7 April 2013 (UTC)
game engine / motor de juego / motor de jogo / Game-engine / moteur de jeu
Description | game engine used to develop a game |
---|---|
Data type | Item |
Template parameter | en:template:infobox video game engine |
Domain | games, video games |
Example | System Shock 2 <game engine> Dark Engine |
Source | List of game engines |
Proposed by | — ΛΧΣ21 |
- Discussion
This is another thing we need for video game items. — ΛΧΣ21 18:30, 7 April 2013 (UTC)
- Support (damn, too late) Comment Renaming: We should rename it to simply "engine", so it could be used for other software (beside games), too. (Note in advance: This item couldn't be merged with an other item (eg. "engine"), completely different meaning.) --#Reaper (talk) 19:30, 8 April 2013 (UTC)
- Agree. This can be named as "engine", so that it can be used for other types of software. — ΛΧΣ21 15:52, 11 April 2013 (UTC)
- I believe that this is a very necessary property, and I really need it for the video games task force. Hence, I decided to go ahead and create it: Property:P408. — ΛΧΣ21 01:55, 13 April 2013 (UTC)
distribution, media
Description | ways (media) how a video game, software and (maybe) film and music is distributed. |
---|---|
Data type | Item |
Template parameter | en:template:Infobox video game media |
Domain | games, paid software and (maybe) films |
Allowed values | download, DVD, CD, record; but maybe also "Origin" or "Steam" |
Robot and gadget jobs | not really possible, to various |
Proposed by | #Reaper (talk) |
- Discussion
We should think about how to perform with things like "download" in combination with "Origin" or "Steam". Maybe download as value and Steam as a qualifier of it? Or simply Steam as value? --#Reaper (talk) 20:05, 8 April 2013 (UTC)
- Both ways can work, tho i'd prefer 'download' as value and Steam and Origin as qualifier. Notwithstanding, most games have the same distribution type, so I am not sure if we need this property... — ΛΧΣ21 07:18, 13 April 2013 (UTC)
- Yes, I think we should use qualifiers for "Steam" and similar, too. But I think (I see no other way) we need this property, because there is a row in the infobox / its used there. --#Reaper (talk) 12:57, 14 April 2013 (UTC)
- Support I agree with the above. We need it, along with some qualifier (if necessary) to add the specific distribution venue. — ΛΧΣ21 21:01, 17 April 2013 (UTC)
- I went ahead and created it as Property:P437: "distribution method used to release a work". This way, it can be done to specify the methonds used to release a software, a film, a recording, or any other relevant work. Cheers. — ΛΧΣ21 01:36, 19 April 2013 (UTC)