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.SvenManguardWha?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)
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)
StrongSupport 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 articleen: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)
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 likeen:Template:Infobox settlement anden:Infobox Province or territory of Canada. Note that these can display multiple time zone values, e.g. as inen: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)
Done This was created by an IP atProperty: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 asProperty:P421. --at12:59, 14 April 2013 (UTC)
Description: language code as used by Wikimedia projects, e.g.ja forJapanese
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?
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)
CommentRelations 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)
Oppose OSM IDs are not so stable as it seems. I would prefer to link from OSM to Wikidata withhttp://wiki.openstreetmap.org/wiki/Key:Wikipedia . There already over 200.000 links exist and we use these in WikiMiniAtlas overWIWOSM. 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 fromQ34444 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)
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)
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 likeUser: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 useinstance 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 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 -Talk04: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
Description: The species which defines this genus, or the genus which defines this family. For example, the type genus of Drosophilidae isDrosophila, and the type species ofDrosophila isDrosophila funebris.
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)
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:
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)
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 -Talk06:23, 12 April 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)
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 atProperty: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. —06:52, 10 April 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 ExampleQ274744 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)
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)
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)
Done What about "Taken from", which is the opposite of "Singles" ("Singles": album → song. "Taken from": song → album)? --★ → Airon 9010:27, 4 April 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)
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
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))
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 haveedition 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" (seefor 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)
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.
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", usingsubstring(code,3,4) can easily tell us their administrative division types (substring(code, 3,4) of the former is "01" so it's adistrict of Beijing, whilesubstring(code, 3,4) of the latter is "02" so it's acounty 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)
Comment Alternatively to this proposed property, the qualifier "former" could be used, but I don't know if this is technically possible. --NormanB (talk)22:37, 15 March 2013 (UTC)
Question: Dear Snipre, would it be an option for you to implement this property now and have it replaced (by a bot) with ["is a(n)" + qualifier] when qualifiers become available? That way we can move on with entering knowlegde without having to wait for software development. --NormanB (talk)11:03, 16 March 2013 (UTC)
As qualifier will comes in the future you can already add the statement using the property "instance of" and let the date for later. It is the same as putting a new property "was a" and to wait to add later the date. No wikipedia will use data from wikidata to replace infoboxes before several weeks or month.Snipre (talk)22:21, 22 March 2013 (UTC)
Comment Since qualifiers may not be available for a while and there are a lot of "former" type items on Wikipedia, I am looking for a temporary solution. The mentioned "was a(n)" could be this temporary solution imho, but maybe "is a former" or "former instance of" would be better?NormanB (talk)00:54, 18 March 2013 (UTC)
Weak support. This sounds better than a combinedis/was a(n) property, although that may be easier to automatically map to Wikipedia infoboxes and lists.Mange01 (talk)08:37, 20 March 2013 (UTC)
Support as interim property. I think we should proceed modeling historical data on WD, but as discussedin the project chat qualifiers are the way to go. Since qualifiers are not available right now, I support this property as a temporal, migrate-able solution. --Faux (talk)07:36, 22 March 2013 (UTC)
Oppose, better to wait for qualifiers instead I think. This might be just the thin end of the wedge; a "former" variant of many other properties would probably be clamoured for next. --Avenue (talk)14:06, 25 March 2013 (UTC)
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
Electronelement ofLeptonOppose, but a singleElectron iselement of the group of all/someLeptons. But such items (=set of all instances of one concept) does not exist, I hope.
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)
Oppose This property is essentially an undifferentiated alias forinstance of (P31) andsubclass 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 theis 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)
For instance, the articleen: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)
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 9010:56, 29 March 2013 (UTC)
No, X's discography is not a "list of X", it's a "list of albumsby X", so list of is not appropriate (also,there's not going to be a "album by X" item in almost all cases).Superm401 -Talk00:30, 8 April 2013 (UTC)
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. —07:30, 9 April 2013 (UTC)
Support Seems useful. I usedpart 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 -Talk02:35, 4 April 2013 (UTC)
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)
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)
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)
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 1example 2) Only in case if we decide to use only one i guessplatform 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)
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. —07:06, 7 April 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)
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)
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)
Comment actually I (create of the proposal) am not even convinced. AISN does not Identify a Work but a release of this work, same as ISBN. But even the same release can have multiple AISNs. AISNs are collected by the musicBrainz Database where they have a release-based-logic. At least recorded works can be identified by [Creative_work#MusicBrainz_Identifier_.2F_MusicBrainz_Identifikator_.2F_num.C3.A9ro_d.27identification_MusicBrainz musicBrainz Identifier] --Shisma (talk)15:08, 2 April 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 ofpreceded by, andsucceeded 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 arepredecessor,successor,incumbent with suitable aliases depending on how it is implemented. —billinghurstsDrewth09: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 propertyhere 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(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)
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 qualifiershere. --Nightwish62 (talk)15:34, 30 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 qualifiershere. --Nightwish62 (talk)15:34, 30 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 9015:25, 29 March 2013 (UTC)
StillOppose. 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 qualifiershere. --Nightwish62 (talk)15:32, 30 March 2013 (UTC)
Support(damn, too late)CommentRenaming: 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. —15:52, 11 April 2013 (UTC)
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... —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:01, 17 April 2013 (UTC)
I went ahead and created it asProperty: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. —01:36, 19 April 2013 (UTC)
Support Of general interest. --Kolja21 (talk)07:10, 5 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.SvenManguardWha?04:25, 7 February 2013 (UTC)
Oppose, per Sven. This should be handled by the software. --Yair rand (talk)11:39, 7 February 2013 (UTC)
Done This was created by an IP atProperty: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 asProperty:P421. -- at12:59, 14 April 2013 (UTC)
Question What should be the datatype? Item? --MichaelSchoenitzer (talk)01:40, 20 March 2013 (UTC)
Not done per consensus against its creation. —00:29, 14 April 2013 (UTC)
Weak support Can be useful for some programs but potentiallyabused. --Ricordisamoa23:59, 25 March 2013 (UTC)