Very often we have statements saying that A is a collection of some sort. While we would ideally have all of those parts listed under has part(s) (P527) this isn't always possible and it isn't easy to judge, by looking at has part(s) (P527) if that is complete. This property would allow a statement to be qualified with the number parts/components.
This should only ever be used as a qualifier and should only be used where the number of components are known and finite.
In addition: this is not unlike the way number of faces, edges and vertices are presented in for instance cube (Q812880). For that reason special properties on numbers of these, like P1569 (P1569), have been deleted. Lymantria (talk) 07:50, 3 June 2016 (UTC)
I've always read quantity (P1114) as working the other way around. I.e. I want A has # parts whereas P1114 says A occurs # times. The above solution could work though but it becomes a bit weird in that you end up mixing generics (building) and specifics (named buildings) in has part(s) (P527). I.e. in your example it's fine while you only have
Which is why both Thryduulf and TomT0m pointed out "has part of the type", where, if the item having a part is an instance (of anything but the "class type"--I suppose there may be some exceptions to this parenthetical, but I don't know of them) the item having a part can use the property "has part of the type". Now, there may be some ambiguity at that point--does the location have 19 buildings + Time-Life building or does it have 19 buildings total and one of the buildings in the set is the Time-Life building? I suppose we can qualify this with criterion used (P1013) and e.g. "total set" "partial set" (if we had those items I suppose). --Izno (talk) 11:53, 3 June 2016 (UTC)
Thanks. The combo fills my needs and I end up with a final solution like:
. With that I'll happily withdraw my proposal. Might be worth adding this as an example/comment on the discussion page of those two properties though. /André Costa (WMSE) (talk) 09:46, 8 June 2016 (UTC)
The immediate reason for this proposal is to allow it as a qualifier for publications (see frequency of publication proposal above) but it could be used with many different items and properties and may (depending on the structure we eventually use) be a key component of the way to story "opening hours" currently being discussed. There may be a small overlap with valid in period (P1264) but I'm not sure that a day of the week is quite how that property is intended to be used. Thryduulf (talk: local | en.wp | en.wikt) 23:48, 24 May 2016 (UTC)
Comment It makes sense as a qualifier for "frequency of publication"-like properties – not so much for the other examples given, IMO. "The Queen's birthday is on some Saturday" is not very helpful information - there is literally an infinity of Saturdays that would fit that description.--Anders Feder (talk) 21:28, 28 May 2016 (UTC)
Actually knowing the Queen's official birthday (which incidentally is distinct from her actual birthday) is always on a Saturday is useful, as it can be linked with other events that happen on Saturdays for example, or dates determined with a day of week + date range. I agree that is only minorly useful for this example, but something like e.g. Jumu'ah (Q924037) → Friday (Q130) it is a much more significant aspect of the item. Thryduulf (talk: local | en.wp | en.wikt) 23:24, 29 May 2016 (UTC)
(Just putting location as a statement on the Eni item does not let understand that it's not the company's offices location that is being described, but the location of the extraction points.) GiordanoArman
Discussion
Weak oppose without an example, but if I've understood this properly I think using operator (P137) and/or owned by (P127) on the item about the extraction site (which should have coordinates) would be a better way of doing this. Large corporations like BP (Q152057) would have massively long lists for this property, and it would make it harder to track changes in ownership that way too. Thryduulf (talk: local | en.wp | en.wikt) 10:31, 8 May 2016 (UTC)
Comment @Mcnabber091: make sure what you are proposing actually makes sense as a property - I don't understand how the "list of sovereign wealth funds" could work as a property for example. Maybe you what you want could be done better by creating that as an item representing a class, and then other items could be indicated to be of that type via instance of (P31)? It's good if possible to pull an example from an existing wikipedia article (the article would have an item ID, the property would then allow a claim on that item with a certain value). If you have some good examples it makes it clear what a property is for and how it would work. Also I would expect to see a number of different people showing support for the property before it could be created, and at least a week's time for discussion. ArthurPSmith (talk) 15:11, 18 December 2015 (UTC)
@Filceolaire: This property would be for the total government + private foreign aid donation. Mcnabber091 (talk)
Isn't this usually a pretty small figure? Are macroeconomists really that interested? Isn't 'remittances' more important that private foreign aid in most cases? Joe Filceolaire (talk) 22:01, 23 December 2015 (UTC)
Some developed countries have aid outflow of 1% of GDP. Although this is small, I believe it has a macroeconomic effect and should be a Wikidata property. I think that remittances inflow/outflow should have it's own property, Mcnabber091 (talk) 09:21, 25 December 2015 (UTC)
Comment What I miss here is an example of how this is supposed to be used, and what source is to be used. Apparently this is not about government expenses alone, which will make it difficult to find figures that are reliable and compatible between countries. Lymantria (talk) 13:40, 22 April 2016 (UTC)
Comment Not 100% of foreign aid inflow goes directly to the government. This property includes private and publc recipients of aid. Sometimes aid flows into the economy without going first through the government. Mcnabber091 (talk) 09:26, 25 December 2015 (UTC)
Comment What I miss here is an example of how this is supposed to be used, and what source is to be used. Apparently this is not about government to government alone, which will make it difficult to find figures that are reliable and compatible between countries. Lymantria (talk) 16:51, 2 May 2016 (UTC)
@Srittau: You should go to econfactbook.org, pick any of the countries, and then scroll to the bottom of the page. There you should see a good example of how the property for foreign aid inflow should look. All of the properties I have proposed are meant to replication econ factbook (see the United States article for the complete complete statistics). BTW thanks for all the suggestions on the properties so far. Mcnabber091 (talk) 01:36, 12 June 2016 (UTC)
State and local combined government revenue
Not done
Description
combined total of state and local government revenue.
@Filceolaire: I think that this property is needed because I think it will be hard to internally calculate it within Wikidata. Most state and local governments don't easily provide this information, so it would be unrealistic that Wikidata could sum up every city and localities' budget entered into Wikidata and produce a good estimate. State and local combined government spending can be found for the United States in this report: http://www2.census.gov/govs/local/summary_report.pdf. I like this type of estimate because it reliable. Mcnabber091 (talk) 09:46, 25 December 2015 (UTC)
I think that for calculable properties, I would suggest having two references: the statistic from directly for a source and our internally calculated statistic. That way the reader would have both. Mcnabber091 (talk) 21:16, 25 December 2015 (UTC)
@Lymantria:This property should apply to every country. It combines all of the government budgets into a total budget and then a balance is determined. Some countries provide this information such as the United States.Mcnabber091 (talk) 06:10, 17 May 2016 (UTC)
@Mcnabber091: The problem is that not all countries have the same form of subdivision as the USA have. Actually, many of them don't. Shouldn't the property read "combined revenue for all subnational governments within a country"? Same for the propositions on "state and local governments combined" below. Lymantria (talk) 07:11, 18 May 2016 (UTC)
Comment I think that for calculable properties, I would suggest having two references: the statistic from directly for a source and our internally calculated statistic. That way the reader would have both. Mcnabber091 (talk) 21:16, 25 December 2015 (UTC)
@Lymantria:This property should apply to every country. It combines all of the government budgets into a total budget and then a balance is determined. Some countries provide this information such as the United States.Mcnabber091 (talk) 06:10, 17 May 2016 (UTC
Comment I think that for budget balance, and other calculable properties, I would suggest having two references: the statistic from directly for a source and our internally calculated statistic. That way the reader would have both. Mcnabber091 (talk) 21:16, 25 December 2015 (UTC)
@Lymantria:This property should apply to every country. It combines all of the government budgets into a total budget and then a balance is determined. Some countries provide this information such as the United States.Mcnabber091 (talk) 06:10, 17 May 2016 (UTC)
I would have an item with a particular rating ("E for Everyone"/"M for Mature") with this property on it. I think that's what you're proposing, so I support. No need to qualify--just make it number with units? --Izno (talk) 16:09, 30 March 2016 (UTC)
On the one hand, I Support the property, if only we could find a more descriptive label. On the other hand, I'd Comment that we need a way to indicate the nature of this "minimum age" (we really need a better name), whether it means that parental guidance is suggested for ages above, not recommended for ages below but not restricted, restricted to ages above unless accompanied by an adult, restricted to ages above, or adult content. (In Hungary we've only had the first two. It's fascinating to me that there are Western countries where you won't be admitted to a screening if you're not old enough.) – Máté (talk) 16:42, 30 March 2016 (UTC)
Come to think of it, even the rating of "R" in America allows for parental supervision, if memory serves. --Izno (talk) 17:09, 30 March 2016 (UTC)
"Minimum Accompanied Age" is only used on EIRIN and RSVR (RARS), nine ratings, and in all cases it's set to the same value as "Minimum Unaccompanied Age" (which is used 121 times). Even if the system made sense and was used, it doesn't begin to describe properly the complexity of the issue. On the other hand "minimum unaccompanied age" already sounds somewhat better than just "minimum age". We may have a "minimum unaccompanied age" property (this one), and an "accompanying criterion" property/qualifier with item datatype with possible values: N/A (Q929804) (when the value is 0)/parental guidance suggested/not recommended/accompanying adult required/restricted/adult content. – Máté (talk) 05:00, 12 April 2016 (UTC)
"accompanying criterion" would have to be a String monolingual text type. If we're going to do that, just label it "restriction" to make it more widely useful. We can also make an opposite property called "allowance". Those two along with "minimum age" could then all be used in various other contexts, like video games or any other age-limited activities. -- Netoholic (talk) 08:18, 12 April 2016 (UTC)
I assume, you're thinking of monolingual text, not string. In any case, item datatype would have more (research) use, as categories with similar nature could be easily grouped together, or even weighted according to their "strictness" when calculating an average rating (of a work/a system/a year) to be used as a variable. – Máté (talk) 08:42, 12 April 2016 (UTC)
The problem is the very subtle wording differences would make managing items pretty daunting. See en:Motion picture rating system for all the variations. I'd rather manage them as values within a single item for each rating. The restriction text isn't conceptually a different "thing" from the rating, its descriptive. If you want to group and weight, use the ratings items themselves, not the "accompanying criterion". -- Netoholic (talk) 16:10, 12 April 2016 (UTC)
The article you linked is exactly the example how you can easily group them and use the item-system on them, just take a look at the comparison table. This is invaluable information that you need for grouping and weighting, the rating items themselves are not enough. The two, however, are not mutually exclusive. We can store both the item-type nature of the rating and the exact wording of their description quoted from the corresponding law or guidelines. All I'm saying that the item-type is something that is useful. Especially given, that the description often doesn't even gives you the true nature of the rating, but you have to go back to the law and find about it in the context where it is defined. – Máté (talk) 16:59, 12 April 2016 (UTC)
@Pigsonthewing, Máté, Jura1: Done as proposed. While there is much more that could be modelled on individual rating items, considering the various different rating systems around the world, this is a good start. Also, this property could be useful in other contexts. --Srittau (talk) 22:51, 11 June 2016 (UTC)
The corresponding template Template:HKMDB title (Q8140673) has already been created on 8 different wikis and is used on more than 500 pages in the English Wikipedia. HKMdb contains more than 18,000 movies and has a much better coverage of Hong-Kong and Chinese movies than IMDB. Koxinga (talk) 23:41, 19 May 2016 (UTC)
Looking through the constraint violations for event interval (P2257) I noticed that t was being used to indicate a publication frequency on several items, but the domain for that property is restricted to events and I think there is sufficient difference between "this item reoccurs with this nominal frequency" and "this items releases an issue/edition on this standard schedule" that a new property is better than broadening the old one. See also the "day of week" proposal below that could be used as a qualifier to this property.
I debated a couple of issues with myself when proposing this:
number or item datatype: some publication schedules are more complex than a standard interval, e.g. for a time period the Reader's Digest published 10 issues a year, but 0.8333 year (or 10/12 year if/when we get fraction support) can represent that. If people prefer the item route though then I will support that. Another option would be for three new properties: issues per week, issues per month and issues per year. That is getting too complicated though I think and I would need convincing before supporting that (I am open to being convinced though).
"publication" or "publication or broadcast": is something like this desired to represent the frequency of TV and radio programmes? As I don't really know the answer to that I've decided not to include this in my initial proposal but I'll happily and readily support that expansion if there is a desire. Thryduulf (talk: local | en.wp | en.wikt) 23:27, 24 May 2016 (UTC)
Discussion
There's some problem with this property in that some publications do not have a regular publication schedule. I had a discussion on en.WP just this week about the subject. It may be better to infer this property by making items for the published works and linking them via "series" or "part of" or similar. --Izno (talk) 10:17, 25 May 2016 (UTC)
That could work for less frequent publications, but would not be realistically valid for anything publishing more frequently than about weekly, and items for each issue of daily newspapers would overwhelm wikidata very quickly. The alternative I discussed above using "item" could work here (have an item for "irregular schedule" or something), or maybe we should title this "regular publication schedule" and set it to no value for those publications that don't have a regular schedule? Thryduulf (talk: local | en.wp | en.wikt) 10:32, 25 May 2016 (UTC)
Comment Isn't this proposal on publication interval (how much time between two publications) rather than publication frequency (how many times per amount of time)? I think I would prefer a real "publication frequency" property, as it is more flexible. For most newspapers you could say "6 per week", which is more accurate than a "at a 1 day interval". Lymantria (talk) 15:56, 31 May 2016 (UTC)
That would indeed be more flexible, but I am unsure how a property with two variables can be stored in Wikidata's structure? I came accross this same issue with ratios and gradients, for the first we fixed it as a 1:n ratio (e.g. using 1:-2 rather than 2:1) and for the latter we restricted it to a percentage. Here it would I think require four properties - issues per day, issues per week, issues per month, issues per year - making it harder to query and harder to maintain. Thryduulf (talk: local | en.wp | en.wikt) 23:47, 31 May 2016 (UTC)
Support This would be a very nice property to have. It resembles the predicate dcterms:accrualPeriodicity. --Andrawaag (talk) 19:13, 2 June 2016 (UTC)
@Thryduulf: I think this should be solved by using a qualifier "per/relative to" (but not relative to in the sense of relative to (P2210)). Examples would be:
Apart from that, still I am thinking over this frequency issue becoming harder to query and maintain. I think that is indeed a risk. Lymantria (talk) 10:53, 3 June 2016 (UTC)
I suppose we could partially (but not completely) alleviate that with "per day", "per week", "per month", "per year", etc items used as units of frequency but again that might make querying more difficult as the number of time periods is potentially limitless, so I still prefer the original proposal (although your point about the name is good). Thryduulf (talk: local | en.wp | en.wikt) 15:56, 3 June 2016 (UTC)
Not exactly. Though The Hobbit trilogy was shot in 48 fps, most people watched it in 24 fps at the movies, while in 23.976 fps or 25 fps at home. This could be "filmed at frame rate". But my proposal was something different, a qualifier for duration (at what frame rate was the given duration measured), since The Hobbit has a different running time on home video in the U.S., in Europe or at the cinema. – Máté (talk) 20:32, 19 May 2016 (UTC)
The Shakeosphere site is a scholarly project of the University of Iowa, collecting edition information on publications in English to 1800. It has around 54K person identifiers (authors and others).
Looks good, and the early modern project rushes ever on. Pity they don't seem to have standard identifiers we can crosswalk to - not yet, at least. Andrew Gray (talk) 20:07, 24 May 2016 (UTC)
The chancellor is the name for the highest-ranked university official in many english-speaking universities. Synonyms include President. Rector (P1075) is less commonly used in English-language schools for the same item.
Items about universities should list the top officers; particularly in the US, this is generally the Chancellor and Provost, or President and Provost. The chancellor (or president) is in charge of the whole university; provost is in charge of the academics. There is not another property that fits this information that isn't so generic as to be meaningless, as far as I can tell (president right now redirects to chairperson, but the chairperson at a university has an entirely different meaning, typically meaning the chair of the governing board). I am hesitant for instance to list the chancellor of US universities using the current property choices, because I think it's misleading and confusing (since the chair is an entirely different person/role, and in the US "Rector" often doesn't actually exist as a title, but there's no way to indicate this). Note: this is needed in Wikipedia as it's a position that occasionally changes, and I often see wrong information in articles about who is who. Phoebe (talk) 04:41, 18 April 2016 (UTC)
In the UK, and apparently often in other Commonwealth nations, Chanellor is a figurehead position and the Vice-Chancellor (or sometimes President) is the one who runs the institution as a chief executive. This should probably be represented somehow, but I don't immediately know if a separate Vice-Chancellor property is the best way to do that. Thryduulf (talk: local | en.wp | en.wikt) 12:12, 19 April 2016 (UTC)
Oppose I think there are too many leading positions one can think of to make all seperate properties. I propose a generic one below.Lymantria (talk) 14:52, 3 May 2016 (UTC)
Per above, particularly at universities in the United States, the Provost is the top academic position and there is not currently a way to show this relationship. Phoebe (talk) 04:48, 18 April 2016 (UTC)
Pigsonthewing, as per above, what would you use to indicate this for the university item? (I am not familiar with something that would work). thanks! -- Phoebe (talk) 15:19, 2 May 2016 (UTC)
@Lymantria: Seems like that would be redundant data. If there's already a statement pointing in one direction, we don't need another pointing back. --Yair rand (talk) 21:37, 3 May 2016 (UTC)
For companies we have "chief executive officer" lists, and the individuals then have "position held=chief executive officer, employer=company". I think it's often useful to have something pointing in both directions, because then queries can go both ways. --99of9 (talk) 02:33, 4 May 2016 (UTC)
Ok -- but I'm not sure that makes sense, since the leaders of the university are an important part of the information about the institution, and having to figure out a complicated query to get that as part of the item doesn't seem super usable. -- Phoebe (talk) 01:35, 5 May 2016 (UTC)
Oppose I think there are too many leading positions one can think of to make all seperate properties. I propose a generic one below this.Lymantria (talk) 14:51, 3 May 2016 (UTC)
http://www.searchupc.com/?q=$1 or http://www.upcitemdb.com/upc/$1 or http://www.upcdatabase.com/item/$1
First digit meaning
UPC
EAN
Type
0
00
Products
1
01
2
02
In-house: Encoded weight
3
03
UPN codes (medicine/pharmaceutical)
4
04
In-house use (loyalty cards/store coupons)
5
05
Manufacturer coupons
6
06
Products
7
07
8
08
9
09
Manufacturer coupons
Motivation
From MusicBrains:
Barcodes are numbers used as stock control mechanisms by retailers: as such they are highly standardised and well recognised, and form an invaluable identifier for communication between companies.
So I want to add UPCs to video games as this is the only unique identifier that exists (like an ISBN). This property would make it easy for other systems to integrate Wikidata. Or the reverse such as searching Amazon by UPC.
A cool thing we can do is auto create the barcode itself with Lua and image segments. The only question is should it be complicated by including the European superset, EAN?
Weak oppose I believe Wikipedia/Wikidata simply isn't granular enough for this to make sense. Usually there are different barcodes for different versions, packaging sizes, multi-packs, regions, etc of a product. Even simply a change in packaging design may result in a new barcode. So that may result in an item having tens or hundreds of bar codes attached. For example, the Cheerios (Q2425291) item won't just have one value, it should have at least 71 according to upcitemdb.com. Intgr (talk) 08:54, 17 March 2016 (UTC)
For video games, UPCs are like a book's ISBN. As an example, The Orange Box (Q374556) is more findable by its UPC 0-14633-09852-5 (4,000 Google results) than by its ISBN (which is unusual to have) 0-7845-4306-2 (5 Google results). Dispenser (talk) 04:20, 25 March 2016 (UTC)
Oppose Unfortunately it is not that easy. For example, the UPC/EAN for the Orange Box is not just "5030931058936". That is just the EAN for one particular edition. The German, French, and other language edition have a different code. The UPC for Cheerios is just for a specific package size. The 685 gram package listed here has a different number. UPC/EAN in general is much for volatile than, for example ISBN numbers. --Srittau (talk) 23:50, 5 May 2016 (UTC)
Comment maybe we could attempt to determine a range of products where this could be helpful. --- Jura15:21, 19 May 2016 (UTC)
Support I am agree with @Intgr about this require more wikidata granularity but this would give a new powerfull functionality to wikidata as is explained here https://meta.wikimedia.org/wiki/WikiObject. Probably it's early to start using wikidata in this way since nowdays there are not tools developed speciffically aimed at listing and searching objects (https://query.wikidata.org/ would be the closest thing) but this could be reached little by little.Qupro (talk) 06:22, 12 May 2017 (UTC)
Comment I think this is best left until we have the number type, and know how it will function, because we may only need one generic property for "size in bytes" which can be used as a qualifier. So, for example, we may be able to claim that a CPU has part L2 cache with qualifiers, quantity = 2, size = 8MB. Let's not create 100s of properties for speeds and dimensions. Danrok (talk) 02:11, 27 January 2014 (UTC)
@MisterSanderson, Tobias1984, Danrok, Micru: So quantity datatype is now available, and we have megabyte (Q79735) and related items so in principle we can move ahead. However Danrok 's comments should be taken into account. We don't actually have any property (that I can find) that would give a generic "size" suitable for showing the number of megabytes, pixels etc - I think that property should be created first and may be all we need. Also I couldn't find an item corresponding to L2-cache: the only related one I think is cache (Q165596) (which has aliases include L2 and L3). Please look into some of these and let's have a more organized proposal for computing properties here! Is "has part" generally a suitable way to document the components of a CPU, camera, phone, etc, rather than having separate properties for each piece? That makes sense to me... ArthurPSmith (talk) 20:11, 11 December 2015 (UTC)
Well maximum capacity (P1083) seems very specific to counting people, has constraints that would need to be modified, it's been used by a Russian project etc (see discussion page). I think a new more generic property is warranted. Maybe let's add it under Wikidata:Property_proposal/Generic @Danrok: can you take care of making the proposal? Or maybe I will try later this week if it's not done yet. And @MisterSanderson: - what we are specifically proposing here is as an alternative to your property, to use the combination has part(s) (P527) with an item for "L2 cache" and a qualifier specifying "capacity" (size) in MB or GB or whatever appropriate unit. This seems reasonable to me and I think it's preferable as a rule to use more generic properties where they make sense. What are your feelings on the matter? ArthurPSmith (talk) 20:34, 14 December 2015 (UTC)
I marked this proposal as withdrawn, since I don't expect it to get any traction if the proposer has lost interest. That said, I would support a new proposal. --Srittau (talk) 22:49, 6 June 2016 (UTC)
There are differences in the usage of the number of minutes in different countries; this would result in misleading information, might need to be disambiguated. Also, consider adding a "classification" property — i.e. "Category 1," "super typhoon," "severe tropical storm," etc.? Hurricanefan24 (talk) 13:50, 18 March 2013 (UTC)
@Thryduulf: Yes there would be mandatory qualifiers for duration because the quantity is without rigorous definition otherwise. Additionally it should be qualified with the quality of the estimate - operational, postanalysis, measured with reconnaisance, etc.--Jasper Deng (talk) 23:54, 31 May 2016 (UTC)
I don't think speed (P2052) should be used in this manner to record the wind speed produced by a storm system, as I would expect a speed property on a storm item to record how fast the system was moving. Something like
I would not oppose if this were changed to something more generic like "wind speed" with "Maximum sustained" etc as qualified, point in time, references.. -- Netoholic (talk) 13:16, 24 April 2016 (UTC)
@Netoholic: No, qualification using measurement scale (P1880) would be incorrect, because "maximum sustained winds" is seldom something that can be directly measured. For this reason, meteorological agencies tend to limit it to integer multiples of 5 knots and even in the presence of direct measurements of wind, always acknowledge that these are estimates.--Jasper Deng (talk) 23:51, 31 May 2016 (UTC)
Support either a "wind speed" property or the "has quality" proposal above, by Thryduulf. I think I would slightly prefer a dedicated wind speed property, qualified as desired, with "point in time"/"end time"/"start time"--maximum speed can be derived from that information. --Izno (talk) 13:59, 16 May 2016 (UTC)
Support However, I disagree that this should not be automatic. I hope we can import the entire HURDAT database and other track files to Wikidata where they can be more easily referenced for Wikipedia's purposes.--Jasper Deng (talk) 23:45, 31 May 2016 (UTC)
@HakanIST: I am not sure this had consensus as "max sustained wind speed". I only supported a more generic property, and the same with Thryduulf and Netoholic. Sven's !vote is ancient as is Gold's, and Hurricane fan is retired. @Jasper Deng: would you support a more generic property? --Izno (talk) 14:39, 10 June 2016 (UTC)
I didn't actually support (or oppose) this proposal. I opposed using speed (P2052) and commented that a specific property would be better than using a construction involving has characteristic (P1552), but didn't put my name to this specific proposal as I was not certain about the approach to recording the duration of measurement (I think it is very important that it is somehow noted so like can be compared with like). I hadn't seen (until now) Jasper Deng's comment about measurement only being an estimate which makes me wonder more about how the estimations are performed, and how that relates to this property - are there multiple methods? If so should they get qualifiers or separate properties? I don't know if I oppose it finally, but I don't support it as it and my thinking at the moment and wouldn't have called this a consensus at this point. Thryduulf (talk: local | en.wp | en.wikt) 21:50, 10 June 2016 (UTC)
Read any National Hurricane Center advisory and you'll see. See for example [1]. Not only are there multiple ways of measuring or estimating it, but we also need a qualification using 1-, 3-, or 10-minute.--Jasper Deng (talk) 21:57, 10 June 2016 (UTC)
Knowledge crystals (knowledge crystal (Q23691297)) are versatile information objects that answer specific research questions. The answer to this question often has a written description, but typically the core of an answer is a quantitative result. Results of different knowledge crystals are measured in different units, and only a fraction of knowledge crystals have a result that can directly be represented using an existing property. In the example, the suggested property "knowledge crystal result" could be replaced by number of cases (P1603). But if the disease burden had been measured using quality-adjusted life year (Q614165) with unit quality-adjusted life year (Q23893355), there would not be a good property available.
The point is that the relations between the question and the answer of a knowledge crystal may be very different from each other and such that there are no existing properties describing them. Therefore, it makes sense to create one property that is generic enough to describe the relation of any question and answer of a knowledge crystal, rather than creating a new property whenever a new kind of relationship emerges.
Of course, specificity is needed in describing the relation of a question and an answer. This is done in several ways:
The result may vary e.g. between subgroups, as by observation year or country in the example. This variation and subgroup-specificity is handled by using qualifiers. Again, it is easier to use or create qualifying items than create properties.
The question must be known to be able to understand the result. This can be achieved by locating the question into the description of the item of a particular knowledge crystal. A benefit of this is that the question can be described in several languages.
In this way, all essential information to interpret the question and answer of a knowledge crystal can be achieved by creating a single property as suggested here: knowledge crystal result.
Jtuom (talk) 20:31, 20 April 2016 (UTC)
Discussion
Comment This appears to be exclusively associated with Opasnet and a Finnish health institute, and I don't see a large number of actual results that this would be applied to (at least not yet). Jtuom do you have an estimate of how many times this property could be used based on current data? We do have a generic property in the form of "numeric value" that could possibly be expanded in domain if the lack of suitable properties was really a problem, but I think it would be better to add these statements using existing properties and propose any missing properties as discovered in that process first. ArthurPSmith (talk) 19:01, 21 April 2016 (UTC)
Comment @ArthurPSmith: I am trying to be proactive here. It is true that currently knowledge crystals are mostly used in National Institute for Health and Welfare (Q4354957), but they were designed in such a way that they could be used widely in science and also to support societal decisions. In my own work only (in the field of health impact assessment), I can see hundreds of knowledge crystals with immediate need. For example: disease burden estimates of dozens of risk factors in different countries; disease burden estimates of dozens or hundreds of major diseases in different countries; half-lives of toxic pollutants in the human body or in the environment; average levels of pollutants in food; average intakes of pollutants in different populations; exposure-response functions of major pollutants on causing specific diseases etc. All these are quantitative data that are of importance and interest to people interested in environmental health.
But more importantly, I see knowledge crystals as an effective way to handle and update scientific information in any field, and therefore this should be seen as a generic property that has a large potential. If the property is found out to be useful and effective, it can actually reduce the need of new properties. So, I think it is now important to talk about the theoretical and potential merit of knowledge crystal result rather than think of its current popularity. If it fails in theory, I withdraw my suggestion. If it succeeds, it should be promoted in practice.
I do not agree that numeric value (P1181) could be used instead of the suggested knowledge crystal result. It seems to be used with natural constants and other things that have a single true value. Knowledge crystal results are by nature uncertain, and their values may also change in time (if e.g. an infectious disease is eradicated, its disease burden may decrease dramatically -- or increase, if the health care system fails such as in the case of ebola). --Jtuom (talk) 08:45, 11 May 2016 (UTC)
Comment An important feature of a knowledge crystal is that it has been produced by applying quality control and certain rules. The most important rules are that the result has been produced in an open website where anyone can see the contents and the rationale, and anyone can criticize the methods and premises used. However, critique must be based on science. Therefore, the most common critique is that the result is not in accordance with observed data.
Because of this production process, knowledge crystals can be said to be established scientific information, and conversely, the property knowledge crystal result cannot be used about a result that has not been produced according to the rules. See also [2]. --Jtuom (talk) 11:39, 20 May 2016 (UTC)
Support I support experimenting with this but I think it needs more documentation also. This would be easier to manage if "knowledge crystals" were all coming from a single authority, but right now, the plan is to get knowledge crystal information from Opasnet or the Finnish health institute with which it partners. As I understand, the longer term plan is to use this term for any data produced by a "knowledge crystal" methodology. In the example above, a knowledge crystal query is producing data on how many people died of air pollution in all of earth in a given year. The same dataset that produced that information could produce variations of similar data that seem limitless by human standards. Opasnet is not the only organization that can provide this kind of data. So when this property is used, it would be used in the context of saying, "here is some interesting data", then apply the knowledge crystal property, then say what authority executed the knowledge crystal process. That means that this property probably would never be used without associating it with some authority.
I have a little trouble thinking about this, because I cannot think of examples of Wikidata having been used in this way, but it seems logical to set up this property and experiment with using it. Blue Rasberry (talk)20:28, 20 May 2016 (UTC)
@Bluerasberry: You are quite right: this is experimenting at the moment. I also agree that at the moment knowledge crystals require an authority who curates the content and thus backs up the quality. However, I hope and believe that then when we get practical experience about this, it can be shown that the knowledge crystal methodology, when properly applied, tends to produce high-quality content even if the curator is not an expert (organisation) in the field. One reason to this is that there is a rule saying that relevant information must not be ignored. Therefore, if there are several knowledge crystal variants of the same topic, they must collaborate, resolve possible disputes, and produce a synthesis, thus preventing limitless variation. Such process has already been seen with encyclopedias: previously, there was a large variation of content within the hundreds of different encyclopedias; but Wikipedia brought all encyclopedists to a single page to discuss and synthesise a particular topic, thus reducing variation on what people can read about the topic. --Jtuom (talk) 15:11, 22 May 2016 (UTC)
Yes, but the fact that Wikipedia is reducing variation on what people can read about the topic is, clearly, no guarantee for quality. Good content does not just happen, it takes work. - Brya (talk) 16:48, 22 May 2016 (UTC)
I completely agree. I wanted to emphasize that reduced variation makes it possible to focus the work on one place, where it has the largest impact. --Jtuom (talk) 21:16, 22 May 2016 (UTC)
Oppose I have a hard time understanding the rationale of this property. One could think of some scientific result that is interesting and gives a number as answer to a question. Why seperate it as a "knowledge chrystal result" in stead of just as a piece of information? So why quote all kind of knowledge chrystal results at Disease burden of air pollution (Q23680551) in stead of using disease burden (P2854) at air pollution (Q131123)? I tend to see this as unnecessary duplication of information. A "knowledge chrystal result" is merely a result and should be recorded as such. Lymantria (talk) 15:00, 30 May 2016 (UTC)
Oppose per previous discussion at Wikidata:Property_proposal/Archive/44#Question this property could answer. The varying problem with this proposal is that it's not linking the questions to the answers in any meaningful fashion, and either way could produce a large number of items that would have a single use and no external notability. Generally, this type of stuff is either a) premature for what we're doing b) not in our wheelhouse--and I would tend to think it's probably both. --Izno (talk) 12:08, 31 May 2016 (UTC)
You raise good points. Based on the discussion so far, I can see two alternative ways of using knowledge crystals in Wikidata, as shown with this fictional example about lead exposures in different populations (measured as lead concentrations in blood):
(Traditional) lead (Q708) → property "exposure" (requires a new property) 0.5 umol/l
(New proposal) "Lead concentrations in human populations" (a new item that is a knowledge crystal) → property "knowledge crystal result" (the suggested property) 0.5 umol/l; description: "What is the average lead concentration in blood in the studied populations? (A knowledge crystal with this question)"
Based on these examples, I must admit that the suggested information structure is neither simpler nor clearer than the traditional one. However, it does save us from creating a new property "exposure", which I think is a benefit. On the other hand, if exposure estimates are an important part of Wikidata in the future, maybe such a property should be created.
It is also noteworthy that in both cases, it is possible to use a knowledge crystal in Opasnet workspace as a reference in a similar way as a scientific article. All the scientific discussions, e.g. about how to summarize results from several studies, would be held in Opasnet, and only the results would be brought to Wikidata.
Yes! I missed it! Thanks! I'd like to correct it, but I don't know what value put in "datatype" element of property documentation! I correct it. --Paperoastro (talk) 21:56, 24 February 2014 (UTC)
Comment The format of the data for the separation of a double star would usually be in seconds of arc specified for a particular date of observation or a future epoch as computed from orbital elements. See WDS SUMMARY CATALOG KEY used in the w:Washington Double Star Catalog for example. For multiple star systems such as w:Epsilon Lyrae the value will change slowly over a millennium. For close binaries this data might prove difficult to keep up to date as it will change over time. For example, w:Sirius#Sirius_B has changed significantly since 1994. See the diagram at How to see Sirius B. There is also the problem of a lack of reliable sources for some star systems. --Mu301 (talk) 19:21, 5 February 2016 (UTC)
Note: I just noticed that the IAU Style Manual states that "it is becoming common in astronomy to use the milliarcsecond as the unit." However, I would recommend arcsecond as a more useful unit. --Mu301 (talk) 21:58, 5 February 2016 (UTC)
Comment Note there is not "one" formula for a probability distribution (Q200726). There are mean, variance, PDF, CDF. Another approach could be to use a generic 'formula' property and then use qualifiers.
Support also "TeX string" probably should be rendered as a string given its name - and for example should not be converted to MathML as is apparently planned for some renderings of "Mathematical expression". Distinct properties for mathematical expressions on an item are definitely appropriate as this proposal (and others) makes clear. ArthurPSmith (talk) 13:29, 11 February 2016 (UTC)
Support that would be cool. --18:22, 11 February 2016 (UTC)~---
Good question. :-) The formula shown is for the PDF, while every distribution has multiple formula, CDF, mean, variance, other moments, characteristic function, so what should we do about that? Have a whole series of properties? Or use qualifiers? If the equation is to be used in an infobox I suppose the qualifier approach is not well suited? — Finn Årup Nielsen (fnielsen) (talk) 21:50, 4 March 2016 (UTC)
If we use defining formula (P2534) that way, this proposal (and the next one) is unnecessary? However, this seems to stretch the original intention of defining formula (P2534), where "a theorem or a law" was to be represented. But of course, in broader sense any formula could be seen as representing a theorem or a law. Lymantria (talk) 10:14, 25 April 2016 (UTC)
Comment the English label just says "administration" and the sample item is titled "Cabinet of Germany". Scope is mentioned as country/administrative unit (of subnational entities, I guess) or organizations. Not sure how that matches the proposed German label "Regierung". To match legislative body (P194), maybe "executive body" or "governing body" could work (sample). List at Freebase: governmental_jurisdiction/government, for organizations there is just "board members" and committees. --- Jura10:49, 31 January 2016 (UTC)
"We have executive body (P208) for the cabinets of countries" - Yes, see "P208:Cabinet of Israel" in the item about Israel. But do we have a property for the specific cabinet, in this case "Netanyahou III"? We also have to sort out how we should handle cases when two (or more) persons are cooperating in the leadership. Andorra and San Marino has two princes/capitani reggenti and Swedish municipalities can have several "kommunalråd". We have somewhere agreed to use an item for the group of "kommunalråd" but we have not sorted out how that should be implemented or how it affects for example these two European nations and other nations that has had two or more cooperating chief of states. (Competing chiefs is another question.) The Roman Empire, Russia, ancient Egypt, the biblical Israel and several other nations have at least temporary had cooperating kings. Ok, I went a little out of topic here, but the questions are related. We also have political parties with more than one leader. How the office of the prime minister will look like if such parties ever get the center seat in a government is an interesting question. -- Innocent bystander (talk) 08:55, 4 June 2016 (UTC)
none yet, but could be used if an infobox Indian reserve is created (now those Wikipedia articles use the same infobox as for cities, but reserves have specific information that would make having their own infobox useful, I plan to create one on fr.wp)
Question @Mdmahir: Let me try to understand this. In a constituency there are a number of reserved seats for certain minorities and you want to express this using statements, correct? --Srittau (talk) 13:43, 23 April 2016 (UTC)
In general I like this property, we have a similar concept here in Germany, but I am not sure the modelling you do in Thiruvallur Lok Sabha constituency (Q7785493) is the right way. Instead of cramming all individual elections into the constituency item, you should in my opinion create items for individual elections, where you then could use this as a regular property. Also, I would suggest to name it reserved seats or something similar. Reservation is a bit too generic for my tastes. --Srittau (talk) 21:21, 5 May 2016 (UTC)
the whole model for elections/constituencies needs a deep thought. It looks so differently in different times and parts that it is very difficult to see the whole picture. There is also the problem that we do not have very detailed sources everywhere. -- Innocent bystander (talk) 19:26, 3 June 2016 (UTC)
@Innocent bystander: Personally, I would prefer a new suggestion, based on the discussion above, i.e. not as a qualifier and with proper domain etc. Maybe after a general discussion about how voting and election results are to be modelled. But if you want to reopen this proposal, please go ahead. --Srittau (talk) 12:34, 12 June 2016 (UTC)
I think it could gain from the different formulation, maybe with more detailed samples from two or three countries. Obviously it's something we would want to include. --- Jura12:54, 12 June 2016 (UTC)
I stopped contributing to wikipedia/wikidata after I failed to get consensus because I got disappointed and don't want to waste time. This property is specifically for India elections. Why people confuse, I see people from other regions they able to get it done. -- Mdmahir (talk) 15:19, 7 April 2018 (UTC)
The Molendatabase verdwenen molens (Database of disappeared mills) is a sister database of the Nederlandse Molendatabase (Dutch Milldatabase) (Nederlandse Molendatabase ID (P2863)) and contains a lot of interesting and detailed information on mills in the Netherlands that disappeared or are not mills anymore. Used in nlwiki infobox, but also e.g. in enwiki. Lymantria (talk) 14:55, 29 May 2016 (UTC)
Do you mean "not used as mills anymore"? Or as in, they were demolished completely and something else built there? As for disappeared mills, can you point to such a mill in en.WP? --Izno (talk) 20:45, 6 June 2016 (UTC)
Question Could you please verify the examples? One leads to www.molendatabase.org, while the other leads to www.molens.nl. --Srittau (talk) 21:45, 11 June 2016 (UTC)
While my specific motivation involves linking to time series associated with power tools' sound pressure levels, it has a broad number of applications. We have plenty of Wikidata items on scientific papers, but it would be great if, when possible, we could also link to datasets associated with those papers. My specific example uses this property as a qualifier for a statement, but it could also be a property of a scientific article itself. Where multiple datasets can be attributed to one item, qualifiers such as P794 (P794) could be used. James Hare (NIOSH) (talk) 14:20, 23 May 2016 (UTC)
Storing the real / full name of an object is useful. I considered using the description or as an alias, but this is nuts. Description should descripe the item. And to catch the right entry in the alias array is impossible.
I found no property (like long name or real name); especially companies have often a long name registered, sport fans are using nicknames since centuries. So ... where to place this information? The multilingual problem (like jap.
Sure, we can say: Use the (real) long name as label and drop the familiar name in alias, but then there is a lot of update work to do.
Plagiat (talk) 19:40, 12 June 2016 (UTC)
I think this should probably already be "regex clarification" rather than "syntax clarification". The latter has some potential misuse that I'd like to avoid beforehand. --Izno (talk) 13:42, 6 June 2016 (UTC)
@Izno: IMHO, using this qualifier to clarify the syntax of any other cryptic statement would not be a misuse; I would prefer to allow its use beyond regexes, since it is still pretty specific. -- LaddΩchat ;)13:24, 12 June 2016 (UTC)
Comment I don't think we should just throw out the old "comment" values, they do seem helpful. If this property isn't supported, maybe those comments should move to the respective discussion pages (perhaps as an additional line in the property documentation template?) ArthurPSmith (talk) 20:32, 16 June 2016 (UTC)
This was originally suggested by ArthurPSmith in the proposal for day of week (P2894) with which it is complementary. It is intended as a generic property and so the uses above are illustrative rather than exhaustive. The allowed values could be constrained to just instances or subclasses of month (Q5151) (or a different single item) if the months of various calendar systems were all instances or subclasses of that item - a few are but there appears to have been no systematic structuring of this data (most just use calendar date (Q205892) which is too broad for a meaningful constraint to this proposed property) Thryduulf (talk: local | en.wp | en.wikt) 13:49, 8 June 2016 (UTC)
Oppose as currently proposed, because it does not address any of the issues raised with the previous proposals. - Nikki (talk) 19:33, 14 June 2016 (UTC)
Actually, I was about to propose this property myself when I found this here. Transforming a known singular word into plural may be close to trivial in quite some languages, but it is not in my own language, German (at least there's considerably more special cases in German compared to English). I have read some of the related discussions and agree that this is mostly a linguistic problem and may not be a subject of Wikidata. However, does anyone know any machine-accessible public database that provides singular to plural mappings? Machine-accessible Wiktionary doesn't seem to have arrived by now, right? (BTW: Units of measurement were about the least reason why I was goin to propose this property.) Eri523 (talk) 22:25, 3 January 2018 (UTC)
Hi everybody. Two months ago, I have had the propertyrace time (P2781). With Molarus we continue the work to centralise the datas on Wikidata for cycling and reuse it in possibly 20 Wikipedia thanks to the program Module:Cycling race. teamroster is now finished, perfectly operational and tried like the three first functions, we now start this day to develop generalclassification, a function that will permit to display in possibly twenty Wikipedias the table of the general classification of a cycling race.
To do this, I need two other properties. The first, object of this proposal, is a time property, called "time gap" or somethink like that in English and "écart de temps" in French. With race time (P2781), we give the time of the winner, with the time gap, we say the difference between the winners and other cyclists. Sunday, I was at the fr:Paris-Roubaix espoirs 2016. As you can see, the second arrive 49 seconds after the first, the third arrives at the same time than the second. Note that I will appreciate to have the time expressed if necessary in hours minutes and seconds as we do for a date. It seems it is not again possible, I will ask to the development team. (and sorry for my English) Jérémy-Günther-Heinz Jähnick (talk) 12:40, 2 June 2016 (UTC)
Discussion
This is derived information from the times of the participants in the races. In general, Oppose, unless there's some reason why you cannot derive it from those times. --Izno (talk) 15:21, 2 June 2016 (UTC)
I would also prefer using race time (P2781) for the winner, runner-up and so on and then calculate the difference. I can see this not working, if the runner-up etc. are not modelled, though. --Srittau (talk) 21:02, 11 June 2016 (UTC)
Support I understand the objections, but it is a fact that all rankings (not only for cycling) are presented with a time gap on internet and...everywhere actually. Moreover, for long races, like Tour de France, the total time is really huge (like 100 h), so it is quite long to type the general classification time of each rider without a time gap. Eventually in cycling there are a lots of massive sprint. In this case all times are the same, it is once again quicker and safer, to type "0" than making a copy/paste of the winner time. Psemdel (talk) 20:34, 12 June 2016 (UTC)
To give more informations, if you see this example, we have only race time (P2781) for the winner of the race. For all other cyclists, we have only the time gap because it is the only data that is widely used in cycling. This way to do is the good data model. But your idea is in reality not bad, because during the team time trial as this example you can see that we use the race time, the time gap and the average speed. But this particular classification will be another function. Note also that we can't ask to all user to calculate in seconds the time for each cyclist. I prefer datas entered as we do on cycling (and I work regularly on races) as not data because it is too long/too difficult to enter. Note that these datas like all other datas on Wikidata about cycling are entered here just because users are able to reuse them in their Wikis. Without this, Wikidata would have only datas entered by bots for cycling. Users work here because they have a gain to do it, not for the love of free licences or similar ideology. Jérémy-Günther-Heinz Jähnick (talk) 09:35, 13 June 2016 (UTC)
Support Looks really nice this property to general classification.
Support As this is the way a classification is published. Doing it by calculation would mean one has to calculate the total time for each rider, and the code has to calculate it back. Edoderoo (talk) 05:49, 13 June 2016 (UTC)
Support Seems equivalent to dct:temporal (temporal coverage), so add this as one of the names, and as "equivalent property". This is better than "subject" because it doesn't require to have all possible intervals as items, and because it allows temporal computations (eg give me all Creative Works that cover a given time interval. --Vladimir Alexiev (talk) 19:21, 7 June 2016 (UTC)
Support Valuable for posthumous portraits that have an inscribed date which is not the date the painting was created. - PKM (talk) 00:57, 10 June 2016 (UTC)
This was originally suggested by ArthurPSmith in the proposal for day of week (P2894) with which it is complementary. It is intended as a generic property and so the uses above are illustrative rather than exhaustive. The allowed values could be constrained to just instances or subclasses of month (Q5151) (or a different single item) if the months of various calendar systems were all instances or subclasses of that item - a few are but there appears to have been no systematic structuring of this data (most just use calendar date (Q205892) which is too broad for a meaningful constraint to this proposed property) Thryduulf (talk: local | en.wp | en.wikt) 13:49, 8 June 2016 (UTC)
J'avais pensé à ça, mais in fine par exemple ça ne pouvait pas donner la couleur du maillot, sachant que cette donnée pouvait aussi varier au fil des éditions. Sous-jacent il y avait aussi le problème de l'ordre de ces maillots, sachant que différents contributeurs remplissent les vainqueurs, et qu'il n'y a pas d'ordre précis. La solution la plus simple consistait à utiliser un système proche de fr:Modèle:Maillot. Les premiers essais, avec une propriété de subsititution sont plutôt bon puisque Molarus a réussi à définir une couleur de fond par la même occasion. Jérémy-Günther-Heinz Jähnick (talk) 09:43, 13 June 2016 (UTC)
Support I've been waiting for this property to all the jerseys. It will be very helpful to stage and general classification.
I don't think we should add qualifiers for "standard rate phone numbers" ;). To avoid that someone actually tries to dial it, use a US one with 555. --- Jura14:45, 17 May 2016 (UTC)
I would definitely say fax number should be a separate property, regardless. Faxes and voice calls are different things and I can't see any benefit to combining them into a single property. I generally support subproperties over qualifiers if the number of variations is quite low (which seems to be the case here) because qualifiers are often quite broad in meaning and get used very inconsistently (there's already three different suggestions here... and I'd like to add fee (P2555) novalue as another option for free numbers :P) and properties are generally easier to add and easier to query for than qualifiers. - Nikki (talk) 11:04, 19 May 2016 (UTC)
The current system is that Template:Listing (Q14330485) has separate fields for fax or freephone/tollfree numbers and the template generates the vCard (actually an hCard) in whatever format - without forcing us to change fax=+xxxx to be phone=+xxxx/and, by the way, this is a telecopier. K7L (talk) 15:52, 20 May 2016 (UTC)
I am going back and forth between having this as a separate property and having this as the more generic "phone number". My head says "phone number" and my gut says "fax". This is mostly due to the difference in output: data using a faxline is going to end up being printed rather than heard (except in that lovely set of tones signifying a call :D), which may make it more desirable to have it elsewhere than a 'generic' phone property. I will tentatively Support this property. --Izno (talk) 14:43, 10 June 2016 (UTC)
Yeah, which went me to go from a qualifier solution to a separate property. Given the extensive support, I think this is ready for creation. --- Jura08:07, 11 June 2016 (UTC)
Support, phone = talk to someone, fax = machines talking to each other. (Also, specialized properties top qualifiers, in my opinion.) --Srittau (talk) 00:14, 12 June 2016 (UTC)
), but this is a key property of naval lights, used in lighthouse templates in several languages. There are further light properties to be proposed, such as range and intensity of the lighthouse light, see WikiProject Lighthouses. /Susannaanas (talk) 15:42, 13 June 2016 (UTC)
Useful mostly for Wikiquote. Often a single work has multiple editions or translations, and currently there is no way to bind them together. NMaia (talk) 11:56, 5 June 2016 (UTC)
Discussion
Comment I have a vague recollection of a discussion along similar lines to this that proposed having an item about the work and then separate items for different editions and translations, all linking to the item of the work with an "edition of" or "translation of" property. Would that not work better than peer to peer linking? Thryduulf (talk: local | en.wp | en.wikt) 13:47, 5 June 2016 (UTC)
Support Seems equivalent to dct:temporal (temporal coverage), so add this as one of the names, and as "equivalent property". This is better than "subject" because it doesn't require to have all possible intervals as items, and because it allows temporal computations (eg give me all Creative Works that cover a given time interval. --Vladimir Alexiev (talk) 19:21, 7 June 2016 (UTC)
Support Valuable for posthumous portraits that have an inscribed date which is not the date the painting was created. - PKM (talk) 00:57, 10 June 2016 (UTC)
InterPro is a resource of protein families, domains and functional sites that provides functional analysis of protein sequences by classifying them into families and predicting the presence of domains and important sites. Having InterPro in WikiData would allow linking proteins together by family/function across and within species.
Gstupp (talk) 21:08, 12 June 2016 (UTC)
We need a way to determine the value of a timezone. For example in voy:en:Template:Quickbar (see voy:United States of America as an example) we don't need to display every single timezone but just a MIN and a MAX value. There the offset of a timezone is required.
There are a limited set of time zones. I therefore suggest that items are used. I don't know what is best for places spanning over several zones, but to be able to add several values (one for each zone) might be an option. --Averater (talk) 08:02, 6 June 2016 (UTC)
Depending on the use you are planning to make of it, "numeric value" may be sufficient. --- Jura08:05, 6 June 2016 (UTC)
@Averater: we already have items. They are instances of time zone named for a UTC offset (Q17272482) (And the proposed property should only be used on these items). The point is that for comparing two timezones we need to have something numeric. The question to answer is which timezone among two has the biggest/smallest offset. @Jura1: I would prefer "quantity" because it's more meaningful even though "numeric value" would be enough for the Wikivoyage use case. -- T.seppelt (talk) 09:41, 6 June 2016 (UTC)
Every named timezone item can (and should) be linked to it's numerical offset using located in time zone (P421). This proposed property will be used on all numerical offset items, regardless of whether they're summer time, standard time or both. I'm not other items you are referring to. Thryduulf (talk: local | en.wp | en.wikt) 11:15, 6 June 2016 (UTC)
Support. Admitting only basic familiarity with Wikidata, it seems natural to include UTC offsets as numeric values rather than solely as text. LtPowers (talk) 12:45, 6 June 2016 (UTC)
Thanks @Izno:! But I think since "river" is a word, "type" is better than "type ID". Also their vocab is called "place-types" not "place-type-IDs"
Sorry for the confusion re asking to delete this page, the magic of how the parent page is composed of its headings is new to me. Vladimir Alexiev (talk) 20:15, 7 June 2016 (UTC)
No worries regarding the magic. It will not take long to get used to and will probably help make it easier to focus on one proposal at a time. (And will show up nicer in recent changes and watchlist.)
The reason I think it should be "place type ID" is that this will be used to link their vocabulary with ours in some way, not to populate our own ontology, and the name, without the phrase "ID", makes it look like our type is following theirs or theirs ours or something. And if it is the latter, then I'm not sure I support the property... --Izno (talk) 20:17, 7 June 2016 (UTC)
I don't think that's sufficient. I would rather it be clearly obvious that the claim is being used as an ID by calling it one. --Izno (talk) 22:41, 7 June 2016 (UTC)
An excellent and famous ancient place gazetteer. Describes 35k places. Includes RDF export, alignments to Geonames and TGN.
I can't believe we don't have it yet.
Vladimir Alexiev (talk) 18:13, 7 June 2016 (UTC)
Discussion
Definitely this property and probably the one above should be an external-id datatype rather than string, but other than that they look good to me. Thryduulf (talk: local | en.wp | en.wikt) 18:23, 7 June 2016 (UTC)
The Mapping the Practice and Profession of Sculpture in Britain and Ireland site, for short the Mapping Sculpture database, is a scholarly project on sculpture 1851 to 1951.[4]. There are over 6K person identifiers.
"The University of Glasgow, in partnership with the Victoria & Albert Museum and Henry Moore Institute, launched the project in September 2007."[5] This is a major resource for British art. Charles Matthews (talk) 12:53, 9 June 2016 (UTC)
ECARTICO is a comprehensive collection of structured biographical data concerning painters, engravers, printers, book sellers, gold- and silversmiths and others involved in the ‘cultural industries’ of the Dutch and Flemish Golden Ages.
This is very valuable and useful collection of structured biographical data, supported by University of Amsterdam and free licensed under CC-BY-SA. Currently the database contains 24 912 peoples — "Painters: 7 671, Engravers: 1 292, Booksellers, printers and publishers: 865, Gold- and silversmiths: 1 953, Sculptors: 209", — and this is "gold pages" (in my opinion). --Kaganer (talk) 17:40, 9 June 2016 (UTC)
Aside from its value as external identifier, this useful and structured database (around 3500 items) usually offers, address, images, pics, architect(s), bibliographical references and a short description about each item. It may as well prove to be useful in coordinating local Commons contests. A template for this identifier already exists in es:wiki (see: es:Plantilla:COAM), with 227 items (see: es:Categoría:Artículos con plantilla COAM), already tagged and prepared for migration to wikidata.--Asqueladd (talk) 18:27, 9 June 2016 (UTC)
Discussion
Support. The Official Architects' Association of Madrid has a deep background in heritage protection and in the creation of building and structure catalogues in Madrid. As Asqueladd mentions, the records in their catalogue shows valuable and comprehensive information about the items and are, in themselves, reliable sources. Therefore, I cannot but support and encourage the adoption of this property. --Discasto (talk) 21:42, 9 June 2016 (UTC)
thousands of items related to different topics (there are some more than 12 thousand live articles to date, and, according to the publisher, there will be available up to 45 thousand by the end of this year)
The Great Russian Encyclopedia is one of the most trusted Russian-language reference sources. The official website was opened to the public just two months ago, but the whole project is funded by the Russian government, so it's not expected to close in the near future. INS Pirat (t | c) 06:02, 4 June 2016 (UTC)
Possibly Mix'n'Match. Also, some author profiles have other identifiers we could match, like ORCID iD (P496) and arXiv-ID (property missing).
Motivation
INSPIRE-HEP (Q5972440) is a major database for high energy physics, that includes author profiles identified by a BAI (Bib Author Identifier).
For most scientists working within the HEP field, the profile is connected to a HEPNames record that contain name variants and their professional history. But there are also author profiles not connected to HEPNames (example), that are not as well curated. So we should probably recommend linking mainly to HepNames-connected records. Danmichaelo (talk) 20:38, 14 June 2016 (UTC)
Import by de:Vorlage:CPR gives the wrong values, dewiki makes use of the possibility to reach the individual pages by Integrated Authority File (Q36578). A mix'n'match entry will be created by me after the property is active (or perhaps even before).
Motivation
Interesting and reliable information on the careers at Rostock University. Used quite a bit by dewiki. Seems a good addition to wikidata. Lymantria (talk) 16:25, 20 June 2016 (UTC)
A series going back to the 17th century of biographies of Fellows of the Royal College of Physicians, and some others; started by William Munk and continued by librarians of the College; "biographical resource for those interested in medical and social history".[7] Currently 6.9K persons, and the site is updated. Charles Matthews (talk) 15:08, 21 June 2016 (UTC)
ID for the individuals and business entities listed in the British Book Trade Index database that is hosted by the University of Oxford's Bodleian Libraries
To be used as qualifier on address-like properties. I stumbled across this in the example above while looking for remaining uses of comment (DEPRECATED) (P2315). It seems useful that we can specify a PO box when specifying addresses. --Srittau (talk) 17:28, 5 May 2016 (UTC)
Discussion
First, thanks for testing this out as a separate page, I think it works well! Second - I guess this is a necessary complement to P969 (P969)? Or would it be better to have a general mailing address property (which would include PO Box)? ArthurPSmith (talk) 15:54, 6 May 2016 (UTC)
Yes, I would think that this would go with P969 (P969). On my example above, the PO box was attached to headquarters location (P159), which makes a bit of sense, but not really. And then there is also located on street (P669), which works like P969 (P969), but for street items. I think all of this is a bit of a mess, at the moment. We should maybe rethink how we are doing addresses, but I guess we would need a more public place for that than this proposal. --Srittau (talk) 20:09, 6 May 2016 (UTC)
The Watsonian (British Isles, except Ireland) or Praeger (Ireland) Vice-county in which the place is located, for the purposes of biological recording.
I also support an incarnation that would have wider use than the UK only - maybe a general one about sub-county-level organization? I'm honestly not sure how it would be organized in other countries. Ajraddatz (talk) 20:03, 31 May 2016 (UTC)
Support. This is significant information for biological recording that cannot be recorded on Wikidata using existing properties. There is no deadline, and no required stated anywhere that properties have to be immediately widely used. Thryduulf (talk: local | en.wp | en.wikt) 23:35, 30 May 2016 (UTC)
Vice-county, ceremonial county and administrative county of Derbyshire For reference, the image right is an an example showing how the vice-county of Derbyshire differs from the modern ceremonial and administrative counties of the same name. Thryduulf (talk: local | en.wp | en.wikt) 00:02, 1 June 2016 (UTC)
I would Support a more wider approach than one that only can be used in the UK. Until this proposal becomes more generic I Oppose. If the target-article is a vice-county or not can be seen in the P31:Q7925010-statement in that item. -- Innocent bystander (talk) 07:35, 31 May 2016 (UTC)
Close as out-of-process and instead recreate undelete Property:P1887. The latter was created by consensus, and was deleted without consensus, as Ajraddatz himself has acknowledged. "as per Wikidata:Administrators' noticeboard#P1887" is a bogus justification, as the AN discussion, which Ajraddatz himself closed, was ongoing and itself had no consensus for this action. [I also note that P1887 does not apply to organisations] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits10:47, 31 May 2016 (UTC)
A discussion that lasted over a month on AN failed to produce any real results. I think it's time we focus on the actual merits of having this property, rather than whatever bureaucratic nonsense you want to go through with. I assume you support re-creating the property? Ajraddatz (talk) 20:32, 31 May 2016 (UTC)
We have already had three discussions focused on the actual merits of having this property. The first found consensus to create the property; the second (the first PfD, last December) failed to find any consensus to delete it, with not a single supporter; as did - by your own admission - the next. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:37, 31 May 2016 (UTC)
Andy, can you explain why it matters whether the old property is recreated or a new one is created? What difference does it make? I've been reading your fight on this for a while and I just don't get why you are so worked up about it. As you and others have said - there is no deadline, so if the property is unavailable for some time (or some other way of handling it is eventually arrived at) what harm is done? I just don't see why this justifies getting a handful of admins (and more by the day, it seems) upset with you. ArthurPSmith (talk) 21:08, 31 May 2016 (UTC)
I can't speak for Andy, but stability matters on a project like this. If properties with three consensuses for existence are deleted and recreated (after months of protest and a fourth consensus) as a separate property, what stability is there for reusers of our data? If the original property is recreated then any external tools etc can just be reactivated rather than needing to be rewritten. As for getting people pissed off, this is an unfortunate but I consider that the benefits to the project from ensuring that consensus is respected far outweighs the downsides of people getting pissed off at me. Thryduulf (talk: local | en.wp | en.wikt) 22:53, 31 May 2016 (UTC)
If the property was widely used, then that would be a fair point. But it wasn't. Maybe let's focus on its actual merits instead? Ajraddatz (talk) 23:21, 31 May 2016 (UTC)
Why does it mater how widely used the property was? Do you know whether someone was collating the data to use it or was preparing a larger project that made use of this? The property was created with consensus that it was beneficial to Wikidata to have a property to store this data, for reasons given in just about every discussion about it, and it was ready to be used at any time (rather preferable to telling an enthusiastic new contributor to wait between a week and a year for their property proposal to be decided upon). In unrelated discussions about property use, nobody has ever been able to explain to me (despite repeatedly asking) why lightly used properties are a problem? The only answers given related to vandalism, misuse and constraint violations, but the volume of and propensity for these are all entirely independent of how many uses a property has (indeed a more used property is more likely to attract vandalism and constraint violations are far easier to sort among a few uses than among many uses). Thryduulf (talk: local | en.wp | en.wikt) 23:41, 31 May 2016 (UTC)
As I pointed out to you above, and more recently elsewhere: "We have already had three discussions focused on the actual merits of having this property. The first found consensus to create the property; the second (the first PfD, last December) failed to find any consensus to delete it, with not a single supporter; as did - by your own admission - the next.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:36, 1 June 2016 (UTC)
Technically, it doesn't matter "whether the old property is recreated or a new one is created", because if the latter action is taken, it will have to be merged into P1887 anyway. What matters is that we don't have admins deleting properties with no consensus; that we don't have admins closing discussions while they are in progress (and despite objections from their recent participants); that we don't allow multiple, disruptive deletion nominations; that we don't invent procedure on-the-fly to cover up the failure of admins to act on reasonable requests to oversee the actions of other admins, and that we don't waste the time of volunteers with redundant, duplicate proposals for properties that have already found consensus for their creation, and no consensus for their deletion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:34, 1 June 2016 (UTC)
Question @Innocent bystander, Ajraddatz: why do you think something broader is required? To my knowledge the concept of a vice-county is unique to Great Britain, Ireland, the Channel Islands and Isle of Man and this method of recording data for areas that are not used in other contexts (e.g. current or former administrative territorial entities, cultural regions, statistical areas, etc) is not used elsewhere. Certainly the Wikipedia article and other references I've read give no hint that there is an equivalent elsewhere.Thryduulf (talk: local | en.wp | en.wikt) 00:02, 1 June 2016 (UTC)
@Thryduulf: The fact that Staffordshire (Q17581852) is a vice-county is already stated in that item. location (P276):Staffordshire (Q17581852) then can fulfil exactly the same purpose and you will get the same information. BUT, to state that a nature reserve, a rare flower or a bird can be found in one specific area with maybe very specific living circumstances actually looks like a good idea. We maybe do not have exactly the same kind of entity in the rest of the world, but to state that something can be found in the limestone-islands of the Baltic Sea or the erosion zones of Ångermanälven still looks very useful. -- Innocent bystander (talk) 05:27, 1 June 2016 (UTC)
If we're thinking in a comparative sense, many countries have a sub-county administrative zone that is still above the municipal level. In Canada, these are called township zones, which they apparently are in China as well. I just wonder if this property could be modified to fit all sub-county-but-not-municipal administrative zones, something which could make it more usable and remove that concern as well (though I do agree that widespread use shouldn't be mandatory for a property to be made). Or if it is even needed at all, or even if it could be used as a qualifier within the location property; i.e. location --> whatever, with the qualifier of sub-county admin area --> thing. Though this probably duplicates data that can already be figured out by going from the bottom up, i.e. listing the lowest level and then extrapolating the other administrative districts that it is in. Ajraddatz (talk) 07:31, 1 June 2016 (UTC)
@Ajraddatz: I do not like pretending like this hierarchy exists in reality. They maybe do so in Canada or China, but here in Sweden there is a chaos of different types of overlapping administrative territorial entities and they follow no hierarchy at all. A Swedish district do not have to follow the same borders as a municipality, neither a parish or a civil parish do. That something here is located in a district, does often not gives you information in which municipality you live. One family in Boteå district lives in Kramfors municipality, while the rest (I think) lives in Sollefteå municipality. "Located in" "Boteå district" then does not give you enough information to tell where they get their municipal service or where they pay municipal tax. -- Innocent bystander (talk) 10:05, 1 June 2016 (UTC)
Yeah, vice-counties are not part of any hierarchy of administrative areas. For most you can infer which country they are in, but at least one is party in the UK and party in the Republic of Ireland (they pre-date even Irish Free State (Q31747)) and it is not unlikely that some span the England-Wales border (England-Scotland border is less likely but still possible, e.g. around Berwick-upon-Tweed (Q504678)). It would be possible to add statements noting a location's vice-county but this would require (a) statements on every location in the British Isles and (b) a property to record the location's vice-county, so I don't recommend that approach. I suppose the vice-county could be added as a second location (P276) statement but that is going to be less clear, possibly harder to query (I'm not sure) and likely to see the entries removed by well-meaning users who don't know what a vice-county is. Thryduulf (talk: local | en.wp | en.wikt) 10:54, 1 June 2016 (UTC)
I understand that vice-counties are not used for administrative purposes, but they still represent an organizational unit above the municipal and below the county. So even if there is no explicit administration based on the vice-county that a city / town / etc is in, it should be possible to figure out by the software by listing the lowest possible administrative division. So you take something like Anglian Tower (Q4763423), list the lowest possible administrative division (York (Q42462)), and then by extension the software can figure out that it is part of whatever vice-county it is a part of - 10 minutes of Googling and I can't figure that out. Basically, it isn't an administrative division, but it could be figured out as one in the software. Would it also be possible to add as a second location (P276) statement, with a qualifier that it is a vice-county? Though I suppose there wouldn't be much different between that and creating this property. Ajraddatz (talk) 20:18, 1 June 2016 (UTC)
No, they don't represent any organisational unit at all, and it is not conceptually possible to say that they are "above the municipal and below the county" as they exist as entirely independent concepts that have exactly no relation to each other (it's as nonsensical as saying that area control center (Q854272) regions are "above the state and below the country" - they exit independently for different, unrelated purposes). Most are larger than municipal but this cannot be guaranteed, some are larger than counties, others are smaller than counties, some are about the same size but with different borders - at least one is in two different countries. Also, the borders of vice-counties do not change - a given point in the Vice County of e.g. Derbyshire will always be in that vice-county but which administrative and ceremonial county/counties it is in can change at any time - see the image above. location (P276) has been brought up several times, including in the first property proposal - see for example the comment of mine immediately preceeding yours for a couple of reasons why it would be inferior to a dedicated property. Thryduulf (talk: local | en.wp | en.wikt) 23:07, 1 June 2016 (UTC)
My own understanding of this was based on Google searches, so thanks for explaining this better to me. Looking at a map, it seemed like the boundaries for the vice-counties intersected with those of counties, but if they are completely different then perhaps this property does make sense. Though, they still represent organizational units by definition - it's just an issue of them not being comparable with the administrative districts. My only other concern is the use for this - it was proposed as a necessary part of bio recording, but went largely unused. Is this actually an important area? Are these vice-counties widely used for that purpose? And is enough data involving them available to promote future use? Ajraddatz (talk) 18:21, 3 June 2016 (UTC)
The boundaries of vice-counties are generally similar to ceremonial counties with the same name but they are not identical and some are very different (e.g. Oxfordshire (Q17581832)), there are vice-counties without direct equivalent (e.g. Mid-west Yorkshire (Q17582085)) and others that sound more similar than they are (e.g. West Kent (Q17581823) does cover the western part of present day Kent (Q21694674) but also most of south-east London, at least as far west as Greenwich (Q179385)). Further, the boundaries of ceremonial and administrative counties can and do change, but vice-counties are static by design. As for data availability - there is 160+ years of biological recording and other data that uses the vice-county system, including contemporary recording with tools available to convert grid references and GPS points to vice-county location. As there are many independent organisations using vice-counties the format and license of that data will vary though, but much will be in the public domain by now. There is plenty of potential use, but I cannot promise how quickly that will occur - but as I've still never seen any valid reason why low use of properties is actually a problem (I've seen a couple of attempts, but none that actually stood up to scrutiny - they are no more or less likely to be subject to random vandalism and probably less likely to suffer targeted vandalism; constraint violations are less likely to happen with low-use properties and easier to resolve when they do). Thryduulf (talk: local | en.wp | en.wikt) 19:54, 3 June 2016 (UTC)
Thanks Thryduulf, that makes sense. I've changed my vote to support. I appreciate your time spent walking me through it; perhaps some more information could be included on the talk page or something to make this more clear next time. Ajraddatz (talk) 22:13, 3 June 2016 (UTC)
This is not an external id property for which we do have some very localized properties; it is intended as a property indicating the location of an item within another item. That seems a very generic thing to me. If location (P276) is deemed unsuitable or ambiguous as Thryduulf suggests above, how about creating a new property such as "located within" or "located within the nonadministrative territorial entity" to distinguish it from the administrative version? Another option perhaps is the simple part of (P361)ArthurPSmith (talk) 14:16, 2 June 2016 (UTC)
Why is there so much scrabbling around trying to find a broader property - are there any usecases that we are missing? part of (P361) isn't a good fit as e.g. Sandwell Valley RSPB reserve (Q7417062) is no more part of a vice-county than it is part of an administrative county (perhaps even less so). "Located in non-administrative territorial entity" is less problematic on the surface, but what would be the domain and allowed values other than vice-counties? Everything else I can come up that could possibly fit is either not a territorial entity (e.g. flight information region (Q1433404)) or part of some other administrative structure (e.g. police area (Q7209560)). Thryduulf (talk: local | en.wp | en.wikt) 17:10, 2 June 2016 (UTC)
because wikidata, structurally, is benefited by having fewer more general item-valued properties if they are sufficient to capture the information in question. The generic nature of instance of (P31), subclass of (P279) and part of (P361) in particular allow some powerful querying to be done that wouldn't be nearly as easy if there were a collection of disparate properties representing the same kinds of relationships across different domains. String-valued (or external-id valued) and numeric-valued properties are a different matter, as the meaning of the values is very much tied into the specific property. But the power of wikidata is that items (Q-identifiers) are in themselves already highly specific - they don't need further interpretation, in general. We know Staffordshire (Q17581852) is a vice county because it is specified that way, and differs from Staffordshire (Q21694786) and all the other Staffordshire's. We don't need to have the property telling us that the value is a vice county, the item already tells us that. So what is it that this proposed property would be telling us? If it's covered by an already existing property, we really should use that. If we do need a new property, we certainly don't need it to be specific to vice counties. And I would have thought "territorial entity" includes anything that specifies a geographic region in some way, so flight information region (Q1433404) for example ought to count (though the region specified is above the ground). ArthurPSmith (talk) 14:16, 3 June 2016 (UTC)
Support The explanations given make sense to me. I don't think any other property suggested is really suited to model this very specific and arcane (but seemingly important) aspect unambiguously. For the same reason I don't think we need a broader property. --Srittau (talk) 21:34, 11 June 2016 (UTC)
Oppose unless we see a list of 15 sample uses before creation. This as it had been created, but wasn't actually used for quite some time (despite us being told that some other property had been used instead in its previous creation discussion). --- Jura09:20, 13 June 2016 (UTC)
Not a requirement for a proposed property, but to indulge you:
Support, but I think "percent of area water" or "water as percent of area" would be better English labels. "Percent of water surface" suggests that "of the area that is water, this percent is <x>" rather than the intended "of the surface area of <x>, this percent is water". Thryduulf (talk: local | en.wp | en.wikt) 22:39, 23 May 2016 (UTC)
Comment I wonder if this should be a qualifier to "area". Countries may have different views on what parts of the sea are included. --- Jura07:25, 27 May 2016 (UTC)
The Encyclopedia of Triangle Centers is a comprehensive encyclopedia giving a lot of useful information on triangle centers. Used as a source in several wikipedia's. Lymantria (talk) 08:20, 23 April 2016 (UTC)
Discussion
Oh my goodness, I had no idea there were so many different "triangle centers"! I Support this proposal - however, I don't think "Kimberling number" is a standard name, and what you're proposing for the value is not a number anyway (i.e. has an X and parentheses). Maybe "Kimberling center identifier"? ArthurPSmith (talk) 18:12, 18 May 2016 (UTC)
You are right about the naming as "number" being less apporpriate (I was hinted by the French and Dutch wikipedia articles linked to by Encyclopedia of Triangle Centers (Q1340177)). I changed the name (added aliases). In publications in stead of parentheses often the number is proposed as subscript. I follow the way it is presented in ETC itself.Lymantria (talk) 21:05, 21 May 2016 (UTC)
Needed to claim what software supports certain peripherals such as VR headsets (these are not always platforms). Danrok (talk) 14:03, 25 March 2018 (UTC)
Question How do this property work with other devices. Force Feedback controls, Joystick, Wheels, iFeel Mice, Novint Falcon, flight sticks, and motion control platforms. Rumble motors. Light up keyboards, mice, and headphones. What about arcade games like Dance Dance Revolution with the lighting controls? What aspect of the Dreamcast's VMU or the Wii U's GamePad does this cover? Motion Tennis output to the Apple TV from the iPhone[8]. How about all apps with Chromecast support? Dispenser (talk) 14:46, 25 March 2018 (UTC)
I'd suggest that you would use either input device (P479) or this proposed property based on the primary function of the device, i.e. a haptic control pad is primarily an input device, whereas a printer is primarily an output device (even though most now have displays) Danrok (talk) 15:04, 25 March 2018 (UTC)
I'm not totally sure this is really the best possible property to do this but I failed to come up with anything better, so maybe my feeling is wrong. Therefore Support as long no one has a better idea. -- MichaelSchoenitzer (talk) 15:39, 25 March 2018 (UTC)
@TomT0m: Some games (and software) specifically support VR headsets and their respective controllers, and some may not be playable without. This is because the user interface is designed to work with VR hardware instead of the usual keyboard/mouse. Some software is designed and coded from scratch for use with VR only, e.g. Rec Room. Other "standard" games have had VR support added on, e.g. Elite Dangerous. Some games have a specific VR release version, e.g. Fallout 4 VRDanrok (talk) 20:55, 25 March 2018 (UTC)
Comment Something like this does seem to be needed. However, given the above comments what about a more general "supported device" (and possibly "required device") property? ArthurPSmith (talk) 14:25, 26 March 2018 (UTC)
Do "supported device" and "required device" already exist? My problem with "output method" is that the VR controllers are _input_ devices. SharkD Talk 19:30, 2 April 2018 (UTC)
Oppose What's the problem with "has part" A qualifier quantity (P1114) N? That seems like it's exactly the use case in question. --Izno (talk) 17:09, 2 June 2016 (UTC)
. has part(s) (P527) is for the actual parts if we have items for them. author TomT0m / talk page 19:18, 2 June 2016 (UTC)
Comment I don't understand the problem with has part(s) (P527). For example, it could be used this way: . Lymantria (talk) 07:43, 3 June 2016 (UTC)
WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Izno (talk) 11:53, 3 June 2016 (UTC)
Support - this seems like a useful property to have. Should there maybe be a "month of the year" property also - for example Thanksgiving (Q13959) -> November (Q125) (qualifier = US)? Anyway I definitely support this one. ArthurPSmith (talk) 18:02, 27 May 2016 (UTC)
Done now day of week (P2894) --Lymantria (talk) 05:31, 8 June 2016 (UTC)
Weak oppose without an example, but if I've understood this properly I think using operator (P137) and/or owned by (P127) on the item about the extraction site (which should have coordinates) would be a better way of doing this. Large corporations like BP (Q152057) would have massively long lists for this property, and it would make it harder to track changes in ownership that way too. Thryduulf (talk: local | en.wp | en.wikt) 10:31, 8 May 2016 (UTC)
Not done, no support. --Srittau (talk) 21:22, 11 June 2016 (UTC)
Comment @ArthurPSmith: What do you think of this property and the ones I proposed below? Your feedback would be appreciated. Thanks Mcnabber091 (talk) 06:10, 18 December 2015 (UTC)
Question @Mcnabber091: This is supposed to be a USA only property? Lymantria (talk) 06:27, 7 May 2016 (UTC)
On hold To be re-opened when the right datatype is available.--Micru (talk) 13:57, 23 May 2014 (UTC)
Support Only allowed unit should be byte (Q8799). --Srittau (talk) 20:49, 16 May 2016 (UTC)
Question @MisterSanderson: Why only L2 cache (and not L1)? Lymantria (talk) 05:23, 25 May 2016 (UTC)
thank you for →official name (P1448) didn't find this property. --Plagiat (talk) 04:45, 13 June 2016 (UTC)
Done --Fralambert (talk) 00:50, 16 June 2016 (UTC)
Weak support P794 (P794) would do, but I prefer a specialized property. --Srittau (talk) 15:21, 17 May 2016 (UTC)
Not done Unsufficient support. Lymantria (talk) 10:16, 12 June 2016 (UTC)
⟩ has part(s) (P527) 
.jpg&action=edit&redlink=1){kind=link}
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.