Wikidata:Property proposal/Archive/51

 This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

This archive page is full. Use Wikidata:Property proposal/Archive/52 or subsequent ones.

The previous archive page is Wikidata:Property proposal/Archive/50.

Description Code identifying a pollen or spore listed in the Australasian Pollen and Spore Atlas managed by the Australian National University String No existing property is known to exist, however a link to the atlas entry could be included somehow within en:template:taxobox pollen (Q79932) and spore (Q177332) string pattern: \d+(\-\d+)*($$\d+(\-\d+)*$$)? Parietaria judaica (Q147991) → 62-14-3 Australasian Pollen and Spore Atlas http://apsa.anu.edu.au/sample/$1 Codes could be scraped from the Australasian Pollen and Spore Atlas and mix-and-match used for import into Wikidata Motivation The Australasian Pollen and Spore Atlas website is designed to enable simple online access to the largest collection of pollen and spores information in the Australasian region. The APSA collection and office is currently located at the Australian National University in Canberra, Australia. This database contains numerous fields of information on pollens and spores for flora both endemic and common to Australia. Database fields include description of the pollen and spore shapes, their arrangement and patterns. Addition of this property would signifanctly enhance Wikidata's understanding of pollens and spores, particularly those endemic within Australia (Q408). Dhx1 (talk) 11:56, 22 November 2015 (UTC) Discussion Comment Not sure. A quick browse does not turn up real content? I would rather have something like FloraBase. - Brya (talk) 13:54, 22 November 2015 (UTC) Comment The unique content is demonstrated better for Acanthus ebracteatus ACANTHACEAE, Pseudowintera traversii WINTERACEAE, Dicliptera brachiata ACANTHACEAE and Bouganvillaea spectabilis NYCTAGINACEAE. I am unaware of this level of detail being provided by other organisations, including FloraBase. A quick survey of samples in this database shows that most entries have useful detail (morphology, images, etc) - Dhx1 (talk) 16:04, 22 November 2015 (UTC) Comment OK, that is better, although I seem to recall having seen more extensive sites covering pollen. - Brya (talk) 05:49, 23 November 2015 (UTC) Support looks useful to me. --99of9 (talk) 02:44, 4 May 2016 (UTC) @Dhx1: Done with datatype external identifier. I have taken your regex (with a minor correction), which has single values per species. In some cases there are multiple pages however (with codes ending in a, b, c). Lymantria (talk) 20:29, 4 May 2016 (UTC) ADB Not done Description entry in ADB on the subject Allgemeine Deutsche Biographie (Q590208) Item Template:Cite ADB (Q6676526) any item for Wikisource page Kaspar von Schoch (Q1048100) → Schoch, Kaspar von (ADB) (Q19679712) Integrates ADB into Wikidata. --- Jura 06:48, 26 July 2015 (UTC) Discussion Not done No support. Lymantria (talk) 17:35, 9 May 2016 (UTC) price range (WikiVoyage) Withdrawn Description price range for eat/sleep listings. Use price (P2284) or fee (P2555) for specific prices Item price in voy:Wikivoyage:Listings items for WikiVoyage price ranges, see voy:Template:Eatpricerange and voy:Template:Sleeppricerange Hotel ABCDEF > budget • Comment seems to be needed for WikiVoyage --- Jura 18:36, 13 May 2016 (UTC) • Oppose We already have fee (P2555) which would seem suitable. If a range needs to be expressed this can be done with qualifiers (e.g. determination method (P459) minimum (Q10585806)) or using the mid point with ± (e.g. 7.5±2.5 pound sterling (Q25224)), although note that until phab:T95425 (and related bugs?) is fixed this may be displayed incorrectly. Thryduulf (talk: local | en.wp | en.wikt) • I updated the proposal to clarify the function of this property. It's different from the actual prices. BTW, for these price (P2284) seems to be the main property. --- Jura 10:16, 14 May 2016 (UTC) • Oppose You haven't merely "updated" the proposal, you've changed it to something entirely different which actually makes no sense. We don't use words like "budget" "midrange" "splurge" in the individual listings, we use numeric prices or price ranges. The 'budget' label is a subsection header only, it isn't template data. K7L (talk) 18:47, 15 May 2016 (UTC) • Comment. This prices ranges seem to be used in to different ways: once for a summary per location (what means "budget" in this location?) and then for each listing (is this place to eat/sleep "budget"?). The later would use this property. Not sure where to store the first. --- Jura 10:16, 14 May 2016 (UTC) • Comment. The "budget", "midrange" and "splurge" qualifiers are Wikivoyage city article ===subsection headers===, but are not used as data values for the price= field in individual listings. They're not template data. An individual listing might have "€100/room, €150/suite,$25/campsite with caravan hookups" but vague text like "reasonably priced" is *not* desired in WV listings. K7L (talk) 01:24, 15 May 2016 (UTC)
• Most listings seem to be grouped by these ranges. Is this specific to the English version or used everywhere? To do the sections based on Wikidata, one would need such a property.
--- Jura 09:43, 15 May 2016 (UTC)
• The arbitrary grouping by price is only used to break up long lists of restaurants and hotels into more manageable chunks of 7±2 listings each; it has no other significance. There are other ways to break these up - by type (eat: 'asian', 'western', 'pizza', 'european', sleep: 'hotel', 'motel', 'B&B', 'campground') or by neighbourhood ('downtown', 'west end', 'lakeshore', 'old town', 'suburban') being the most common. It's not specific to the English-language version. K7L (talk) 18:47, 15 May 2016 (UTC)
•   Comment. price (P2284) as specified on Property talk:P2284 has some very inflexible constraints, only one price instead of a range or list of values, currency forced to EUR or USD only. fee (P2555) is marginally better, but is still a single price (such as a bridge toll) as of a specific date. A "pricerange" is not a single "price". K7L (talk) 02:30, 15 May 2016 (UTC)
• If you think a string version is needed, please make a separate proposal.
--- Jura 09:43, 15 May 2016 (UTC)
• Done. K7L (talk) 18:47, 15 May 2016 (UTC)

Description identifier in the Index Hepaticarum, a nomenclatural database External identifier plants (hepatics) number Jungermannia lanceolata (Q21875939) -> 2690 http://www.ville-ge.ch/musinfo/bd/cjb/hepatic/detail.php?no_record=$1 Motivation Nomenclatural database, for hepatics (liverworts and hornworts), comparable to IPNI, at a smaller scale. Brya (talk) 18:43, 22 April 2016 (UTC) Discussion • Support - Makes sense. --Succu (talk) 09:21, 23 April 2016 (UTC) • Support --Tobias1984 (talk) 10:02, 23 April 2016 (UTC) @Brya, Succu, Tobias1984: Done --Lymantria (talk) 17:30, 29 April 2016 (UTC) Thank you! - Brya (talk) 17:36, 29 April 2016 (UTC) flower colour Done: flower color (P2827) (Talk and documentation) Description colour of flowers of a plant species, hybrid or cultivar Item flowering plants colours Jasminum officinale (Q515610) → white (Q23444) Motivation Of interest to gardeners, florists, botanists and others. We may need to create items for colour ranges or groups, as used by reliable sources (e.g. en.WP describes Hyacinthoides non-scripta (Q164013) as "violet–blue"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:18, 29 July 2015 (UTC) Postscript: Prior discussion is at Wikidata:Project chat#Adding property colour (for flowers), and I should have mentioned that I posted this at the request of User:Timboliu, posting as an IP on my talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:59, 30 July 2015 (UTC) Discussion I really like it that we are venturing more and more into covering traits now (after things like eye color (P1340) and mushroom cap shape (P784)), but I have not seen a strategic discussion as to whether it would be better to use more generic properties on more specific items or more specific properties on more generic items, though the issue keeps popping up (see also the volcano eruption discussion). With this in mind, I am not sure about the benefit of this proposed property over starting an item for "flower of Jasminum officinale" and using colour properties like color (P462) on it. --Daniel Mietchen (talk) 01:12, 30 July 2015 (UTC) Notified participants of WikiProject Taxonomy --Daniel Mietchen (talk) 01:15, 30 July 2015 (UTC) I think this may get complicated very quickly. For example, this means having to deal with "violet–blue", "violet and blue", and "violet or blue". I suggest first looking at existing databases (here is one, and another, but there should be lots of them). - Brya (talk) 04:54, 30 July 2015 (UTC) There is WikiProject Identification Keys, but I'm not sure if it actually goes somewhere. --- Jura 05:02, 30 July 2015 (UTC) Comment A flower consists of multiple parts. The proposal is refering to which one? Flora of North America says „violet-blue or rarely white or pink“. So we would need at least an additional qualifier. Characters (or traits) are not stable. They are depending from a certain taconomic viewpoint. I agree with Daniel. We need a more general discussion. Watson and Dallwitz are using 581 characters in their The families of flowering plants to describe flowering plants. GrassBase uses 1090 characters for species belonging to Poaceae (Q43238). We are far away from defining our own plant ontology. --Succu (talk) 08:37, 30 July 2015 (UTC) Perhaps we need properties for petal colour, sepal colour, etc? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:59, 30 July 2015 (UTC) @Pigsonthewing: I think not. Constructions like ⟨ Flower of whatever ⟩ has part (P527) ⟨ 107412) ⟩ color (P462) ⟨ blue ⟩ number of elements search ⟨ 4 ⟩ would be pretty nice in this case ... author talk page 09:27, 30 July 2015 (UTC) Oppose I guess there would be a discussion if the discussion for standard flower color representation, but it seems it's not that well defined, so I think here there would be absolutely no benefit to try to be specific for no precise reason. Even if the discussion of a specific color standard was at sake, this solution would work anyway with the item datatype for color, assuming there is an identifier property, an item for each color in the standard, with ⟨ color as defined by standard S ⟩ subclass of (P279) ⟨ color ⟩ ⟨ blue whatever ⟩ instance of (P31) ⟨ color as defined by standard S ⟩ , and ⟨ blue whatever ⟩ S standard identifier search ⟨ blueZZZZZ ⟩ , used as in my comment above: ⟨ Flower of whatever ⟩ has part (P527) color (P462) ⟨ blue whatever ⟩ number of elements search ⟨ 4 ⟩ – The preceding unsigned comment was added by TomT0m (talk • contribs). Comment I think before discussing this property, we should write up a RFC and let outsiders of this knowledge domain weigh in. I have been thinking about this a lot lately and see no clear path to follow. For example TomT0m's suggestion is nice, but it is hard to imagine that we can retrain a whole community to use constructs like that. There is also the problem of adding too much information in the qualifier-rows. Readability and editablity are concerns for Wikidata and we have to be pragmatic about that. - In my opinion the most manageable solution would be to create items for all subparts and dump all the metrics in there. There are some examples of that already on Wikipedia: Acer saccharum (Q214733) has part Canadian Gold Maple Leaf (Q119457). But that also means creating many items ("bee wing", "shark tooth", ..). --Tobias1984 (talk) 10:31, 30 July 2015 (UTC) • why not ? It's not that hard. And similar structure for the whole project greatly limit the amount of examples needed. I don't agree that this structure is hard to grab. author talk page 15:04, 30 July 2015 (UTC) • Comment List of mushrooms seems to work mainly with specific properties, open to non-specialists and non-template editors. Maybe a similar sub-field could be identified to build a similar set of properties. --- Jura 11:11, 30 July 2015 (UTC) and a subproject specific to a kind of mushrooms would have its own set of incompatible but similar properties ? Please don't take that path /o\ author talk page 09:15, 31 July 2015 (UTC) • I think it's a good path to follow collaboratively built samples that can be compatible. This way we are sure we don't just follow idle chat. --- Jura 09:25, 31 July 2015 (UTC) • @Jura1: So ... why chatting at all ? It's for that reason we have a property proposal process (plus I have a few stalled properties myself, easy to say I'm idle after that) but enough personal iddle chatting. On the list : in which way edibility is specific to mushrooms, to take an example in the list ? having specialized properties for no good reason could create the need for a merge later ... author talk page 13:03, 31 July 2015 (UTC) • Well, at some point one has to evaluate if all the talk of participants actually leads to some collaboration within the project or not. --- Jura 07:20, 1 August 2015 (UTC) • @Jura1: Let's be clear : should I consider this a personal attack ? You should be clear on what you consider a "contribution". There is many ways to contribute. Mine is not "maximising the editcount on the main namespace". author talk page 10:25, 1 August 2015 (UTC) @TomT0m: Specialized properties don't necessarily need to be merged. They can also be subclassed to more generic properties. - And I still think the structure is hard to grab. If we have many properties that each take one or a few simple statements it is easier to work with than totally generic properties that can hold 1000s of statements each with their own qualifier structure. How would a user read such a list without thinking he is reading a programming language? - But I could also be totally wrong about this assertion. In any case I still think an RfC would be a better idea than dispersing the discussion over so many property proposals. --Tobias1984 (talk) 20:39, 31 July 2015 (UTC) @Tobias1984: Yout RFC argument is also valid for discussion on similar properties spreads on a lot of property discussions. And the outcome of discussions in many specialised properties is likely to become inconsistent decisions. I also don't see an obvious way to subproperty "color of parts" like properties as the kind of part would not be specified by an item. A Rfc why not but ... This would not prevent property proposals anyway and I would not know what to ask. On the contrary the structure I propose can be used in a variety of usecase, and a few examples with the color of the flower of some plant and the color of the superhero costume pant should suggest it applies to anything ... Plus the fact that there will be property proposals for people who does not knows that is an opportunity to tell them that, and those who knows won't ever have to go through this and will just enter their statements smoothly. There is so many advantages for so less understanding problems ... author talk page 21:06, 31 July 2015 (UTC) @TomT0m: For example this RfC also proposed a really simple and generic way of handling images on Wikidata: Wikidata:Requests_for_comment/Image_properties:_many_properties_or_many_qualifiers. But even that rather simple scheme did not catch on and we still have all the specialized image properties as far as I know. So the topic might require an RfC that we need to make certain changes to the user interface that makes it easier for people to use generic properties. I might have time to draft something next week and I will ping you for your input. --Tobias1984 (talk) 21:28, 31 July 2015 (UTC) I'm not sure if Wikidata actually has the technology for this RFC nor if it's planned to develop it in the long term. --- Jura 07:20, 1 August 2015 (UTC) @Jura1: As a lot of your post, I don't understand what you mean. author talk page 10:25, 1 August 2015 (UTC) • Support I support the flower color proposal as a generic property. The values have to be added as needed. There are many standards, but most data sources use their own vocabulary, which needs to be matched. As to petal color, sepal color etc.: It may be desirable to add this, but it will not replace the unspecified flower color. For practical reasones, unspecific "flower color" is relatively highly used property in botany, without specifying the parts. Thus data available for flower color cannot be easily mapped to (often unavailable) data for the color of specific parts). --G.Hagedorn (talk) 11:47, 8 August 2015 (UTC) • Support as above. If different parts have different colours then use applies to part (P518) as a qualifier to identify the part associated with each colour. Joe Filceolaire (talk) 17:34, 8 August 2015 (UTC) @Filceolaire: Excuse me but such a model is prone to give me headeaches :) Flowers are parts of a plant. To tell the color of the flower, or the color of any other part, like leaves, we will use either part of (P361) qualified, or ... a property "color of the part", and when the part has several color, we will use applies to part (P518) ? OK, but we could also put statements like ⟨ plant ⟩ color (P462) ⟨ yellow ⟩ applies to search ⟨ flower ⟩ ... I really don't like this. We should try to stay consistent in the ontology and limit the number of ways to express the same thing. This means that we should try to adopt the most straightforward rule with as few exceptions as possible, and "in the case of part colors use has part qualified with colors except for the case of flowers where we use "flower color" and when the color has parts we put several "flower color" statements qualified with "applies to" seems to me where we cross a complexity line. author talk page 08:10, 10 August 2015 (UTC) • Support somehow the discussion got side-tracked. --- Jura 06:08, 15 August 2015 (UTC) • Oppose The property color (P462) already exists, and can be used together with applies to part (P518) without problem. I see no benefit to creating a new property for flowers. --Yair rand (talk) 06:46, 16 December 2015 (UTC) Yes we have, but how would you describe the colorparts of Union Jack (Q3173323) with a generic property and applies to part (P518)? --Succu (talk) 23:17, 25 December 2015 (UTC) • Comment I agree with using color (P462), about the rest I'm not sure. Regardless on whether we use it with qualifiers, or on a data item describing the flower part of that plant, things can get even more complicated than described above - I have two comments. First, consider e.g. butterflies. How do we describe the color of the upperside forewings of the male imago of a butterfly? Forewing is definitely "a part of the object", but in this case we have also other categories: gender male, developmental stage imago, and also upperside (which is perhaps also "a part of the object"). Second, sometimes it's not clear whether the property should apply to the whole object or its part. Is deciduous/evergreen the whole plant, or its foliage? Is phyllotaxis a property of the leaf, or the stem, or the whole plant? Prot D (talk) 09:47, 4 March 2016 (UTC) @Pigsonthewing, Daniel Mietchen, G.Hagedorn, Filceolaire, Jura1: Done as sub-property of color (P462). I see a slight consensus in favor of creating a sub-property, although it is not really clear-cut in this multi-year discussion. In the end I opted for creating this specialized property, since the color of a flower is a very important aspect for identification, but also for the general public. Much more so than the color of any other part of a plant. --Srittau (talk) 21:30, 8 May 2016 (UTC) 3DMet ID Done: 3DMet ID (P2796) (Talk and documentation) Description External identifier chemical compound B\d{5} ethanol (Q153) → B01253 http://www.3dmet.dna.affrc.go.jp/ http://www.3dmet.dna.affrc.go.jp/cgi/show_data.php?acc=$1 Yes
Discussion

--GZWDer (talk) 08:32, 6 October 2015 (UTC)

@GZWDer, Snipre, Pigsonthewing:   Done I noticed the proposer is not available (for a while?). The formatter URL suggested in the previous question is in accordance with the enwiki use, so I used it right away. Lymantria (talk) 12:39, 30 April 2016 (UTC)

@Lymantria: Thanks for the change of the url and the property creation. It is ok like that. Snipre (talk) 20:52, 30 April 2016 (UTC)

Molar volume

Done: molar volume (P2807) (Talk and documentation)
Description To be used as a qualifier with phase point (P873) to describe critical volume Quantity chemical compounds value with unit dimethyl carbonate (Q416254) → phase point (P873) with critical point (Q111059) and 251±51 cm³/mol scientific literature, e.g. CRC Handbook of Chemistry and Physics (95th edition) (Q20887890)
Motivation

(Add your motivation for this property here.) ∼Wostr (talk) 22:16, 14 April 2016 (UTC)

Discussion

@Wostr, Snipre:  Done Happy editing. Lymantria (talk) 18:28, 4 May 2016 (UTC)

wavelength

Done: wavelength (P2808) (Talk and documentation)
Description To be used as a qualifier with refractive index (P1109) Quantity chemical compounds value with unit dimethyl carbonate (Q416254) → refractive index (P1109) = 1,3687 with 589 nm scientific literature, e.g. CRC Handbook of Chemistry and Physics (95th edition) (Q20887890)
Motivation

(Add your motivation for this property here.) ∼Wostr (talk) 22:16, 14 April 2016 (UTC)

Discussion
•   Comment This needs a better description and should be applicable to other cases besides as a qualifier for refractive index - wavelength is a pretty generic physical property for light, sound, or any other mode of propagation. I could imagine wikidata items for specific spectral absorption lines for instance that it would be reasonable to provide a wavelength property for - though I can't find any examples right now... Anyway, I think the property should be recast as more generic, but otherwise I   Support creating it in principle. ArthurPSmith (talk) 12:52, 30 April 2016 (UTC)
Support I agree with User:ArthurPSmith that this will be used more broadly. For example hydrogen line (Q1406191) wavelength=21.10611405413 cm. --99of9 (talk) 03:02, 4 May 2016 (UTC)
•   Support A more general application of this property should be proposed. Snipre (talk) 13:21, 4 May 2016 (UTC)

@Wostr, ArthurPSmith, 99of9, Snipre:  Done With a general description. Lymantria (talk) 19:52, 4 May 2016 (UTC)

Mercalli intensity scale

Description measurement of the intensity of an earthquake Mercalli intensity scale (Q170350) String "intensity" in en:Template:Infobox earthquake and "mercalli" in es:Plantilla:Ficha de terremoto earthquakes (V?I{1,3}|I?[VX]|XI{1,2}) 2016 Kaohsiung earthquake (Q22662663) → VII Possibly, if there is a source (e.g. from USGS) that has this information in a convenient format for a bot.
Motivation

Mercalli scale intensity is an important and commonly used attribute for earthquakes, and is often one of the things in the infobox on Wikipedia articles about earthquakes.

I am somewhat bothered by the fact that mercalli is typically given and displayed as a roman numeral, but at least if this is used in an infobox w/ lua, special formatting could at least be done there. (and in the way we have formatter urls for identifiers, maybe there could be something for formatting this type of thing on Wikidata). Aude (talk) 12:01, 7 February 2016 (UTC)

Discussion
• @Aude: Datatype should be "item", with an item created for each of the twelve possible values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:30, 12 March 2016 (UTC)
•   Support --Tubezlob (🙋) 17:49, 17 April 2016 (UTC)
•   Support @Aude: To allow roman numerals, datatype should be changed into string, and Regex should be something like (V?I{1,3}|I?[VX]|XI{1,2}) I changed that in the proposal above, but feel free to revert that. Lymantria (talk) 07:38, 24 April 2016 (UTC)
•   Support as datatype "item". --Pasleim (talk) 22:37, 25 April 2016 (UTC)

@Aude:  Done and created twelve items with intensity scale numbers as the possible values. Lymantria (talk) 14:52, 26 April 2016 (UTC)

Description Identifier for entries in MathWorld, online mathematics reference work. MathWorld (Q719112) External identifier en:Template:MathWorld: |id= - Template:MathWorld (Q6272939) [A-Z][A-Za-z]* http://mathworld.wolfram.com http://mathworld.wolfram.com/$1.html Motivation MathWorld is on of the widest used online basic mathematical reference works. It has a template (Template:MathWorld (Q6272939)), that is used in many wikipedias. Lymantria (talk) 15:10, 23 April 2016 (UTC) Discussion volume formula Not done Description formula to calculate the volume of an object Mathematical expression geometrical object LaTeX strings cube (Q812880) => "V = a^3" or "a^3",sphere (Q12507) => "V = \frac{4}{3} \pi \cdot r^3", solid of revolution (Q725939) => "V = \pi \cdot \int_{a}^{b} (f(x))^2 \mathrm{d}x" Motivation Adding this property with data type "Mathematical Expression" allows us to save language indepentant information, used by several articles. This kind of property should also emphasize, why we should have several properties additionally to the TeX String one to add a meaning to the formatted TeX String. – The preceding unsigned comment was added by 2003:45:4f71:7301:d515:92cf:a661:d7f8 (talk • contribs) at 11 feb 2016 05:03 (UTC). Discussion Not done No consensus. Lymantria (talk) 08:52, 7 May 2016 (UTC) lastedit (Wikivoyage) Withdrawn Description Date stamp; when was info in this record last verified? WV listings get outdated quickly. date of disappearance (P746) is close, but specific to missing persons. Point in time lastedit in voy:template:listing at Template:Listing (Q14330485) calendar date, point in time (P585) 1867-07-01 • Comment Maybe "Wikivoyage entry last checked" as name? point in time (P585) is generally used for individual statements. dissolved, abolished or demolished date (P576) can be used to indicate that a place no longer existing. --- Jura 09:43, 15 May 2016 (UTC) • Comment We don't know the venue has disappeared (otherwise we would remove the listing outright). All this field tells us is that the venue was still extant as described at the date listed. It's a "date last seen" but doesn't necessarily put the venue on a missing persons list. K7L (talk) 18:54, 15 May 2016 (UTC) • P576 could be used without an actual date (unknown value) or with a year. At Wikidata, items are not deleted because they are no longer current. --- Jura 05:08, 16 May 2016 (UTC) • P576 without an actual date might work as a 'closed' flag (next item, below) but wouldn't fit this item. The 'lastedit' field indicates that an establishment was last seen alive by a Wikivoyage editor on that specific date, for instance {{sleep|name=Some cowshed in Bethlehem|lastedit=0001-12-25}} doesn't tell us whether they're still housing voyagers in stables because there was no room in the inn, only that it was happening the last time we checked - on Christmas Day. retrieved (P813) (access date, date retrieved) might be closer? K7L (talk) 13:10, 16 May 2016 (UTC) • Oppose For wikidata, this is in metadata. For Wikivoyage, this is almost certainly not going to be kept in sync. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 16 May 2016 (UTC) • Comment This is *not* the same as the metadata, as it doesn't update on every edit - only manually each time someone has verified the listing is accurate or the venue is still in operation. For instance, I log on in 1912 and create a "get in - by boat" listing for SS Titanic, a fine and luxurious vessel that just launched. It gets forgotten for a few years, then someone edits it to correct the name from SS Titanic to RMS Titanic without verifying the rest or checking whether the boat is still running. That bumps forward the edit date in the metadata, but doesn't update Wikivoyage's "lastedit" because that's used as a "last verified" date and not merely "last touched". They're not the same, so they should not be synchronised in any way. K7L (talk) 19:53, 16 May 2016 (UTC) • Oppose This can be expressed using Wikidata references or qualifiers. This property would contradict good practice in Wikidata. -- T.seppelt (talk) • Oppose Not appropriate for Wikidata. --Srittau (talk) 23:23, 16 May 2016 (UTC) closed (Wikivoyage) Withdrawn Description Boolean flag indicating a venue is permanently closed and should be removed from all Wikivoyage editions. dissolved, abolished or demolished date (P576) can be used to indicate that a place no longer exists if we know when it closed - but we often find these years later as URLs break or telephone numbers go out of service. Item Not used as a Template:Listing (Q14330485) listing field; setting this 'true' should suppress display of the entire template or display an error. true, false, (blank) false • Comment This effectively invalidates the entire record for Wikivoyage purposes, as the guide rarely mentions something which no longer exists. Likely only useful to track closed venues to ensure they're removed from other Wikivoyage languages. K7L (talk) 19:18, 15 May 2016 (UTC) • Oppose Use end date, significant event, or similar. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:24, 16 May 2016 (UTC) • Oppose Per Andy. --Srittau (talk) 18:09, 16 May 2016 (UTC) • Comment The end date looks close, but can we use it if we have no idea when the venue closed - but do know that a call today gives "number not in service"? K7L (talk) 19:53, 16 May 2016 (UTC) • Oppose per Andy. -- T.seppelt (talk) 20:10, 16 May 2016 (UTC) google-plus Not done Description URL to venue's user-supplied content page on Google+, see proposal at Wikidata:Property_proposal/Generic#Google.2B External identifier google in voy:de:vorlage:vCard at Template:Listing (Q14330485), currently a full URL, used in German-language Wikivoyage only Wikivoyage listings (de) integer or text (username), website account on (P553) "Komische Oper Berlin" listing in voy:de:Berlin points to https://plus.google.com/102309912006062068078/ https://plus.google.com/$1/

Closed as duplicate of Wikidata:Property proposal/Google plus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:49, 16 May 2016 (UTC)

Place of marriage

Description location where the marriage was celebrated, qualifier for property "spouse" (P26) Item Wikidata:Database_reports/Constraint_violations/P26#Qualifiers items with spouse (P26) currently using location (P276) as qualifier Property_talk:P26#Place_of_marriage --- Jura 11:26, 17 April 2016 (UTC)
Discussion
• I prefer the use of significant event (P793)=wedding (Q49836) with qualifier location (P276) and point in time (P585) like on Q9726#P793 --Pasleim (talk) 08:41, 18 April 2016 (UTC)
• +1 to this format. --Yair rand (talk) 16:14, 18 April 2016 (UTC)
• The problem with P26 stuff is that it needs to be repeated on the item of the spouse. Potentially, you are burdening yourselves with quite a lot of work with this approach. If there is really more to list about the event, a separate item linked from both seems more compact.
--- Jura 12:25, 19 April 2016 (UTC)
• The problem with this approach would be that people can have multiple spouses and multiple weddings. If they are listed separately, matching wedding with spouse may be non-trivial. Especially if due to some local laws date of record of the marriage and date of the wedding are different (the difference will usually be small but still would impede automatic processing). Laboramus (talk) 20:15, 20 April 2016 (UTC)
•   Oppose Per Pasleim. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:21, 18 April 2016 (UTC)
•   Support Now that spouse (P26) is the central property here, it is best to have all qualifiers on marriage with spouse (P26) as qualifiers, and not to seperate the marriage place (and date) from it using significant event (P793). Lymantria (talk) 10:58, 29 April 2016 (UTC)
•   Support --Almondega (talk) 15:03, 12 May 2016 (UTC)
•   Support per Lymantria. Thryduulf (talk: local | en.wp | en.wikt) 19:36, 12 May 2016 (UTC)
Done --Tobias1984 (talk) 19:02, 17 May 2016 (UTC)

Wikidata time precision

Description numeric value used by Wikidata to describe the corresponding time/date precision Quantity integers (1-14) Year > 9, Day > 11 Wikibase User:Jura1
@Lymantria: As in the sample above, the idea is to place it on items like month (Q5151) allowing to add a label to precision in queries, sample: [1].
--- Jura 21:05, 2 May 2016 (UTC)
Ah, right.   Support. Lymantria (talk) 06:03, 3 May 2016 (UTC)

@Jura1:  Done --Lymantria (talk) 06:49, 4 May 2016 (UTC)

Wikidata month number

Done: no label (P2837) (Talk and documentation)
Description numeric value of month month (Q5151) Quantity 12 items for months 1-12 none May > 5
•   Comment Allows to add month names to query results with datatype time.
--- Jura 08:22, 5 May 2016 (UTC)
•   Question Can't this be fixed by using
numeric value (P1181)   ⟨ "5" ⟩
? May being 5 is more general than in Wikidata. Lymantria (talk) 09:51, 5 May 2016 (UTC)
• We could do almost all quantity datatype properties with P1181. It just gets more complicated to build queries and/or monitor items for changes. Every time someone edits an item that may be completely unrelated, potentially they could break everything.
--- Jura 10:17, 5 May 2016 (UTC)
• Can you give an example where this property is needed? --Pasleim (talk) 21:06, 7 May 2016 (UTC)
• To generate this, it can be helpful.
--- Jura 22:56, 7 May 2016 (UTC)

@Jura1:  Done without "Wikidata" in the name, this month number is way more general. Lymantria (talk) 07:50, 14 May 2016 (UTC)

• The problem with that is that it could lead to more than 12 items with the property.
--- Jura 09:34, 14 May 2016 (UTC)
• Agreed. I would prefer the more specific Wikidata to be in the title. @Lymantria, Jura1: --Izno (talk) 14:01, 16 May 2016 (UTC)
• Right. Adjusted the English and Dutch descriptions accordingly. Other languages I am not capable of. Lymantria (talk) 15:20, 16 May 2016 (UTC)

applies in

Not done
Description See above. Probably only used with property "property used in this template". Item wikimedia projects Template:Authority control (Q3907614) "uses" ORCID iD (P496); "applies in" English Wikipedia (Q328)
Discussion

Motivation:

Proposed by: GZWDer (talk) (Add your motivation for this property here.) GZWDer (talk) 15:40, 6 March 2015 (UTC)

@GZWDer:   Not done Non-stand-alone proposal, with the referenced proposal is missing. This makes no sense and can not be created as is. If this is still required, please open a new, stand-alone proposal. --Srittau (talk) 23:15, 5 May 2016 (UTC)

Gettext plural form string

Not done
Description string used in Gettext PO files to determine plural forms grammatical number (Q104083) String languages German (Q188) => "nplurals=2; plural=(n != 1);" https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html#index-nplurals_002c-in-a-PO-file-header
Discussion

Motivation: GNU Gettext is a widespread translation program. One of its features is a distinction of the grammatical number. For example, English has 2 grammatical “numbers”: singular and plural. Russian has 4 of them, Chinese only has one, and so an. Additionally, the grammatical number can differ a lot for each language. Gettext has a syntax to desribe the grammatical number of a language. See the source to learn more. While this is very technical, I think having this syntax also has a nice side-effect: It provides a precise way to describe the various grammatical number systems (oddly referred to as “plural forms” in Gettext manuals) of the languages of the world. That's great to build a database IMO. So its use is clearly beyond just Gettext. A list of known “plural forms” values can be accessed here: https://localization-guide.readthedocs.org/en/latest/l10n/pluralforms.html This proposal may not be complete, so please suggest anything which is missing! Thanks.

Proposed by: Wiki-Wuzzy (talk)

•   Support --- Jura 23:32, 20 April 2015 (UTC) Need to think this over. --- Jura 10:58, 8 May 2015 (UTC)
•   Support. Wiki-Wuzzy is there any benefit in having the datatype = "item" instead (and rename the property "grammatical number")? with items created for each different form of grammatical number. This would mean languages with 4 'plural forms' would have 4 values for this property. Filceolaire (talk) 13:07, 28 April 2015 (UTC)
• No, because you inevitably lose information if you do this, because terms like “plural” are not strictly defined. Most importantly, you'd lose the rules (a “plural” does not follow the same rules for all languages which have a plural). Your idea soundns more like something which could (!) be used for another property. --Wiki-Wuzzy (talk) 12:22, 2 May 2015 (UTC)
•   Support, but uncertain, per Kaldari Popcorndude (talk) 00:53, 11 November 2015 (UTC)
• couldn't you have an item version for the vast majority of these?
• "has plural": "1 thing", "not 1 thing"
• "has plural": "1 thing", "more than 1 thing"
• "has plural": "no plural".
• There are 143 languages listed, these 3 cover 120 of them. Or perhaps a slightly more general property for what grammatical category (Q980357)s the language marks? Popcorndude (talk) 12:32, 11 October 2015 (UTC)
•   Comment Having a value based on a specific piece of software seems short-sighted. Shouldn't we be recording this data semantically? Kaldari (talk) 23:25, 10 November 2015 (UTC)
•   Comment As with others above, I think this would be best to be item-valued, with values required to be from a small class of allowed items.
With that proviso, I would   Support.
But it would be good to be able to record on that small set of items how the class was represented in GNU Gettext. It seems to me that this would need a new property, perhaps "syntactic expression", so that one could record
⟨ plural-type N ⟩ "syntactic expression" search ⟨ "nplurals=2; plural=(n != 1);" ⟩
As far as I can see this property for how something is represented in a particular programming or specification language appears to be something that still needs to be created (though it's possible I may just have missed it). Jheald (talk) 21:51, 17 November 2015 (UTC)

@Wiki-Wuzzy, Jura1, Filceolaire, Popcorndude, Kaldari, Jheald:   Not done: no consensus for the property as is. But I can see a consensus for an item-based solution, where languages, whose plural-form works similar are referencing the same item. Per Jheald, this item could then get a property for a gettext string. You might consider a new proposal for those two properties. --Srittau (talk) 23:21, 5 May 2016 (UTC)

central government bond yield (10 year maturity)

Not done
Description the interest rate on a 10 year government bond Number (not available yet) Countries, states, cities Percentages 8.32% A robot should update this
Motivation

The government 10 year bond yield is important information for assessing credit markets Mcnabber091 (talk) 07:24, 17 December 2015 (UTC)

Discussion

Comment Qualifier would be historical date of the interest rate. Mcnabber091 (talk) 04:51, 20 December 2015 (UTC)

Comment @Mcnabber091: In some countries these bond move up and down a lot, see for instance these graphs. Are you prepaired to do mass imports of historical data on this property? Only two or three figures about random moments in time I think do not yield a lot of information. Lymantria (talk) 06:40, 7 May 2016 (UTC) @Lymantria: This property would be updated once per year. A yearly snapshot is better than nothing.Mcnabber091 (talk) 06:33, 17 May 2016 (UTC)

•   Not done lack of support, unclear if it's ever going to be used.
--- Jura 15:38, 19 May 2016 (UTC)

Not done
Description the amount of liabilities (debt) held by households for a specific type of debt Number (not available yet) Countries, states, cities Currency amounts $56 billion in home mortgages A robot should update this Motivation Household liabilities play an important role in the economy and it is good to know what types of loans households have Mcnabber091 (talk) Discussion Comment I was thinking of deleting this property and then create separate properties for each liability type (household mortgage debt, household auto loans, household credit card debt, etc.). In that case I would delete this property and create new properties to work for the data. Please see this table to get an example of what data I want to import into Wikidata: Household assets and liabilities Mcnabber091 (talk) 01:18, 21 December 2015 (UTC) • Not done lack of support, unclear if it's ever going to be used. --- Jura 15:38, 19 May 2016 (UTC) household assets by source Not done Description the amount of assets held by households for a specific type of asset Number (not available yet) Countries Currency amounts$3.5 trillion in equity stock A robot should update this
Motivation

Comment Household assets are an important part of the economy. It is important to know the composition of household wealth. Mcnabber091 (talk) 07:38, 17 December 2015 (UTC)

Discussion

Comment Please see the household liability by type property proposal. Mcnabber091 (talk) 05:23, 20 December 2015 (UTC)

•   Not done lack of support, unclear if it's ever going to be used.
--- Jura 15:38, 19 May 2016 (UTC)

sovereign wealth fund

Not done
Description sovereign wealth fund of the country or region sovereign wealth fund (Q1061648) Item countries, regions subclass of organization (Q43229) People's Republic of China (Q148) → China Investment Corporation (Q1824816) en:Largest sovereign wealth funds#Largest sovereign wealth funds etc.
Motivation

Sovereign wealth funds can have a large amount of money that can impact a national economy. Mcnabber091 (talk)

Not done
Description the amount of household wealth (net worth) per adult Number (not available yet) Countries Currency amounts $3,500 per adult A robot should update this Motivation Household wealth is very important for analyzing an economy Mcnabber091 (talk) 07:38, 17 December 2015 (UTC) Discussion Comment This property should be easy to create. It would be a simple amount. The qualifier would be the historical date and currency. Mcnabber091 (talk) 08:39, 20 December 2015 (UTC) • Not done lack of support, unclear if it's ever going to be used by proposer. --- Jura 15:32, 19 May 2016 (UTC) individual tax rate Description the percentage tax rate on individuals by income Number (not available yet) Countries, states, cities Percentage 34% A robot should update this Motivation Tax rates and tax thresholds are important economic statistics to monitor government finance and economic behavior. Mcnabber091 (talk) 06:25, 18 December 2015 (UTC) Discussion Comment This property would be the individual tax rate for a country. It would have 3 main qualifiers: historical date, lowest income threshold and highest income threshold. Item: Country. Property: Individual tax rate Qualifier: date. Qualifer: lowest income threshold. Qualifier: highest income threshold. Would this work? Mcnabber091 (talk) 08:52, 20 December 2015 (UTC) • Support. I think this will work with those qualifiers but you need to propose the qualifier properties for the threshold. Joe Filceolaire (talk) 16:12, 22 December 2015 (UTC) @Mcnabber091, Filceolaire: Done I created the requested qualifiers as lowest income threshold (P2835) and highest income threshold (P2836). Lymantria (talk) 07:23, 14 May 2016 (UTC) capital gains tax rate Not done Description the standard tax rate investors pay on capital gains capital gains tax (Q687591) Number (not available yet) Countries Percentage 15% A robot should update this Motivation The capital gains tax rate is an important economic variable.Mcnabber091 (talk) 22:41, 20 December 2015 (UTC) Discussion • Not done lack of support, unclear if it's ever going to be used. --- Jura 15:38, 19 May 2016 (UTC) central government debt Not done Description total debt held by the central government central government debt (Q12695) Number (not available yet) Countries Number, currency$324 billion A robot should update this
Motivation

central government debt is an important economic statistic that provides information about the finances of a country.Mcnabber091 (talk) 22:51, 20 December 2015 (UTC)

Discussion

Comment this property shouldn't be too hard to create. it would have qualifiers for each year.Mcnabber091 (talk) 22:51, 20 December 2015 (UTC)

Oppose. We have total debt (P2133). Joe Filceolaire (talk) 16:42, 22 December 2015 (UTC)

Comment Do we need to make an item for each government entity such as 'united states federal government' or 'govnerment of Las Vegas'? I don't think this property would be descriptive enough when applied to the 'united states' item. Are you suggesting we would use a qualifier to show that it is central government? In that case I don't think we have a property yet that differentiates a central government. I think it would be easier to have both properties. Mcnabber091 (talk) 21:45, 25 December 2015 (UTC)

Would the property legal form fix this? I don't see how that would work. Mcnabber091 (talk) 21:57, 25 December 2015 (UTC)
Support I think total debt (P2133) at a country page could easily be misunderstood as total debt of a country and all its inhabitants or something. So I support this, but as a subproperty of total debt (P2133). Lymantria (talk) 09:49, 3 May 2016 (UTC) Second thoughts. Lymantria (talk) 13:37, 7 May 2016 (UTC)
• @Lymantria: I think this property is specific enough. It means exactly the about of debt outstanding for the central government of a country. I hope it wouldn't get misunderstood. Mcnabber091 (talk) 06:15, 17 May 2016 (UTC)
•   Not done lack of support, unclear if it's ever going to be used by proposer.
--- Jura 15:33, 19 May 2016 (UTC)

state and local combined government debt

Not done
Description combined debt for all state and local governments within a country. Number (not available yet) Countries Number. positive or negative -352 billion A robot should update this
Motivation

State and local government finance is important for economic analysis Mcnabber091 (talk) 23:06, 20 December 2015 (UTC)

Discussion
•   Not done lack of support/unclear if it's actually ever going to be used by proposer.
--- Jura 15:30, 19 May 2016 (UTC)
Discussion

Comment I'm not sure how this would work. The goal is to have a list of public investment funds within a country.Mcnabber091 (talk) 01:18, 21 December 2015 (UTC)

Comment I have reshaped the proposal. --Jklamo (talk) 21:49, 9 April 2016 (UTC)

•   Not done lack of support, unclear if it's ever going to be used.
--- Jura 15:38, 19 May 2016 (UTC)

Motivation

This is an important economic statistic for analyzing an economy.

Discussion

Comment I was thinking about deleting this property proposal and replacing it with multiple new properties that are more specific (for example: Central government military expenditure, Central government healthcare expenditure etc.). Would this be the appropiate way to import this type of data into Wikidata. Please see this example of the data I'm talking about: [2]. I can't find any relevant examples on Wikidata yet. Mcnabber091 (talk) 05:14, 20 December 2015 (UTC)

•   Comment Please rename as "Expenditure by Type" so it can be used for other ornanizations besides national governments.
Use with qualifier 'applies to part (P518)' to indicate what type each line is. Joe Filceolaire (talk) 16:37, 22 December 2015 (UTC)
•   Comment @Filceolaire: As you are suggestion if this were used for the U.S. federal budget, then it would be 'expendtiture by type' under the United States item (or should another item be created for U.S. federal government)? Using the United States item, I feel like that is not descriptive enough to just be 'expenditure by type'. I feel like this would be more convenient to keep it as 'central government expenditure by type' and create a new property for 'expenditure by type' that would apply to all other entities. Mcnabber091 (talk) 20:29, 25 December 2015 (UTC)
I was reading through more comments and I saw that you suggested 'applies to part' property to separate separate lines. Can you give me an example of it being used in this way? Mcnabber091 (talk) 21:59, 25 December 2015 (UTC)
Mcnabber091 I disagree on the name This should be a generic property for government expenditure whether it is central, state or county. The important thing is to distinguish between the statistics for the state and statistics for the state government so "Government expenditure by type" works for me.
I can't think of an example off hand of applies to part (P518) used with an economic property - these economic properties aren't much used yet - but that is certainly my understanding of what applies to part (P518) (Description:"part of the item for which the claim is valid") was created for. Joe Filceolaire (talk) 20:19, 30 December 2015 (UTC)
@Filceolaire: Thank you for the comment. I change the name to 'government expenditure by type'. It would be a big help if you could make comments on the other properties proposals on this page. Mcnabber091 (talk) 05:00, 31 December 2015 (UTC)
He is unlikely to respond. RIP.
--- Jura 15:38, 19 May 2016 (UTC)
•   Not done lack of support, unclear if it's ever going to be used.
--- Jura 15:38, 19 May 2016 (UTC)

central government expenditure

Not done
Description total expenditure by the central government Number (not available yet) Countries Number, currency $32 billion A robot should update this Motivation government expenditure is an important economic statistic. Mcnabber091 (talk) 22:57, 20 December 2015 (UTC) Discussion Comment this property would be a single$ amount. qualifier by year.Mcnabber091 (talk) 22:57, 20 December 2015 (UTC)

Comment Do we need to make an item for each government entity such as 'united states federal government' or 'govnerment of Las Vegas'? I don't think this property would be descriptive enough when applied to the 'united states' item. Are you suggesting we would use a qualifier to show that it is central government? In that case I don't think we have a property yet that differentiates a central government. I think it would be easier to have the longer property title. Mcnabber091 (talk) 21:45, 25 December 2015 (UTC)

@Lymantria: I think that makes sense to me. I not very good at understanding how Wikidata works. I think the method you proposed with criterion used (P1013) would work, but it would also work as its own property. Right? Or is it redundant to have two ways that work? I feel as tho there are already properties in existence that work like this. Mcnabber091 (talk) 06:29, 17 May 2016 (UTC)

incidence

Done: incidence (P2844) (Talk and documentation)
Description probability of occurrence of a given condition in a population within a specified period of time incidence (Q217690) Number (not available yet) not yet available diseases, events 0 - 100000 cases per unit of person-time tuberculosis (Q12204) → 1000 cases per 100000 person-years (Q23893296); qualifier point in time (P585) 2013; location (P276) Earth (Q2) en:Incidence
Motivation

There is already a fairly similar property prevalence (P1193) which is about proportion of population with a specified disease at a given timepoint. Incidence is about occurrence of disease or other events in a population. It is a very useful metric in medicine and it describes the importance of a disease. Prevalence is not an illustrative metric for diseases with very different durations; instead, incidence correctly describes the rate of becoming sick. Also, it has wide applicability and large use in epidemiology in both descriptive and predictive modelling. Jtuom (talk) 14:45, 28 January 2016 (UTC)

Discussion
• @Jtuom: The example given, "1000 cases per 100000 person-years globally" is not a number. If the allowed values go up to "INF", then seven digits is insufficient. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:36, 12 March 2016 (UTC)
• @Jtuom: Are you able to respond? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:17, 12 April 2016 (UTC)
• @Pigsonthewing: Sorry for the delay. I created two new unit items (hopefully correctly) to clarify my idea. Incidence is measured with cases per person-year (Q23893259) or cases per 100000 person-years (Q23893296). Typically the unit is selected in a way that the numeric value of incidence is between 0 and 100000, but in theory it can be larger. --Jtuom (talk) 13:31, 20 April 2016 (UTC)
• @Jtuom: Personally, I would look to see only one unit used. Otherwise two diseases using different units are not really comparable using automated tools, without having rules to convert between them. --Srittau (talk) 20:45, 16 May 2016 (UTC)
• @Srittau: cases per 100000 person-years is the most common unit used. I agree that it would be easier if only one unit is used. --Jtuom (talk) 07:13, 17 May 2016 (UTC)
•   Support -ArjaA (talk) 09:00, 17 May 2016 (UTC)
•   Support I think thats's a very important property for epidemiology and medicine in general. Qualifiers could be used to restrict the validiy of a certain incidence rate to a certain population or geographic region. Sebotic (talk) 18:07, 17 May 2016 (UTC)

mentions

Not done
Description indicates that the Creative Work contains a reference to, but is not necessarily about a concept. It can be Same as Schema property "mentions":https://schema.org/mentions monolingual-invalid datatype (not in Module:i18n/datatype) all Wikisource Index pages The Kiss and Other Stories by Anton Tchekhoff (Q15839163) => s:en:Index:The Kiss and Other Stories by Anton Tchekhoff, 1908.pdfQ19186576 => s:ru:Индекс:Дмитрий Минаев - На перепутьи, 1871.pdf import from wikisource Aubrey (talk) 10:17, 8 June 2015 (UTC)

@Aubrey:   Not done, no support, seems to be the same as Wikisource index page (P1957). --Srittau (talk) 18:18, 16 May 2016 (UTC)

Yeah, thanks @Srittau:. The proposal is different from Wikisource index page (P1957), but it's too early: Wikisources are not really mapped/integrated with Wikidata, and definitely is higher priority than mentions. Aubrey (talk) 20:05, 16 May 2016 (UTC)

opening hours

Withdrawn
Description opening hours of the attraction, when applicable String hours in voy:Template:Listing Template:Listing (Q14330485) / voy:Template:See Template:View (Q14330711) / etc. per WikiVoyage formatting guidelines (voy:Wikivoyage:Time and date formats) openhours search ⟨ May 14-June 30: 10AM-5PM, Wed-Sun; July 1-Sept 1 10AM-5PM Daily; Sept 2-Oct 12 10AM-5PM Wed-Sun ⟩ from Banff (Q58337) section voy:en:Banff#See
•   Comment Seems to be the main field missing of Template:View (Q14330711). I don't think specialized datatypes for this are going anywhere.
--- Jura 18:29, 13 May 2016 (UTC)
•   Oppose Needs a structured-data solution, not free text. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 16 May 2016 (UTC)
•   Oppose I agree with Andy. A property for opening hours is necessary but not as string. -- T.seppelt (talk) 20:07, 16 May 2016 (UTC)
• @T.seppelt: can you clarify which other datatype you think applies and why you consider Wikivoyage formatting guidelines "unstructured".
--- Jura 21:46, 16 May 2016 (UTC)
• There is no ideal datatype for representing repeating timespans. And since nothing is going to happen in this direction we need another solution. What about defining to items open and closed, alowing several statements per property and specifying rules by using qualifiers? For example Open with qualifiers: affected part = Monday, start = 8 AM, end = 7 PM. Another solution would be to use the multilingual string type because every language uses different formats. In this case and for the currently proposed property a regular expression should be defined to identify malformed values. I'd be fine with this: a multilingual string with regex for identifying constraint violations. – T.seppelt (talk) 05:41, 17 May 2016 (UTC)
• Currently there is monolingual string that would allow to do this, but there is no datatype multilingual string. The problem would be that the various language versions would need to be kept in sync. To display a localized text, a single string version could be used. Based on K7L's sample above, maybe we should split this into three parts: an hour range (property), a date-range (qualifier) and a weekday range (qualifier, maybe as items).
--- Jura 06:00, 17 May 2016 (UTC)
• I mixed up the names, monolingual string is what I mean. Yes, keeping them in sync would be a big problem. Let's see if we can define a more structures solution using time-ranges and qualifiers. For those ranges we need I new datatype, I think. Maybe this proposal should be moved to Wikidata:Property proposal/Pending. -- T.seppelt (talk) 19:25, 17 May 2016 (UTC)
• "Pending" would suppose that there was an actual datatype planned for this or we came up with one. As these things don't just emerge from nothing, we would need to decide how it could work. As other systems use string datatype for the same or similar, I think we might even be able to formulate a working solution with existing datatypes. There are already lots of constructive contributions in this thread. Let's see what additional points come up (maybe Thryduulf wants to expand his suggestion) and maybe we can formulate a better proposal.
--- Jura 06:47, 18 May 2016 (UTC)
•   Support as-is, as a structured approach would require potentially a different open/close time pair for every day of the week (or two open/close pairs per day if the place is closed for lunch), multiplied by at least two or three seasons (high season, spring/fall shoulder seasons, winter) with start/end dates for each (which often would be "Victoria Day" or "Thanksgiving" or some such). If the listing is a restaurant with a bar, the kitchen might close earlier than the rest of the establishment; often a business fits into multiple categories (that resto-bar might be part of a golf clubhouse or a hotel) creating more permutations of operating hours for each of the individual roles. The difference between free-text and structured data is the difference between a line of text vs. an entire table or more. This gets complex quickly. K7L (talk) 22:47, 16 May 2016 (UTC)
•   Oppose as an unstructured field. --Srittau (talk) 23:20, 16 May 2016 (UTC)
•   Oppose as proposed. Separate properties for "opening time" and "closing time" should be proposed, this can be qualified with valid in period (P1264), has part (P527), etc. as necessary. Thryduulf (talk: local | en.wp | en.wikt) 02:00, 17 May 2016 (UTC)
• How would you group opening time and closing time? What's the advantage over the structured Wikivoyage approach?
--- Jura 05:06, 17 May 2016 (UTC)
• Wikivoyage's method is not, in any meaningful way, structured. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:24, 17 May 2016 (UTC)
• I agree with Andy - the string datatype suggestion is not structure, and nor is the current implementation at Wikivoyage. With my suggestion above I don't propose to group opening time and closing time in Wikidata using this method, that would have to be done when extracted. I have realised though that was is being desired here is actually tabular data, e.g.
May to August
Day Opening time Closing time
Monday 09:00 17:00
Tuesday 09:30 17:00
Wednesday 09:00 17:00
Thursday 09:00 20:00
Friday 09:00 20:00
Saturday 10:00 22:00
Sunday 12:00 16:00
To my knowledge there is no way currently of storing this within Wikidata. The best we can do would be something like:
⟨ Attraction ⟩ Operating hours for day search ⟨ Monday ⟩
opening time (P8626)   ⟨ 09:00 ⟩
closing time (P8627)   ⟨ 17:00 ⟩
valid in period start search ⟨ May ⟩
valid in period end search ⟨ August ⟩
. We could have addition properties for "lunch period start" and "lunch period end" if desired. Thryduulf (talk: local | en.wp | en.wikt) 12:19, 18 May 2016 (UTC)
Unfortunately it's more complicated; the high season might run from July 1 (Q17611863) to the first Monday in September (Q10901070), with the shoulder season as everything else between the last Monday before May 24 (Q2916311) and the second Monday in October (Q13959). Easter parade (Q12056872) as an event listing? The first Sunday after the first full moon after equinox (Q1315). Have fun. K7L (talk) 14:00, 18 May 2016 (UTC)
How is Labour Day (Q10901070) more complicated than August (Q122)? As long as there is an item for whichever event or date you want to use as a deliminating period the suggestion above will work just fine. If there isn't an item, you just need to create one. Thryduulf (talk: local | en.wp | en.wikt) 14:48, 18 May 2016 (UTC)
We get odd cases for event listings like "Town Winter Festival, one weekend in mid-February" where we might have an exact date this was held this year but no exact date when it will fall next year until the event's organisers announce it. Most likely, there is no structured solution which addresses everything. K7L (talk) 15:25, 18 May 2016 (UTC)
For that you'd just use the precision you do know (February) in the structured data and have anything non-structured as an additional comment. The entire point of Wikidata is that it is structured data - from WD:ABOUT: "Wikidata is [...] a free, collaborative, multilingual, secondary database, collecting structured data[...]". If you want something other than structured data then Wikidata is the wrong solution. Thryduulf (talk: local | en.wp | en.wikt) 17:07, 18 May 2016 (UTC)
Comment This is an interesting proposal. I don't think we necessarily need to have a separate field for each part and there may be details we can't cover.
--- Jura 15:54, 19 May 2016 (UTC)
•   Support There are things that can not be structured because they have too many culturally-specific exceptions (closed when it rains? Open for a few days after each Ramadan?) Imposing structure won't always work. An hybrid approach would be the best I guess. Syced (talk) 06:47, 19 May 2016 (UTC)
• If things cannot be structured, the they do not belong in Wikidata, which is specifically for structured data. (The few exceptions that exist simply allow humans to contribute to Wikidata). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 20 May 2016 (UTC)
•   Options There is a template at Wikivoyage to format this in some languages, e.g. at voy:fr:Modèle:Horaire. The template seems fairly straight-forward and could be used as a basis for a string format.
I also found mention of using OSM format for entries. The later doesn't seem to be that easy to use.
--- Jura 15:54, 19 May 2016 (UTC)
•   Oppose per "structured" argument. Generally, any string-formatted data would need to be "structured" to be of use. Regarding the "n days past Ramadan" or "Easter", I think Thryduulf's counterproposal covers that. --Izno (talk) 18:20, 19 May 2016 (UTC)
•   Comment this seems to be another case where wikidata's limited set of datatypes makes things difficult. The actual underlying structure here is really something like a list of date-range specifications where each date-range specification consists of the range of dates for validity mapped to a list of day-of-week or other specific date-matching criteria each of which is then mapped to a list of time spans. I.e. the full structure is a map of items to maps of items to lists. To attach it as a single property value to the attraction would mean allowing nested lists and maps as property values, a significant increase in complexity. What about allowing 'json' datatypes for strings? That might not be too hard to manage... But rendering for display could be tricky. ArthurPSmith (talk) 20:21, 19 May 2016 (UTC)
•   Comment OpenStreetMap's method, which is semi structured, is at http://wiki.openstreetmap.org/wiki/Key:opening_hours Can we learn anything from that? The microformats community also did some analysis, see microformats.org/wiki/opening-hours Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:43, 20 May 2016 (UTC)
•   Comment I propose that we close this as not done' for now, and open up an RfC on a separate page, to look at which data type(s), property or properties are needed, based on some real-world examples and other services' schemas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:46, 20 May 2016 (UTC)
• That seems sensible as long as the closure is without prejudice to future property proposals related to this - (almost?) nobody is objecting to the concept of opening hours on Wikidata, rather there is no agreement regarding the method of doing so. Thryduulf (talk: local | en.wp | en.wikt) 00:32, 21 May 2016 (UTC)

wheelchair accessibility

Data type Item handicap in voy:fr:Modèle:Listing at Template:Listing (Q14330485) WikiVoyage listings yes, no, with assistance; see voy:fr:Modèle:Handicap/Template:Wheelchair accessibility (Q17365980) for values wheelchair accessibility (P2846)   ⟨ wheelchair accessible (new item) ⟩
•   Comment seems to be missing.
--- Jura 22:10, 14 May 2016 (UTC)
• Please provide an example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:39, 16 May 2016 (UTC)
• Generally,   Support, but please provide an example and list the items that should be used as values, or alternatively, which items should be created. --Srittau (talk) 18:13, 16 May 2016 (UTC)
• @Srittau: I think that it is included. Which part isn't clear?
--- Jura 18:16, 16 May 2016 (UTC)
• You are right. An example is required, though. --Srittau (talk) 18:37, 16 May 2016 (UTC)
•   Done --Srittau (talk) 18:45, 16 May 2016 (UTC)
• I don't think we should create the items before we actually agree to create the property.
--- Jura 18:50, 16 May 2016 (UTC)
• Sorry, I meant I added an example. I agree with you. --Srittau (talk) 18:52, 16 May 2016 (UTC)
•   Support -- T.seppelt (talk) 20:09, 16 May 2016 (UTC)
•   Support Syced (talk) 06:59, 19 May 2016 (UTC)
•   Support, but require that the items be more semantic than "green". --Izno (talk) 18:29, 19 May 2016 (UTC)
•   Support. Thierry Caro (talk) 11:03, 20 May 2016 (UTC)
•   Comment Wheelchair accessibility is not a binary property. See the types of access and examples listed at http://wiki.openstreetmap.org/wiki/Key:wheelchair for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:10, 20 May 2016 (UTC)
•   Support, subject to agreement as to what property should be used to bind this attribute to the item that is wheelchair-accessible. While we're defining this, I suggest that we should consider other forms of special-needs accommodation at the same time: for example, support for deaf, blind or autistic individuals. -- The Anome (talk) 11:15, 21 May 2016 (UTC)
• You might want to join Wikivoyage if you want to add this there. For now, Wikidata has already problems supplying what they currently use/need.
--- Jura 11:41, 21 May 2016 (UTC)

@Jura1, T.seppelt, Syced, Izno, Thierry Caro, Pigsonthewing:   Done -- Lymantria (talk) 13:56, 21 May 2016 (UTC)

node (OpenStreetMap), way (OpenStreetMap)

Withdrawn
Description OpenStreetMap "element" may be one of "node", "way" or "relation" and a number. We have OpenStreetMap relation ID (P402) but are missing the other two. Item openstreetmap in voy:fr:modèle:listing at Template:Listing (Q14330485) currently accepts a full URL. This will need two new properties (OSM node, OSM way) to match format of existing P402 (OSM relation). numeric http://www.openstreetmap.org/node/4011033716 is the Titanic Memorial at Belfast City Hall in Ulster. http://www.openstreetmap.org/node/$1 or http://www.openstreetmap.org/way/$1

Data type External identifier people, organizations, other \d{22}|\+[-\w_\u00C0-\u00FF]+ (64-bit int base10 encoded and vanity URL) Ubuntu (Q381) -> +Ubuntu Michael Bloomberg (Q607) -> 10055787708941310856 Mitt Romney (Q4496) -> +MittRomney see User:Nikki/P553#Google+ for current usesFor Wikivoyage: googleplus search ⟨ 102309912006062068078 ⟩ in de:Berlin would point to https://plus.google.com/102309912006062068078/ website account on (P553) statements https://plus.google.com/$1 Jura 09:51, 15 April 2016 (UTC) Discussion • Question @Jura1: How will this data be imported? Give properties that could be filled in using this external resource. Why are both a numerical ID (used by Google APIs) and the vanity URL allowed values? Considering most of its users were coerced into creating an account and subsequently forgot, how can we be assured the information is meant to be public? Dispenser (talk) 20:04, 15 April 2016 (UTC) • Have a look at Nikki's list. --- Jura 23:11, 16 April 2016 (UTC) • Oppose No example; conflicting allowed values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:19, 18 April 2016 (UTC) • Support Both number ID as well as strings like +Ubuntu are valid identifiers, so I don't see conflicting allowed values. All allowed values point to Google plus pages via the formatter URL. • Support, widely used social network. We should prefer vanity URLs if an item has one, otherwise use the internal ID. This can be documented. --Srittau (talk) 18:07, 16 May 2016 (UTC) • I'd Support giving this the same treatment as Twitter username (P2002) and Facebook ID (P2013) because it's just more of the same. K7L (talk) 20:46, 16 May 2016 (UTC) @Jura1, K7L: Done, points by Andy have been addressed. --Srittau (talk) 16:12, 21 May 2016 (UTC) Dictionary of Canadian Biography ID Description entry of the item in the Dictionary of Canadian Biography External identifier human (Q5) Lomer Gouin (Q764557) → gouin_lomer_15F http://www.biographi.ca/en/bio/$1.html and http://www.biographi.ca/fr/bio/$1.html Motivation It was proposed in the proposal of Québec cultural heritage directory people identifier (P2592). Very usefull for starting a article on Wikipedia. Fralambert (talk) 03:21, 13 March 2016 (UTC) Discussion leading position in this organisation Withdrawn Description Indicates the leading position(s) in this organisation. The qualifier below indicates the person who holds the posisiton. Item position (Q4164871) See below position holder Withdrawn Description qualifier that indicates who holds the leading position Item human (Q5) search ⟨ Q6501749 ⟩ search ⟨ Q57665 ⟩start time (P580) ⟨ 1 okt 2014 ⟩ search ⟨ Q2114175 ⟩ search ⟨ Q6231954 ⟩start time (P580) ⟨ 1 sep 2000 ⟩ search ⟨ Q61061 ⟩ search ⟨ Q7025311 ⟩start time (P580) ⟨ 1 jun 2013 ⟩ Motivation See my oppose vote with provost and chanchellor proposals. Lymantria (talk) 14:51, 3 May 2016 (UTC) Discussion • Oppose all four above proposals. We don't need redundant statements or properties. --Yair rand (talk) 21:37, 3 May 2016 (UTC) Withdrawn since corporate officer (P2828) is created, in favour of that property. Lymantria (talk) 19:09, 9 May 2016 (UTC) goratings ID Done: Goratings ID (P2805) (Talk and documentation) Description goratings.org player identifier Go Ratings (Q23058744) Number (not available yet) Go player (Q12039558) or Go professional (Q3186699) Ke Jie (Q18653975) → 1195 http://www.goratings.org/ratings.json http://www.goratings.org/players/$1.html
Motivation

I am working on updating elo ratings of go players (current progress described here), so far I have been matching the players according to their name, but there are multiple players with same name, which produces collisions, using goratings ID would solve this, because it is unique for every player. Wesalius (talk) 08:51, 27 April 2016 (UTC)

Discussion

@Wesalius:  Done with datatype external identifier. Lymantria (talk) 07:28, 4 May 2016 (UTC)

niece

Not done
Data type MISSING MISSING MISSING MISSING
Motivation

Discussion

@Balajijagadesh:  Not done Incomplete proposal. Lymantria (talk) 17:09, 9 May 2016 (UTC)

professional name (Japan)

Represents professional name (Q11415657) Item human (Q5) instances of professional name (Q11415657) (item for holder) → Karaku Sanshōtei (Q11356887) jawiki
•   Comment Currently these are mixed up in items for people.
--- Jura 07:20, 3 May 2016 (UTC)
• @Jura1: Could you give an example of an actually correct ues? For instance, how would it be used in Mansai Nomura II (Q910611)? Lymantria (talk) 06:03, 12 May 2016 (UTC)
• For the sample item above, one would need to create 9 items for each holder which would all link to Q11356887. Some of them already have infoboxes on the linked Japanese article. There are few similar lists I came across when trying to find dates for people. I also asked for input on Wikidata:井戸端. Maybe you could get your item sorted out there as well.
--- Jura 10:19, 12 May 2016 (UTC)
• I'll wait for a complete example. There are more kinds of professional names, even within Japan, e.g. many actors and writers do use professional names. We already have pseudonym (P742) and art-name (P1787), I'm afraid this is confusing and will be used wrongly. Lymantria (talk) 05:39, 13 May 2016 (UTC)
• @Lymantria: I hesitate to create the nine items without being able to link them. Obviously, I would make use of the property if it's created in a reasonable timeframe.
--- Jura 12:02, 13 May 2016 (UTC)

@Jura1:  Done - I hope you make it possible to add Wikidata property example (P1855). Lymantria (talk) 07:59, 14 May 2016 (UTC)

• Thanks @Lymantria::   Done. I will try to add more samples from frwiki.
--- Jura 07:38, 17 May 2016 (UTC)

totem

Done: totem (P2831) (Talk and documentation)
Description Totem. In many indigenous cultures an individual or group has a particular totem (e.g. a type of animal) totem (Q263443) Item humans, clans, tribal groups, ... John Stewart Murray (Q24002220) -> Siluriformes (Q59576) "his cultural totem was Burapac (the catfish)"
Motivation

Some aboriginal Australians listed in the Australian Dictionary of Biography have a clearly referenced totem, which is an important personal "property" to them. 99of9 (talk) 02:22, 4 May 2016 (UTC)

Discussion
Support It's gennerally more associated with the clan or the tribe, but it can be referenced. --Fralambert (talk) 01:56, 5 May 2016 (UTC)

@99of9, Fralambert:   Done -- Lymantria (talk) 05:49, 12 May 2016 (UTC)

iTunes artist ID

Description artist ID in iTunes External identifier human (Q5) Kygo (Q16845512) → 635806094 https://itunes.apple.com/en/artist/id$1 Motivation (Add your motivation for this property here.) Mikey641 (talk) 15:30, 12 May 2016 (UTC) Discussion • Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:07, 16 May 2016 (UTC) • Question Should we add the id part of the artist to this property? It seems to me that it is there for a reason in the URL, possibly to be able to have vanity URLs for artists. --Srittau (talk) 08:31, 18 May 2016 (UTC) Srittau, i didnt add the id part cause i saw that Apple Music album ID (P2281) didnt have one too.--Mikey641 (talk) 16:46, 18 May 2016 (UTC) @Mikey641, Pigsonthewing: Done --Lymantria (talk) 12:56, 23 May 2016 (UTC) Hi! I have find now that /en/ in the URL Formatter itunes.apple.com/en/artist/id$1 - doesn't work now!
Maybe the site itunes has changed its url format...
Now all ids work without this part: /en/ in the url!
With /en/ now this property completely invalid!
Please! Could you edit? This part should be removed!
Thank you!
Aokoroko (talk) 12:44, 9 January 2017 (UTC)

accomplice

Withdrawn
Description accomplice, co-perpetrators of a crime accomplice (Q706884) Item humans (instances of human (Q5)) Gool Badsha Mahomed (Q24088055) <-> Mullah Abdullah (Q16058969) were accomplices (both perpetrators of Battle of Broken Hill (Q4870567))
Motivation

Although this relationship is sometimes linked through a notable crime, sometimes the crime isn't notable in itself, but the connection can still be made. 99of9 (talk) 07:01, 18 May 2016 (UTC)

Discussion
•   Oppose If the crime is needed to link two persons, it is by definition notable ("structural need"). --Srittau (talk) 08:28, 18 May 2016 (UTC)
An accomplice in English may not have actually committed the crime and will usually receive a lesser punishment as a result. --Izno (talk) 12:06, 18 May 2016 (UTC)
• Tentative support--there may be other ways to represent an accomplice to a crime. --Izno (talk) 12:06, 18 May 2016 (UTC)
•   weak oppose
⟨ crime ⟩  Wikidata property  ⟨ 24088055 ⟩
with search ⟨ 16058969 ⟩
as search ⟨ 706884 ⟩
would seem to work here. Thryduulf (talk: local | en.wp | en.wikt) 13:32, 18 May 2016 (UTC)
• Ok, something like that seems to work, thanks. I'll withdraw this. --99of9 (talk) 00:08, 19 May 2016 (UTC)

pricerange (Wikivoyage listings)

Not done
Description price or pricerange for Wikivoyage listings. Use price (P2284) or fee (P2555) if there is just one fixed, specific price and a currency. Item price in Template:Listing (Q14330485) as documented at voy:Wikivoyage:Listings Text. Prices for individual venues - admission prices for theatres and museums, price of a main course in restaurants or a room in a motel ⟨ Gaia House ⟩ pricerange search ⟨ dormitory $10/night, twin rooms$30/night , family room $50/night, camping$3.50/night ⟩ from Cape Maclear (Q2937250) section voy:en:Cape Maclear#Sleep voy:template:listing in individual Wikivoyage city guides
•   Comment. We don't need a field which says "budget", "midrange" or "splurge" as that's simply not what goes into the listing template entries in Wikivoyage. If anything, a vendor claiming "reasonable prices" in a listing instead of a specific numeric range is to be avoided as too vague to be meaningful. We need actual dollar amounts (or quid, euro, yen... whatever passes for local currency) or a specific numeric price range, like £90-100. If the "A Modest Proposal" restaurant has different pricing on their kids' menu, we need to say so instead of listing just one price. K7L (talk) 18:47, 15 May 2016 (UTC)
•   Oppose as proposed. Needs a more structured solution. Please also provide a real-life example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:38, 16 May 2016 (UTC)
Real-life example: https://en.wikivoyage.org/wiki/Tokyo/Roppongi#Eat Syced (talk) 06:58, 19 May 2016 (UTC)
•   Support as proposed, this is data that doesn't fit the structure as there are multiple price ranges and multiple items to be priced. A cabin will cost more than a campsite, there may be extra charges for things like boat launch, parking or dock space; there are also seasonal variations. The number of people will also affect price. It won't fit in a single three-field (item being sold, minimum price, maximum price) if there's more than one option being marketed. K7L (talk) 22:24, 16 May 2016 (UTC)
•   Oppose as proposed per Andy. Each option being marketed needs it's own statement, with has part (P527) qualifiers as appropriate. e.g.
⟨ Gaia House ⟩ price (P2284)   ⟨  10+-5 USD ⟩
has part (P527)
valid in period (P1264)   ⟨ August ⟩
. Thryduulf (talk: local | en.wp | en.wikt) 02:06, 17 May 2016 (UTC)
•   Comment although I initially suggested the use of price (P2284), fee (P2555) might be more appropriate, as it applies to a service at a given place, not the price to buy the place itself. In its current definition, P2555 only applies to tolls and admission fees. In any case, the question is if either meets the current use of "price" by Wikidata. The proposal is somewhat contradictory as it includes datatype "item", but requires "text". Maybe item could work: "dormitory" with "price" as qualifier and value "\$10".
--- Jura 07:36, 20 May 2016 (UTC)
•   Oppose as proposed: this seems to be creating a special-purpose micro-object-model of its own just for this application. I'm not sure what the right solution to this problem is, but it needs more thought. I think Thryduulf may be right that the way to do this is to add multiple price statements, each with a qualifier for what individual facet of the item's services it is pricing. .-- The Anome (talk) 11:05, 21 May 2016 (UTC)

Not done Unsufficient support. Lymantria (talk) 05:32, 23 May 2016 (UTC)

wi-fi

Done: Wi-Fi access (P2848) (Talk and documentation)
Description Indicates availability of public wi-fi hotspot at an individual venue Item wi-fi in voy:fr:Modèle:Listing at Template:Listing (Q14330485) WikiVoyage listings (fr) yes, no, free, paid; see voy:fr:Modèle:Wi-Fi for values ⟨ Sharook Riviera Grand Lodge ⟩ wi-fi search ⟨ free ⟩ (gratuit) from voy:fr:Wete#Se loger
• Please provide an example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:40, 16 May 2016 (UTC)
•   Support Would allow reuse of this much-needed information on other languages. Syced (talk) 07:08, 19 May 2016 (UTC)
•   Support this seems useful. There should be some way of noting if wifi is provided by a third party, e.g. The Cloud (Q7723489). Thryduulf (talk: local | en.wp | en.wikt) 09:17, 19 May 2016 (UTC)
•   Support. Name and password should be documented if public. Thierry Caro (talk) 10:50, 20 May 2016 (UTC)
•   Support. It would be great if you could provide the items which would be used as values for the property. E.g. free / paid / none. Or do you plan to use no-value as snak type? -- T.seppelt (talk) 09:30, 22 May 2016 (UTC)

@K7L, Thryduulf, Thierry Caro, Syced, T.seppelt: with allowed values yes (Q6452715), no (Q3877443), gratis (Q1543615) and paid (Q24202480). --Lymantria (talk) 16:14, 22 May 2016 (UTC) P.S. I added "internet access" to the description, to make clear that free wifi only counts when internet access is free (not only the location website, map etc.). Lymantria (talk) 16:29, 22 May 2016 (UTC)

payment cards

Description Payment cards accepted at venue Item credit-cards in voy:de:vorlage:vCard at Template:Listing (Q14330485) WikiVoyage listings (de) plaintext, comma-separated list of names of accepted payment cards ⟨ Pampas Grill & Bar ⟩ payment cards search ⟨ Pampas Grill & Bar ⟩ payment cards search ⟨ Pampas Grill & Bar ⟩ payment cards search
* {{vCard | type= restaurant | subtype= midrange | name= Pampas Grill & Bar | address= 22-1 Jalan Changkat Bukit Bintang | url= http://www.pampas.com.my | facebook= https://www.facebook.com/pages/PAMPAS-Grill-Bar/170094094369 | lat= 3.147819 | long= 101.707561 | map= 13 | intl-area-code= +60 | phone= 03-21485548 | mobile= 012-2111480 | fax= 03-21485548 | email= pampasgrillbar@gmail.com | hours= tägl. 17:00-00:30 (Bar bis 03:00) | credit-cards= Visa/MC/Amex | description= Das Restaurant bietet gute Steaks und Fisch sowie eine gute Auswahl an Wein und Cocktails. Die überaus freundliche Betreiberin ist immer für einen kleinen, sehr netten Smalltalk zu haben. }}
generates
"13 Pampas Grill & Bar, 22-1 Jalan Changkat Bukit Bintang, Facebook, Tel.: +60 03-21485548, Mobil: +60 012-2111480, Fax: +60 03-21485548, E-Mail: pampasgrillbar@gmail.com. tägl. 17:00-00:30 (Bar bis 03:00). Akzeptierte Kreditkarten: Visa/MC/Amex. (3° 8' 52" N 101° 42' 27" O). Das Restaurant bietet gute Steaks und Fisch sowie eine gute Auswahl an Wein und Cocktails. Die überaus freundliche Betreiberin ist immer für einen kleinen, sehr netten Smalltalk zu haben."
K7L (talk) 21:07, 16 May 2016 (UTC)
Support Sounds useful for Wikivoyage. --Srittau (talk) 21:29, 16 May 2016 (UTC)
•   Support but not as the example is formatted. Instead there should be one claim with individual items as values. Thryduulf (talk: local | en.wp | en.wikt) 02:11, 17 May 2016 (UTC)
• I changed the example to multiple claims. Although we should probably create items for card types instead of using the company items. --Srittau (talk) 15:34, 17 May 2016 (UTC)
•   Support supposedly Wikivoyage needs this. Maybe it could be expanded to any accepted means of payment (avoid mentioning cash).
--- Jura 06:05, 17 May 2016 (UTC)
• Changing it to "accepted methods of payment" sounds sensible. There are some things that don't accept cash (e.g. buses in London). I guess the allowed values should then be changed to cash (Q693464) or subclasses of payment card (Q1436963). - Nikki (talk) 10:33, 19 May 2016 (UTC)
• How about "no cash" as "accepted methods of payment"?
--- Jura 07:39, 20 May 2016 (UTC)
• I think a separate property ("non-accepted methods of payment" or something) would be better than creating items to represent negative versions of accepted methods (there's also places which explicitly say they won't accept American Express cards, credit cards in general, cheques, £50 notes...). - Nikki (talk) 10:34, 20 May 2016 (UTC)
• This should have qualifier "start date"/"end date" if known. --Izno (talk) 18:49, 19 May 2016 (UTC)
•   Support also cash and invoice should be included. We need a general super-class. –T.seppelt (talk) 16:40, 23 May 2016 (UTC)
• I am ready to create this property, but reading the given votes and comments is should be more generic: payment types accepted. The example should become something like: . And other payment types can be added, like cash, bankcard, paycheck etc. Please comment if I understand incorrectly. Lymantria (talk) 16:49, 23 May 2016 (UTC)
• I think it would be more like "Pampas Grill > (payment types accepted) > [ABCxyz card]"
--- Jura 18:31, 23 May 2016 (UTC)

@K7L, Pigsonthewing, Thryduulf, Jura1, Nikki, Srittau:  Done as "payment types accepted" --Lymantria (talk) 05:47, 24 May 2016 (UTC)

mains voltage/frequency

Withdrawn
Description residential voltage/frequency of electricity mains electricity (Q387400) Item electricity in voy:Template:Quickbar, Elektricitet in voy:sv:Mall:QuickbarCountry, possibly others in Template:Infobox country (Q14395495) countries items for voltage/frequency combinations ⟨ Japan ⟩ mains voltage/frequency search ⟨ 100V/50Hz ⟩ ⟨ Japan ⟩ mains voltage/frequency search ⟨ 100V/60Hz ⟩ w:Mains_electricity_by_country import from Wikivoyage or Wikipedia
•   Comment seems to be missing
--- Jura 06:10, 17 May 2016 (UTC)
•   Comment Please provide an example using real items. Also, the name is too vague. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:30, 17 May 2016 (UTC)
•   Support We have type of electrification (P930) but it's specific to railways. K7L (talk) 12:57, 17 May 2016 (UTC)
•   Support either as one combined property or as separate ones for mains electricity voltage and mains electricity frequency. Thryduulf (talk: local | en.wp | en.wikt) 14:18, 17 May 2016 (UTC)
• After reading the discussion below, I now have a preference for separate voltage property with a frequency qualifier as proposed by Nikki but I'm not opposed to a combined property if that is consensus. Thryduulf (talk: local | en.wp | en.wikt) 21:14, 24 May 2016 (UTC)
•   Support as per Thryduulf, with a slight preference for a combined property like proposed here. --Srittau (talk) 15:27, 17 May 2016 (UTC)
•   Comment Why should this be single property using the item datatype (which would mean creating a load of items for all the possible combinations of voltage and frequency, as far as I can tell) and not two properties using the quantity data type? For example, "mains voltage" as a quantity (with volt (Q25250) as the unit) and frequency (P2144) as a required qualifier seems like it would work fine. en:Mains_electricity_by_country (linked from the proposal) even has voltage and frequency as separate columns, which would also suggest two separate values. - Nikki (talk) 19:35, 19 May 2016 (UTC)
• No answer so far so   Oppose as currently proposed. - Nikki (talk) 09:26, 24 May 2016 (UTC)
•   Oppose as defined; electrical voltage and electrical frequency should be separate. -- The Anome (talk) 10:16, 21 May 2016 (UTC)
• Why? Normally the combination is standardized. The items for each still can have the properties. Obviously, for Wikivoyage purposes, maybe we could just do ~110 and ~220.
--- Jura 11:34, 21 May 2016 (UTC)
• @Jura1: I think it is more natural to have two seperate properties and use the quantity datatype. I think that is a more structured way to deal with this subject than creating items 210V/50Hz, 220V/50Hz, 230V/50Hz, 240V/50Hz, etc. When seperated and with quantity datatype   Support, but   Oppose as proposed. Lymantria (talk) 05:49, 23 May 2016 (UTC)
• @Lymantria: What do you think to my suggestion above of a new quantity property for mains voltage with the existing frequency (P2144) as a required qualifier? It seems like the best solution to me because it stores the two values as quantities and connects them together, it's easy to set up constraints for it and it also encourages a single way to represent the data (two new properties would create multiple plausible ways to enter the data, e.g. two separate statements, the first as a qualifier of the second or the second as a qualifier of the first, whereas frequency (P2144) on a country doesn't make sense unless it's qualifying something else). - Nikki (talk) 09:26, 24 May 2016 (UTC)
•   Support per above.
--- Jura 07:50, 24 May 2016 (UTC)
• Given the new approach, changed to   Support for Nicki's proposal, per above. -- The Anome (talk) 12:37, 24 May 2016 (UTC)
•   Support for the new approach. --T.seppelt (talk) 07:56, 25 May 2016 (UTC)

electrical plug type

Description plug type in use AC power connector (Q215292) Item electricity in voy:Template:Quickbar, possibly others in Template:Infobox country (Q14395495) countries items for plug types w:Mains_electricity_by_country import from Wikivoyage or Wikipedia
•   Comment seems to be missing. Related to previous proposal (voltage/frequency)
--- Jura 06:10, 17 May 2016 (UTC)
•   Comment Please provide an example using real items. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:30, 17 May 2016 (UTC)
•   Support. I've added real examples above. The en.wp articles at least tend to be very broad covering several concepts, and the linked wikidata items are often very bare bones so some work is needed to ensure that all types of plug socket have individual items described appropriately. Thryduulf (talk: local | en.wp | en.wikt) 14:30, 17 May 2016 (UTC)
• The US one is an actual one. It's just that we may have to create the items.
--- Jura 14:45, 17 May 2016 (UTC)
•   Support Useful property. --Srittau (talk) 15:26, 17 May 2016 (UTC)
•   Support. Thierry Caro (talk) 10:57, 20 May 2016 (UTC)
•   Support A useful property. -- The Anome (talk) 10:17, 21 May 2016 (UTC)
• @Jura1, Pigsonthewing, Thryduulf, Srittau, Thierry Caro, The Anome:   Done --Lymantria (talk) 16:47, 24 May 2016 (UTC)

emergency phone number

Description national or local emergency phone numbers emergency telephone number (Q694554) Item emergencies in voy:Template:Quickbar, possibly others in Template:Infobox country (Q14395495) countries items for emergency phone numbers US → 9-1-1 (Q533806) w:List of emergency telephone numbers import from Wikivoyage or Wikipedia
•   Comment seems to be missing
--- Jura 06:10, 17 May 2016 (UTC)
•   Comment Please provide an example using real items. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 17 May 2016 (UTC)
•   Support K7L (talk) 13:06, 17 May 2016 (UTC)
•   Support. Thryduulf (talk: local | en.wp | en.wikt) 14:31, 17 May 2016 (UTC)
•   Neutral In general a good idea, but I am not totally convinced about using an item datatype, instead of simple string one. --Srittau (talk) 15:25, 17 May 2016 (UTC)
• @Jura1: Both phone number (P1329) and P1244 (P1244) are proposed for deletion. The proposed property should be subproperty of either one that is kept. Once a decision is taken, we should have this one as its subproperty, of course with the same datatype. So this one should be   On hold until that decision. Lymantria (talk) 08:42, 24 May 2016 (UTC)
• I don't think this is related: the proposal is for item datatype.
--- Jura 08:45, 24 May 2016 (UTC)
• I see. Lymantria (talk) 10:37, 24 May 2016 (UTC)
•   Support per above.
--- Jura 08:45, 24 May 2016 (UTC)

@Jura1, Thryduulf, K7L:  Done --Lymantria (talk) 10:51, 24 May 2016 (UTC)

weather

Not done
Description State of the atmosphere at a specific moment weather (Q11663) Item Mostly for outdoor event (Q23899575) A set of new items that would include such things as 'sunny weather', etc. 2005 Tour de France, Stage 21 (Q446106) → new 'rainy weather' item
Motivation

Any outdoor event (Q23899575) is determined by the weather (Q11663), that might have a great impact on its organization and its outcome, for instance. This new property would help us store data about the state of the atmosphere at a specific event, which is often documented, when relevant, by the media that deal with that event. Thierry Caro (talk) 06:08, 22 April 2016 (UTC)

Discussion
•   Oppose This seems far too vague. In the example given, the TdF lasts over many days, during which the weather is often changeable. In any case, for a given date and region weather information should only be stored once (and is available online), we don't need to store it for each event. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 22 April 2016 (UTC)
Comment. Do you suggest that such data should be stored by items such as 21 June 1964 (Q2546782), with location (P276) and a new property for the specific hour as qualifiers? Well, maybe will we have some day such a comprehensive set of items, ready to be queried for any given place and hour, but for the moment it seems much more reasonable to simply store it in the very specific events that we already have items for and care about. Thierry Caro (talk) 23:08, 24 April 2016 (UTC)
•   Oppose Proposed values are a set of items to be created, but should be a set of values based on existing and reliable criteria. Also: Some events have a longer duration and weather conditions may vary during it. Lymantria (talk) 15:13, 25 April 2016 (UTC)
•   Weak oppose In certain cases, such as for transportation accidents and incidents, the weather is often a significant factor either in terms of the cause or the effect, so there is value in being able to record that - and it is already possible using has immediate cause (P1478), has cause (P828) and has contributing factor (P1479) with items like fog (Q37477) and heavy rain (Q18447212). For aviation incidents, a property to store the relevant METAR (Q476773) would be good (although this ideally would be proposed by someone more familiar with them than me). Wind speeds can be relevant to some athletics records, but that would be best recorded by a specific property (again missing afaict). I'm not sure how a general "state of the weather" property can be useful beyond this? Thryduulf (talk: local | en.wp | en.wikt) 18:49, 25 April 2016 (UTC)

Not done Unsufficient support. Lymantria (talk) 20:29, 3 May 2016 (UTC)

Sports records

Record or record progression

Description links to item on the record or record progression record (Q1241356) Item Record or record progression search ⟨ Q1055256 ⟩ Record or record progression search ⟨ Q25891 ⟩

Olympic record

Withdrawn
Description Officially recognized best performance during Olympic Games Olympic record (Q1432032) Quantity Olympic record search ⟨ 53.00 second (Q11574) ⟩Record holder search ⟨ Q463457 ⟩sex or gender (P21)   start time (P580)   ⟨ 2 aug 2012 ⟩

Record holder

Withdrawn
Description Holder of record, to be used as a qualifier with propoerty record. Inverse property of record held (P1000). Item human (Q5), group of humans (Q16334295) one hour run (Q2164200) → Gebrselassie Haile (Q171500)
Motivation

With the upcoming Olympic Summer Games, most likely there will be a fair portion of interest in sports events. Currently there is the possibility to add personal best (P2415) and record held (P1000) to items on individual sport persons, but to events it is not possible to add the most important records. The examples above give some indication of qualifiers that could be used, to fill in several parameters for the records. The qualifier "record holder", in essence inverse of record held (P1000), is currently missing and I propose to add that one. I have not yet proposed an additional "generic" property like "area record" in which continental, national and regional records could be added. It migth be an idea for the future. Lymantria (talk) 10:29, 26 April 2016 (UTC)

Discussion

@Thierry Caro, Edgars2007, Thryduulf, AmaryllisGardener: I drasticly changed the proposal after Thierry Caro's comments and withdrew two of the three. Please, let me know what you think of it. Lymantria (talk) 12:13, 7 May 2016 (UTC)

•   Comment now it looks like you are attempting to store links to lists at Wikipedia with lists of records. Shouldn't we atttempt to store the record itself on the item of the discipline?
--- Jura 12:25, 7 May 2016 (UTC)
•   Comment I'm not sure that I fully understand what exactly is being proposed now, so I have withdrawn my support. If and when it becomes clearer to me I'll either support or oppose, but for now I'm not comfortable saying either. Thryduulf (talk: local | en.wp | en.wikt) 15:10, 7 May 2016 (UTC)
• @Thryduulf: The new proposal is about linking items about discipline and (some) record list [... article at Wikipedia]. The real thing (addition of records themselves) happens in other items. --Edgars2007 (talk) 15:16, 7 May 2016 (UTC)
• Where would "53.00 second" (from the withdrawn proposal) go and how would that be linked from an item that has the proposed property?
--- Jura 15:26, 7 May 2016 (UTC)
• Not anywhere at this moment. Therefore indeed "record holder" would still make sense, but also something like "performance". My withdrawal of record holder was a bit hasty indeed, but I agree with the point Thierry Caro made, that records should be in a seperate item.... For this record item I will make new proposals soon. Lymantria (talk) 05:32, 9 May 2016 (UTC)
• New proposals are ready, see below

Records (2)

Record holder

Withdrawn
Description Holder of record. Inverse property of record held (P1000). Item records or record progression lists

Performance

Withdrawn
Description Result in a sports event Quantity records or record progression lists search ⟨ Q1189 ⟩ search ⟨ 9.58 second (Q11574) ⟩start time (P580)   ⟨ 19 August 2009 ⟩
Motivation

In stead of listing records at the item about disciplines, as I suggested earlier in my withdrawn proposals above, they should be listed at items on the records itself.

My proposal is to have both as full standing properties, not one a qualifier for the other.

If record holder is set as a qualifier of performance, the same name could appear several times, if an athlete sets several records. Or if the record was equaled a couple of times there are several start time (P580) qualifiers on one property.

Example 1:

<performance> search ⟨ 10.6 second (Q11574) ⟩
start time (P580)   ⟨ 6 July 1912 ⟩
end time (P582)   ⟨ 23 April 1921 ⟩
<record holder> search ⟨ Q954517 ⟩
start time (P580)   ⟨ 6 July 1912 ⟩
end time (P582)   ⟨ 23 April 1921 ⟩
<record holder> search ⟨ Q545823 ⟩
start time (P580)   ⟨ 16 September 1920 ⟩

end time (P582)   ⟨ 23 April 1921 ⟩

If the performance is set as qualifier of the record holder, then it is hardly possible to add subperformances of a multi event discipline like decathlon (Q184654).

Example 2:

<record holder> search ⟨ Q1789 ⟩
start time (P580)   ⟨ 23 June 2012 ⟩
<performance> search ⟨  ⟩
start time (P580)   ⟨ 29 August 2015 ⟩
has part (P527)
<performance> search ⟨ 10.23 second (Q11574) ⟩
<performance> search ⟨  ⟩
has part (P527)

(More did not fit into {{Claim}}).

@Jura1, Thryduulf: I hope this is a clear substitution for the withdrawn property proposals. My apologies for the unclarity. Lymantria (talk) 13:40, 9 May 2016 (UTC)

Discussion
•   Oppose "performance" /   Weak oppose "record holder" as proposed. I think actually a world record should be a separate item to the progression of that world record as they are different concepts.
At any one time a world record is a single duration/distance/height/points total/weight (mass)/etc with a single point in time, a single holder (person or team), and (in some cases) other qualifying information (e.g. a relative wind speed for the long jump). Other information can be stored too (e.g. the location it was set, the event it was set during). All previous information becomes deprecated the instant a record is broken.
The world record progression is a list (or tabular data that we currently cannot store well) storing all the valid (and in some cases invalid) records with start dates and end dates. The old information is historical rather than deprecated.
In my opinion the item about the record holder should store, the event, the record and the point in time, e.g.
record held (P1000)
10.6 second search ⟨ 585 ⟩
6 July 1912 search ⟨ {{{7}}} ⟩
.
The item about the record should store, e.g. for men's 100m
⟨ 100m world record ⟩ record holder search ⟨ 1189 ⟩
duration (P2047)   ⟨ 9.58 second ⟩
start time (P580)   ⟨  16 August 2009 ⟩
end time (P582)   ⟨ no value ⟩
and separately
⟨ men's 100m world record ⟩ has list (P2354)
.
We don't I think need a separate "performance" property as existing properties duration (P2047), length (P2043), height (P2048), mass (P2067), number of points/goals/set scored (P1351) can be used in all cases without ambiguity. Thryduulf (talk: local | en.wp | en.wikt) 10:12, 10 May 2016 (UTC)
@Thryduulf: I agree with your observations on performance, I think that property is not needed. What you tell about a world record (or an area, Olympic, nationa record for that matter) is not entirely correct. First, in a lot of cases equalling a world record is again a world record. Second, I see the world record as a record as depending on time. In the course of time, the record becomes faster/higher/more points ... So, in essence, world record progression and the world record are the same thing. An item on only the actual world record would in my eyes be unstable and a bit weird as well. Lymantria (talk) 05:30, 23 May 2016 (UTC)