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)
@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)
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. --- Jura10: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. --- Jura10: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. --- Jura09: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)
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)
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)
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)
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
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 TomT0m / talk page15:04, 30 July 2015 (UTC)
CommentList 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. --- Jura11: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 TomT0m / talk page09: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. --- Jura09: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 TomT0m / talk page13: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. --- Jura07: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 TomT0m / talk page10: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 TomT0m / talk page21: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. --- Jura07:20, 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)
@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
... 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 TomT0m / talk page08:10, 10 August 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)
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)
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)
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)
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 by2003:45:4f71:7301:d515:92cf:a661:d7f8 (talk • contribs) at 11 feb 2016 05:03 (UTC).
Support make sense. But the variables in the formula will have to be linked somehow to the quantify they measure. For example in a cube, we will have to have a
Comment I will support that kind of property for volume and area but we need to find a way to define the variables of the formula. Perhaps we should create a help page and provide a list of general variable used in Wikidata formula. But without that we will have some problem to propose an unique way to write formulas. Snipre (talk) 19:26, 27 March 2016 (UTC)
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.
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. --- Jura05: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)
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)
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.
Not used as a Template:Listing (Q14330485) listing field; setting this 'true' should suppress display of the entire template or display an error.
Allowed values
true, false, (blank)
Example
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)
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)
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. --- Jura12: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)
Why? I think I know why, but you need to explain why you think we need to track this information using a metaproperty. --Izno (talk) 16:28, 26 April 2016 (UTC)
Question@Jura1: Are these examples of what your mean:
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. --- Jura10:17, 5 May 2016 (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
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.
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)
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
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)
HowLongToBeat is an online polling database for determining video game completion time in various styles. Unlike other media such as books, film, and television, there is no algorithm for determining game play time. Judging by image filenames, the database was seeded with Wikipedia data after its launch (2011). Dispenser (talk) 15:13, 22 January 2016 (UTC)
Matching items to HLtB can be automated to an extend, much the data was seeded from Wikipedia and newer games are "manually" imported from Steam. In the future, I think they'll likely switch to using Wikidata. :-)
You don't need a account to submit completion times, nor need to verify ownership. That and its better design is likely what let it rise above competitors gamelengths.com and trueachievements.com (Xbox est.). The increase popularity means more samples which means more accuracy (Wisdom of the crowd effect, Networking effects). The publicly available raw poll data is not copyrightable (IANAL, Sweat of the brow doctrine).
"1207 - 1209, XIV - XVI cent., 1699, rebuilded in 1991 - 2000"
Source
WLM monuments lists in Wikipedia
Motivation
Currently Latvian, Russian and Ukrainian communities are in progress of migration WLM monuments from lists to Wikidata. We have very comprehensive and complete monument lists, so we can't afford to lose the information from these lists. Inception and reconstruction time period often presents in the lists, espesially for architecture monuments and we can't replace such time periods by inception (P571) because its ambiguity and restrictions - inception (P571) forbids more than one date. Voll (talk) 17:42, 23 April 2016 (UTC)
Can we replace it by datetime value? Or maybe use begin date and end date. It may be useful for comparison or sorting (for example to list older monuments first).--Ahonc (talk) 19:31, 23 April 2016 (UTC)
Firstly, we may separate create and rebuild date, secondly, 1207, 14 century, 1209, 16 century, 1699, 1991, 2000 have their own WD elements and we may use WD elements instead of text. So we may have problems only with dates like 1st half of 19th century. As alternative we may use two properties: string-type and datetime-type, first will use for showing, second for comparison and sorting.--Ahonc (talk) 21:09, 23 April 2016 (UTC)
I am sorry, but I haven't got the idea. How can I realize my example string: "1207 - 1209, XIV - XVI cent., 1699, rebuilded in 1991 - 2000" (and it is not the hardest example) using the datetime value? --Voll (talk) 20:51, 23 April 2016 (UTC)
It would need to be two separate properties, one for the begin date and one for the end date (e.g. "construction started" and "construction finished"). - Nikki (talk) 21:54, 23 April 2016 (UTC)
I completely agree (although as I pointed out above, it would need to be two properties). Wikidata is about structured data, a text string is definitely not the right solution here. - Nikki (talk) 21:54, 23 April 2016 (UTC)
Strong oppose to storing this as a text value. If it really needs to be added to Wikidata right now, this shows how the example string could already be entered using significant event (P793) (we could create an item for rebuilding, I used "building restoration" for now). I have no objections to creating new date properties (probably easier to query, although significant event (P793) makes it easier to pair dates). - Nikki (talk) 10:16, 24 April 2016 (UTC)
Support, yes, we need it for monument lists. Agree, that we can also use inception (P571) for querying (that was my first idea). Somewhere in future, we can convert this proposed property into good, queryable property. --Edgars2007 (talk) 07:54, 24 April 2016 (UTC)
Why create a property to only be used temporarily? It will only create more work for everyone. It's more work for us, converting the data, and more work for local projects, converting their templates to use the first property, then adapting their templates to support both methods after we start to replace the property (which could take a while, P357 (P357) is still not finished a year and a half later) and then changing it again to remove the unnecessary code once we delete the old property. - Nikki (talk) 10:16, 24 April 2016 (UTC)
Comment Dear friends, please remember my original request: governmental institutions often in their databases describe heritage monument history in such strange (for WD) way: "1207 - 1209, XIV - XVI cent., 1699, rebuilded in 1991 - 2000". They just marked milestones without information what happened in this milestones. What happened in 1699 __we don't know__ - abbey could built new belfry or could rebuit old church - so we can't guess - it was inception or reconstruction? In my small country (2 mln inhabitants) we have about 700 described cases (some cases are more complicated than mentioned one) - every tenth monument. I think we will have tens of thousands parameters with described ambiguity in Russia. I am going to import all information from lists to Wikidata, so if I throw these parameters away, I can't convince the WLM community to replace old list with generated ones and store all the data in Wikidata only. Yes, we can discuss about new properties for time of reconstruction and so on, but my request was about storing in Wikidata information from governmental heritage monuments lists. Thank you. --Voll (talk) 10:35, 24 April 2016 (UTC)
CommentNikki, thank you so much, I am thinking a lot about your questions and proposals and now I see that my request was wrong ab initio.
I need, in fact, something like "Monument construction milestones in heritage register" and this new property should be used only as heritage designation (P1435) qualifier. Should I create new request or change information in this request?
Oppose if it is a monolingual text, would support if it would be a list of dates. Firstly, WLM lists can be multilingual (e.g. WLM lists for Crimea are available in Ukrainian and in Russian), secondly, I really don't like the idea of storing dates as text — NickK (talk) 15:25, 27 April 2016 (UTC)
Currently Latvian, Russian and Ukrainian communities are in progress of migration WLM monuments from lists to Wikidata. Every monument should be linked to the heritage monuments list because we are planning to support heritage monuments lists in Wikipedia in the future too. We can't use list of monuments (P1456) because it creates link from administrative territorial entity to heritage monument list and have some specific constraint violations. Voll (talk) 17:48, 23 April 2016 (UTC)
Comment Why can we not get this value by administrative unit? Basilica of the Assumption is situated on AGlona village, which is part of Aglona Parish, which is part of Aglona municipality. Then Basilica is part of Aglona municipality, then it is part of list of monuments of this municiplaity. That's why this property is redundant. // Почему нельзя получить это значение по административной единице? Если Аглонская базилика расположена в селе Аглона, которое находится в Аглонской волости, которая в свою очередь в Аглонском крае, значит базилика в Аглонском крае, а значит она является частью списка памятников этого края. Соответственно это свойство избыточно.--Ahonc (talk) 19:27, 23 April 2016 (UTC)
I think we shouldn't create two ecosystems for monuments lists (one in Wikidata and second in Wikipedia). We should tie these together as much as possible, otherwise we will lose for Wikidata all these communities which are working for lists maintaining and "Wiki loves monuments" contest. If we can't create strong connection between Wikidata and WLM/lists each community will be fine on its own, but it is not enough, if we are going to create mighty heritage monuments database. --Voll (talk) 21:29, 23 April 2016 (UTC)
Manually maintaining lists is a bad idea, regardless of where it's done. What exactly are you trying to achieve, and why can't you use the criteria used to create the list to find the relevant items? - Nikki (talk) 22:43, 23 April 2016 (UTC)
I'm going to say Oppose until someone can explain why the list can't be generated from the criteria used for creating the list. I'm not sure exactly what people are referring to with "smart queries", but filtering by the first letter and/or including multiple administrative entities is easy to do with SPARQL (and SPARQL queries is how the development team plan to support lists, from what I've heard). - Nikki (talk) 09:30, 24 April 2016 (UTC)
Thank you for the question, Nikki. As you know many national communities create own heritage monument lists for WLM contest. For some countries (Ukraine, Italy, etc,) these lists are the only place where you can find information about monuments, because government doesn't collect this information and volunteers collect it from municipalities. In other countries (Russia for example) WLM community improved the lists and they contain a lot of information additionally to common governmental data. In my opinion we can't afford to lose the information collected by communities year by year.
So my plan is: import all information from lists to Wikidata (I am writing a bot for this task), create tool (or extend Listeria functionality) for generation the lists from WD, generate these list alongside to hand made lists (I need requested property for this step), and only then ____convince____ the community to replace old list with generated ones and store all the data in Wikidata only. It will take many months, many times bot will be running and all this time I should have links between old lists and monuments in Wikidata and requested property will do this job. --Voll (talk) 09:56, 24 April 2016 (UTC)
It is not only option, it is second step in my project ;-). But I prefer use current list division, because WLM volunteers many years divide own lists in this way. I will make first test project in Latvian community, so it will be possible for WLM volunteers and Wikidata editors check result and correct tasks for other communities. --Voll (talk) 10:03, 24 April 2016 (UTC)
I don't think so, because IMHO has list (P2354) is using in classes mostly, it is distinct and inverse for the most part. If we are thinking about existing property, then we can use list of monuments (P1456), if we allowed "cultural property" type in addition to "area" type. Something like "link to the list of heritage monuments connected (related) to the subject (area or property)". --Voll (talk) 19:09, 26 April 2016 (UTC)
@Srittau: I'm not sure I understand this proposal, but is this really a wikimedia list ? @Voll: Could you be a little more specific about the kind of list you are planning to build ? For example, I see
statement which seems incorrect to me : we're mixing a class of documents (an outside world concept) with a wikimedia list, which is something we're usually trying to avoid. Secondly, please see Help:Classification, I think you're trying to use the concept of a "list" as the concept of a "class" and that actually to link the class of monuments to the class (of all "classified" ;) monuments) with instance of (P31). Which is something I'm trying to avoid as we're building A LOT of specific properties and classification systems for very little gain. author TomT0m / talk page09:38, 11 May 2016 (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)
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 liabilitiesMcnabber091 (talk) 01:18, 21 December 2015 (UTC)
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)
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)
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)
@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)
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.
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.
@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)
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)
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)
@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 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
@T.seppelt: can you clarify which other datatype you think applies and why you consider Wikivoyage formatting guidelines "unstructured". --- Jura21: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). --- Jura06: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. --- Jura06: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)
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:
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)
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. --- Jura15: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 edits12: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. --- Jura15: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 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 edits12: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)
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)
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. --- Jura11:41, 21 May 2016 (UTC)
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.
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).
http://www.openstreetmap.org/node/$1 or http://www.openstreetmap.org/way/$1
Comment. Used in Wikivoyage en français to link to OpenStreetMap POI's; not available in all Wikivoyage languages at the present time. A "node" appears on the map as an icon or single point, a "way" is typically a building or outline. K7L (talk) 01:24, 15 May 2016 (UTC)
Oppose Previously rejected, OSM does not offer any stable identifiers. OSM provides wikidata=* though to link to us. --Srittau (talk) 18:10, 16 May 2016 (UTC)
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)
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)
⟨ NATO (Q7184) ⟩<leading position in this organisation> [[Special:Search/Property:<leading position in this organisation>|Search]]⟨ Q6501749 ⟩ <position holder> [[Special:Search/Property:<position holder>|Search]]⟨ Q57665 ⟩ start time (P580)⟨ 1 okt 2014 ⟩
⟨ Stanford University (Q41506) ⟩<leading position in this organisation> [[Special:Search/Property:<leading position in this organisation>|Search]]⟨ Q2114175 ⟩ <position holder> [[Special:Search/Property:<position holder>|Search]]⟨ Q6231954 ⟩ start time (P580)⟨ 1 sep 2000 ⟩
⟨ University of California, Berkeley (Q168756) ⟩<leading position in this organisation> [[Special:Search/Property:<leading position in this organisation>|Search]]⟨ Q61061 ⟩ <position holder> [[Special:Search/Property:<position holder>|Search]]⟨ Q7025311 ⟩ start time (P580)⟨ 1 jun 2013 ⟩
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)
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. --- Jura10: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. --- Jura12:02, 13 May 2016 (UTC)
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)
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)
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)
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)
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)
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(s) (P527) qualifiers as appropriate. e.g.
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". --- Jura07: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)
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)
* {{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."
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). --- Jura06: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)
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)
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]" --- Jura18:31, 23 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)
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)
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. --- Jura11: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. 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)
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)
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 edits11:14, 22 April 2016 (UTC)
Comment. Do you suggest that such data should be stored by items such as June 21, 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)
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)
Support. Yes, this will be useful. In examples I would also add something like "competition", which can later also be used in other cases. --Edgars2007 (talk) 10:41, 26 April 2016 (UTC)
Comment. I was thinking about this yesterday and come to conclusion, that at least in case of world records we could store that directly at record holder's item (in "personal best") with some kind of qualifier "instance of (P31) → world record (Q688615)". That should be enough for querying. Agree, that for other cases this approach might not work, because not every Olympic record is personal best for that particular athlete and probably there are many cons for this idea. Just loud thinking. --Edgars2007 (talk) 04:42, 6 May 2016 (UTC)
Hmm, indeed, record held (P1000) has almost 50% constraint violations.... I must say that in my opinion the reference to a record progression in stead of a discipline is a bit unnatural, or even ugly. But that is my opinion. Lymantria (talk) 11:52, 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? --- Jura12: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? --- Jura15: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)
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.
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).
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.
@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)
Comment seems to be missing. Related to previous proposal (voltage/frequency) 
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)
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)
Oppose Use described by source (P1343) = Allgemeine Deutsche Biographie (Q590208) with stated in (P248) as qualifier, е.g. Heine, Heinrich (Q19958379) and Heinrich Heine (Q44403). This schema is used for linking in ruws (s:ru:ЭСБЕ/Гейне, Генрих: "ADB" link under header) and ruwp (w:ru:Гейне, Генрих: "Allgemeine Deutsche Biographie" link at the end). -- Sergey kudryavtsev (talk) 04:07, 21 October 2015 (UTC)
Not done No support. Lymantria (talk) 17:35, 9 May 2016 (UTC)
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Daniel Mietchen (talk) 01:15, 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)
⟨ blue ⟩
Done @Lymantria, Pasleim, TomT0m, Pigsonthewing: - ArthurPSmith (talk) 15:49, 5 May 2016 (UTC)
Not done No consensus. Lymantria (talk) 08:52, 7 May 2016 (UTC)
Question@Jura1: Are these examples of what your mean: and ? Shouldn't there be a constraint check on the precision as well? Lymantria (talk) 20:14, 2 May 2016 (UTC)
Strong oppose to storing this as a text value. If it really needs to be added to Wikidata right now, this shows how the example string could already be entered using significant event (P793) (we could create an item for rebuilding, I used "building restoration" for now). I have no objections to creating new date properties (probably easier to query, although significant event (P793) makes it easier to pair dates). - Nikki (talk) 10:16, 24 April 2016 (UTC)
⟩ 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 ⟩
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)
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)
On hold until that decision. Lymantria (talk) 08:42, 24 May 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)