Wikidata:Property proposal/Attention needed

From Wikidata
Jump to: navigation, search

This page transcludes property proposals that are in need of attention for some reason. To be listed here proposals must be open and generally should not have a currently active, productive discussion that is likely to lead to consensus. Examples of when a listing here is appropriate include:

  • The proposal was initiated more than 7-10 days ago and has received no or very few comments
  • The proposal has a clear consensus for creation and has been marked ready for several days
  • The discussion needs input from more people before consensus can be reached
  • The discussion has stalled without a clear consensus
  • The proposal needs reassessing after significant changes have been made, but this has not happened after several days (pinging users who commented earlier is usually recommended before listing here)

Property creators should also continue to monitor Category:Properties ready for creation as not all properties ready for creation will appear here.

Closed and withdrawn proposals should be removed from this list to keep it clean, as may properties where an active discussion has (re)started following a listing. Any user acting in good faith, including the proposer, may add or remove a proposal but do not edit war about it. Please add new entries to the bottom of the list so the oldest listed are the most prominent.

At present the list is maintained manually although it is hoped that a bot will take over the routine management.

Current list[edit]

head coach of[edit]

   Under discussion
Description sports teams or clubs that the subject currently coaches or formerly coached
Represents coach (Q41583)
Data type Élément-invalid datatype (not in Module:i18n/datatype)
Template parameter "carrière entraîneur" in fr:Template:Infobox Footballeur, "managerclubX" in en:Template:Infobox_football_biography, "trainervereine" (or "trainer_tabelle") in de:Template:Infobox Fußballspieler, etc.
Domain Person
Allowed values Organisation
Example Alex Ferguson (Q44980)Manchester United F.C. (Q18656), Alex Ferguson (Q44980)Scotland national football team (Q34044)
Didier Deschamps (Q508711)Olympique de Marseille (Q132885), Didier Deschamps (Q508711)France national football team (Q47774)
Planned use import corresponding data from Wikipedia footballer infoboxes (as I've done last few months with member of sports team (P54))
Robot and gadget jobs B0ttle (talkcontribslogs), my bot
See also the same as member of sports team (P54), but for coaches and managers
Motivation

Hi. I explained what I want to do in Wikidata:Project_chat#how_to_tag_that_someone_has_worked_as_a_coach.2Fmanager_for_a_football_club.2Fteam. To describe coach career in Wikidata, there is no evident existing property (occupation (P106), member of sports team (P54) and employer (P108) each have their default). So Danrok (talkcontribslogs) invited me to ask the creation of a dedicated property. H4stings (talk) 09:07, 13 July 2016 (UTC)

Up: I am still interested. Face-smile.svg I wait for the conclusion of this page to start my work. Either this new property creation is validated, and I will use it tens of thousands of times. Or it is not granted, in this case I think I will use the member of sports team (P54) property with subject has role (P2868):association football manager (Q628099) as qualifier. H4stings (talk) 08:07, 18 September 2016 (UTC) & 15:37, 20 September 2016 (UTC)

Discussion
I don't see why the information has to be stored on the page of the manager. What's wrong with storing it at the club level? You can still write access the information via a query for an infobox. ChristianKl (talk) 19:31, 20 July 2016 (UTC)
@ChristianKl: there is no obligation, but it sounds simpler to me. Almost every manager is an old footballer, and we already store the player career data in the wikidata player element (with member of sports team (P54)). And in any Wikipedia page, both information (player and manager career data) appears in the infobox of the human being, not in the club one. --H4stings (talk) 07:59, 21 July 2016 (UTC)
When it comes to the term head coach it's not immediately clear that humans can't have head coaches like humans have teachers. This might be confusing for new users. If you want to model the side from the human than I think "hold position" already does the job. ChristianKl (talk) 08:06, 21 July 2016 (UTC)
  • Symbol support vote.svg Support. I guess there are enough people concerned for this to be useful. Thierry Caro (talk) 08:56, 12 August 2016 (UTC)
  • Symbol oppose vote.svg Oppose. I agree with Pigsonthewing, use position held (P39). Sjoerd de Bruin (talk) 07:33, 23 August 2016 (UTC)
  • Symbol support vote.svg Support. I believe that using position held (P39) would be unnecessarily cumbersome as it would require one to use modifiers every single time to show which teams the individual has coached/managed. Furthermore, I have yet to see any explanation as to why P39 is good enough. Indeed, that property appears to be political in scope. Perhaps someone can give me some reasons for why I should use P39. If we have no problem using member of sports team (P54) to list the teams an individual has played for, why is there a problem with storing managerial information on the page of the manager? Many sportspeople are far more famous as a manager than as a player, and it would be good for us to be able to document the organizations that they represented in that role. In a nutshell, I think it would be very helpful for those of us who edit sports items if we had this property. Lepricavark (talk) 11:19, 23 August 2016 (UTC)
  • Symbol support vote.svg Support. Very few items about coaches use P39, it's ambiguous for most editors and you can't think of it while editing. If we have member of sports team (P54), than we must have this one too and keep P39 for politicians or other jobs.Ionutzmovie (talk) 21:18, 6 September 2016 (UTC)
    • That "you can't think of it while editing" is not a good reason to create a property; the more overlapping properties we create, the harder it will be to figure out which to use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:04, 20 September 2016 (UTC)
  • Symbol oppose vote.svg Oppose Maybe the other way around.
    --- Jura 16:25, 19 September 2016 (UTC)
  • Symbol oppose vote.svg Oppose. I've reread this discussion and agree with Andy that position held (P39) does the intended job here. Thryduulf (talk) 14:47, 4 November 2016 (UTC)
  • Symbol support vote.svg Support. We have it in most Wikipedias, and if we put it in Wikidata we can automatically add to templates without using position held (P39), that would be good for presidents of sport teams, but not for a trainer, who can be in more that one team every year. The list of position held (P39) would be too long because most formats in Templates are using this for politicians, with different formatting. At the same time, one coach of any sport team could also be in a political charge during his life, and it would lead to misunderstood. -Theklan (talk) 22:57, 5 December 2016 (UTC)
  • Symbol support vote.svg Support To make it easier for Wikipedia to load this data via a template. ChristianKl (talk) 14:18, 24 January 2017 (UTC)

ITU prefix[edit]

   Not done
Description The International Telecommunication Union (ITU) allocates call sign prefixes for radio and television stations of all types
Represents ITU prefix (Q1344924)
Data type String
Domain countries, Organization
Allowed values Letter/number
Example
Source w:ITU prefix
Robot and gadget jobs No
Motivation

The International Telecommunication Union (ITU) allocates call sign prefixes for radio and television stations of all types. They also form the basis for, but do not exactly match, aircraft registration identifiers. These prefixes are agreed upon internationally, and are a form of country code. A call sign can be any number of letters and numerals but each country must only use call signs that begin with the characters allocated for use in that country. GZWDer (talk) 20:00, 10 July 2016 (UTC)

Discussion


  • Symbol support vote.svg Support, but datatype should be "external-id". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:53, 10 July 2016 (UTC)
  • Symbol support vote.svg Support as external-id per Andy. Thryduulf (talk) 23:03, 10 July 2016 (UTC)
  • Pictogram voting comment.svg Comment Trying to grasp the system from w:ITU prefix and http://www.itu.int/online/mms/glad/cga_callsign.sh?lng=E I understand that call-signs are up to three digits, and if a country has a complete set A-Z allocated, then it may use 0-9 as well in that position. The proposal is to add only the fixed parts of the allocation. Okay with me, but I don't think that "external identifier" suits here as @Pigsonthewing, Thryduulf: suggest. Support for string datatype. Lymantria (talk) 22:13, 3 August 2016 (UTC)
  • Symbol support vote.svg Support as string, GA candidate.svg Weak support as external-id. --Srittau (talk) 23:03, 19 August 2016 (UTC)
  • @Thryduulf, Pigsonthewing: Would you object to this property being created as String as proposed and as favored by Srittau and Lymantria? ChristianKl (talk) 12:26, 9 September 2016 (UTC)
    • Yes, without explanation as to why external identifier is not appropriate here. Thryduulf (talk) 12:33, 9 September 2016 (UTC)
      • @Lymantria: why do you think this is not suitable for an external ID datatype? Thryduulf (talk) 14:54, 14 September 2016 (UTC)
        • That is because a part of a prefix IMHO is not an identification code. "IS3" for instance is a prefix, while "I" is the proposed identification code, appointed to Italy. While codes are far from unique, some are ambiguous (China!). Lymantria (talk) 15:06, 14 September 2016 (UTC)  – The preceding unsigned comment was added by Lymantria (talk • contribs).
          • @Lymantria: why does it being a prefix stop it being an identifier? I'm also not clear why you regard this as ambiguous, nor why that makes it unsuitable for an external identifier but suitable for a string? Thryduulf (talk) 14:35, 4 November 2016 (UTC)
      • @Srittau: do you have an opinion regarding the datatype? Thryduulf (talk) 14:54, 14 September 2016 (UTC)
    • It's an identifier, and it's not internal to Wikidata, so yes, I would. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:02, 9 September 2016 (UTC)
  • Pictogram voting comment.svg Comment I've removed the "ready" status as there is no consensus currently regarding the datatype.
  • Symbol oppose vote.svg Oppose I think this is the wrong approach. Why not create a wikidata item for each identifier, make it an instance of ITU prefix (Q455644) and provide the appropriate country (P17) statement. That way these are not cluttering up the country items but they are still linked to the country so that can be discovered easily enough. And if there are other appropriate geo-location properties associated with particular prefixes they can be added also. ArthurPSmith (talk) 20:22, 4 November 2016 (UTC)
  • Symbol oppose vote.svg Oppose with datatype string/ext-id. Reason: There are too many ITU prefixes per country and it would clutter our items. Alternative: use tabular data when the datatype is ready.--Micru (talk) 15:42, 6 January 2017 (UTC)
  • @GZWDer, Pigsonthewing, Thryduulf, Lymantria, Srittau, Lymantria:

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Azertus
Pintoch
Jsamwrites
Pictogram voting comment.svg Notified participants of WikiProject Informatics Is there someone for which the solution that ArthurPSmith proposes of creating individual items for the individual codes and linking those with country (P17) doesn't work? ChristianKl (talk) 11:11, 29 March 2017 (UTC)

  • I notice that some of the entities assigned ITU prefixes are not countries (eg. United Nations) so perhaps owned by (P127) would be better to describe the relationships. Or a new property for "assigned to" (that could be used for other cases like this? ArthurPSmith (talk) 20:31, 29 March 2017 (UTC)
  • @GZWDer, Pigsonthewing, Thryduulf, Lymantria, Srittau, Lymantria: Given suggested alternative solution and no opposition to it, I mark this as "Not done". ChristianKl (talk) 13:25, 15 April 2017 (UTC)

type of electricity transmission[edit]

   Under discussion
Description medium by which electricity is transmitted
Represents type of electricity transmission (Q23012297)
Data type Item
Domain instances of railway electrification system (Q388201), possibly others in the future
Allowed values instances of type of electricity transmission (Q23012297)
Example 15 kV AC railway electrification (Q1415234)overhead lines (Q110701)
Motivation

Currently I don't see a sensible way to connect the type of electrification system with its intended type of transmission. This makes the use of type of electrification (P930) harder and more ambiguous, since it actually has to refer to two fairly different things at the moment: the electrification type and the transmission type, although the former implies the latter. If this proposal is accepted, we should remove railway electrification system (Q388201) from the domain and type of electricity transmission (Q23012297) from the allowed values of type of electrification (P930). --Srittau (talk) 22:09, 7 March 2016 (UTC)

Discussion
  • Symbol support vote.svg Support. While things like 25kv AC are exclusively used with overhead lines, 750v DC is commonly used with both overhead lines (e.g. on tramways) and third rail (e.g. south east England), and I'd be surprised if that were the only dually used voltage. Thryduulf (talk: local | en.wp | en.wikt) 23:38, 7 March 2016 (UTC)
  • How does this relate to the #Railway electrification system proposal, above? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:19, 8 March 2016 (UTC)
    • This proposal tries to "complete/fix" the existing structured way to describe railway electrification type of electrification (P930). The proposal above suggest a string, i.e. a non-structured way, which I am opposed to. --Srittau (talk) 18:41, 8 March 2016 (UTC)
  • Symbol oppose vote.svg Oppose It seems this can use uses (P2283) simply enough: Josh Baumgartner (talk) 19:42, 8 March 2016 (UTC)
    • uses (P2283) - while better than nothing - is a bit unspecific for my taste. I can imagine other things than just a transmission type that a certain elelctrification system "uses". This property would be a sub-property, though. --Srittau (talk) 10:14, 9 March 2016 (UTC)
      • Indeed, electrification systems "use" substations, breakers, power control systems, etc, all of which will have specific designs. See also my comment about multiple transmission systems for some voltages. Overhead lines, third rail (top, side and bottom contact) and fourth rail are common, conduit systems were used historically (dunno about contemporarily) and there are several different new types of electricity transmission being used/trialled on tramways currently. We need some way to note this and I don't think uses (P2283) is right way to do that. Thryduulf (talk: local | en.wp | en.wikt) 21:53, 6 June 2016 (UTC)
  • Symbol oppose vote.svg Oppose as Joshbaumgartner. --Averater (talk) 08:12, 17 August 2016 (UTC)
    • @Averater, Joshbaumgartner: Why do you think that uses (P2283) can be used when I and Srittau have explained why we think it is too generic? Thryduulf (talk) 11:02, 17 August 2016 (UTC)
      • It is possible touse several things. Nothing weird there. I am not convinced why this use is so different from any other. Are there special properties for substations, breakers, power control systems, etc? --Averater (talk) 15:30, 17 August 2016 (UTC)
        • I'm not aware of either the existence of properties for those items, but that doesn't necessarily mean they aren't needed (I don't know enough about the subject to know). However the medium by which electricity is transmitted is a very fundamental element of electricity distribution, particularly on railways where it impacts what trains can run, how quickly they can run, requirements for lineside structures, etc, etc. Srittau's comment above explains this as well. Thryduulf (talk) 19:42, 17 August 2016 (UTC)
  • Symbol support vote.svg Support uses (P2283) is too vague for this context. It could easily be a sub-property of it, but the electric transmission system is significant enough for its own property. -happy5214 02:03, 25 August 2016 (UTC)
  • Symbol support vote.svg Support I don't like using uses (P2283) for many different things. I'm in favor of having this property well specified for the purpose. ChristianKl (talk) 11:48, 22 October 2016 (UTC)
  • Symbol support vote.svg Support Kindly useful. --Liuxinyu970226 (talk) 08:46, 24 November 2016 (UTC)
  • Symbol oppose vote.svg Oppose this really doesn't seem sufficiently important to need its own property - and it opens the door to many more similar things if this is approved (from above discussion). From the diagram above I don't understand why this can't be solved just with two subclass of (P279) statements and appropriate items. ArthurPSmith (talk) 16:33, 24 November 2016 (UTC)
    @ArthurPSmith: Then how do we specify Hokuriku Shinkansen (Q1037409), where it has both 50 Hz and 60 Hz part? --Liuxinyu970226 (talk) 05:15, 26 November 2016 (UTC)
  • I don't see that this property proposal has anything to do with how to specify several different types of transmission. You could specify that with multiple claims, one for the 50 Hz and one for the 60 Hz part, or you could specify it by creating an item for the special combined 50 Hz + 60 Hz system if that made sense. ArthurPSmith (talk) 20:59, 26 November 2016 (UTC)

average yearly temperature[edit]

   Under discussion
Description temperature calculated by averaging the minimum and maximum daily temperatures over 30 years in a certain place
Data type Quantity
Domain instances of geographic region (Q82794) and instances of, recursively, its subclasses
Allowed values from -400 (minimum using degree Fahrenheit (Q42289), near to the absolute zero (Q81182)) to 350 (maximum using kelvin (Q11579), perhaps could be reached inside a volcano)
Allowed units the same as temperature (P2076), that is, degrees Celsius (Q25267), kelvin (Q11579) and degree Fahrenheit (Q42289)
Example Zaragoza (Q10305) → 15.5 °C (according to aemet.es, the Agencia Estatal de Meteorología (Q2826727))
Planned use firstly, importing data for some Spanish municipalities from the Agencia Estatal de Meteorología (Q2826727)
Robot and gadget jobs creating and regularly updating a world map (Q653848) that represents how these values are distributed across the planet
See also temperature (P2076), Köppen climate classification (P2564)
Motivation

Wikidata is lacking in climate data, and the average yearly temperature is a particularly relevant measurement. abián 15:57, 28 August 2016 (UTC)

Discussion
I think that we have a problem.
  1. If we only create a property for the average monthly temperature, we won't be able to get the average yearly temperature if we don't have well-defined data of all months. In some cases, we know the average yearly temperature but not the average monthly one.
  2. If we only create a property for the average yearly temperature, we'll never be able to know the average monthly temperature.
  3. If we create both properties, we should never use both for the same Wikidata item. This situation could be controlled using a {{Constraint:Conflicts with}}.
There isn't a perfect solution. If we usually know the average monthly temperature, I would say 1. If we usually know the average yearly temperature but hardly ever the average monthly one, I would say 2. And, if there's no a "usual" situation, I would say 3. If I would have to choose right now, without being able to talk or to find out about this, I would choose 3. --abián 20:37, 28 August 2016 (UTC)
  • Average monthly temperatures are way more informative than plain yearly average. Whether we create a specific property for this or not, we should think about how bring here monthly averages too, creating a coherent model including the later ones too.
1) Having a specific property for yearly averages and using generic temperature (P2076) 'qualified' with determination method (P459) for the monthly ones would be pretty awkward.
2) Having "average yearly temperature" and "average monthly temperature" using somehow the month as qualifier would make a little more sense. I don't know.
3) Having "average yearly temperature", "average january temperature", and "average february temperature" and... -> no.
Regardless all that, qualifiers as start time (P580) or end time (P582) should be added too. Strakhov (talk) 20:09, 28 August 2016 (UTC)
Option 2 makes much sense. :-) --abián 20:49, 28 August 2016 (UTC)
month of the year (P2922) would work as the qualifier in this scenario. Thryduulf (talk) 22:11, 28 August 2016 (UTC)
We'd need "average maximum temp." and "average minimum temp." too. Recently we approved precipitation height (P3036), but it seems pretty weird, as it represents a point in time, not an average. How about "average montly precipitation height" and "average yearly precipitation height"? Seriously, I think we need to apply here a more holistic view, not proposing one by one. Strakhov (talk) 17:09, 30 August 2016 (UTC)
  • Pictogram voting comment.svg Comment would it be possible to consider instead a property that provides a database of temperatures for the location so that whatever monthly or yearly averages are wanted can be computed from it? It might have to be a URL to a dataset...? ArthurPSmith (talk) 19:19, 30 August 2016 (UTC)
    The average yearly temperatures in a certain decade are fixed values, they won't change. However, external links will probably do, sooner or later. And, as only linking an external database wouldn't be enough to retrieve data from the Wikimedia projects, I think that it's better to directly save these data in Wikidata. --abián 09:16, 2 September 2016 (UTC)
  • Well, sometimes old values do change thanks to reanalyses - or at least in certain datasets they wouldn't be perfectly fixed. In any case, what I think would be best here would be to be able to store the full dataset, say as a CSV file, in Wikimedia Commons. However, Commons doesn't allow CSV or other dataset files at the moment. If we store monthly averages directly in wikidata, then you have 12 statements per year - for some locations there are 150 years or so of data (perhaps more in England?) so you could have 1800 temperature statements on a location item in wikidata under this approach. That doesn't seem like a good idea to me. ArthurPSmith (talk) 15:41, 21 September 2016 (UTC)
  • Per Phabricator:T120452, tabular data storage is coming to Commons at some point. I'm not familiar with what the current state of work on it is. Thryduulf (talk) 20:11, 21 September 2016 (UTC)
  • They wouldn't be 1800 temperature statements in any case. These values are average ones, usually, in a 30-years period, not in a year. --abián 18:11, 22 September 2016 (UTC)

If I'm not wrong, these are the possible Wikidata properties concerning average temperatures and their dependencies.

Deriving average temperatures.svg

These dependencies can be applied, mutatis mutandis, to any kind of average climate data (average rainfall, average relative humidity, average number of frosty days, etc.).

Having read all comments, having done some research, and knowing that these data:

  • have an absolutely different availability depending on the relevance of the place, on the country and on the antiquity;
  • should always be used with qualifiers start time (P580) and end time (P582);
  • should always have a direct reference;
  • are historical and should never change since they are added to Wikidata;

... I propose that we exceptionally assume some degree of duplication with them and that we allow to store multiple declarations using these properties even for the cases that some of them could be derived from others.

For the case of monthly data, declarations should also necessarily have the qualifier month of the year (P2922).

In conclusion, concerning this property, "average yearly temperature", I still think that creating it would be a good idea. --abián 12:25, 2 September 2016 (UTC)

  • Given that it makes sense to fill for almost any place with a location, I think having a specific property for it is warranted. Symbol support vote.svg Support ChristianKl (talk) 18:20, 25 September 2016 (UTC)
  • Pictogram voting comment.svg Comment I think it would be good to have the monthly series of min/max/avg, but I don't think current quantity type and GUI is quite ready for this.
    --- Jura 23:53, 29 September 2016 (UTC)
  • Pictogram voting comment.svg Comment Please see Phabricator:T147049.
    --- Jura 09:03, 30 September 2016 (UTC)
    • +1 Climate data is needed on Wikidata. The RedBurn (ϕ) 11:53, 15 February 2017 (UTC)
  • @Abián, Thryduulf, ChristianKl, Jura1: Commons now has tabular data; I strongly suggest that instead of this proposal we propose a "temperature dataset" property with datatype "Commons media" to allow for whatever temperature data is available to be linked to a location. ArthurPSmith (talk) 16:15, 10 January 2017 (UTC)
    • Pictogram voting comment.svg Comment Obviously, this is only marginally related to average yearly temperature, but I don't quite see the difference between gifs at Commons and Commons datasets. Neither allow us currently to do comparisons with other locations. Given that quantity datatype has gotten more efficient in terms of resources, we might try a single property for temperatures.
      --- Jura 16:42, 10 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose use tabular data on Commons. Average yearly temperature is only single quantity out of many relevant ones for climate data. Average/min/max yearly/monthly/daily temperature/precipitation are others. We should find a solution which works for all these quantities. Here it should become clear that Wikidata is not the right place for it. Climate data are tabular data and the developers decided to store tabular data on Commons and not on Wikidata, so let's use Commons. A demo is already online: en:User:Yurik/WeatherDemo using the data stored on commons:Data:Ncei.noaa.gov/weather/New York City.tab. --Pasleim (talk) 16:54, 11 January 2017 (UTC)
Pictogram voting comment.svg Comment How many dimensions data should have when we call it "tabular"? Geographic dimension represented using items.
Census data have 3 dimensions right now: location, point in time, sex.
It is possible to get 50+ dimensions from census information, we need only selection of dimensions on Wikidata, not complete 1-to-1 dumps.
Pictogram voting comment.svg Comment If we use .csv / .tabs on commons, then I would like to have a property about "tabular data available on commons"; and with qualifier about topic ("Climate data"). d1g (talk) 03:19, 14 January 2017 (UTC)
That is far too generic. It would be like having a property called "string" that we use for all strings. - Nikki (talk) 18:19, 31 January 2017 (UTC)
  • Pictogram voting comment.svg Comment this is my first time at the property proposals page, so I'm going to keep things to a comment for now. I was just editing Q21726404, and I was looking for a property for annual temperature. There are tons of bot-generated pages on the Swedish Wikipedia, for example the bot generated page for the item I just mentioned. The bot found structured data to make that page, so I feel that Wikidata could have a viable property for this. Icebob99 (talk) 14:53, 16 February 2017 (UTC)

Soundtrack Collector ID[edit]

Description Internet Database for soundtrack, artist, titles, composer, label number o track.
Represents soundtrack (Q217199)
Data type External identifier
Example Saturday Night Fever (Q47654)http://www.soundtrackcollector.com/title/2500/Saturday+Night+Fever
Source http://www.soundtrackcollector.com/
Motivation

Please add Soundtrack Collector reference to Wikidata. It's an important source for soundtracks. Thanx IlPasseggero (talk) 09:15, 30 September 2016 (UTC)

Discussion
Not sure about type. A couple of example: http://www.soundtrackcollector.com/catalog/soundtrackdetail.php?movieid=88677 http://www.soundtrackcollector.com/title/2500/Saturday+Night+Fever --ValterVB (talk) 16:24, 30 September 2016 (UTC)
Changed to "external-id", but we need to look at the formatter URL and decide whether we need more than one property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:24, 30 September 2016 (UTC)
We need two parameters: "title", associated to a movie, and "composer", associated to a composer. We need the subject item Q36834 too, indeed. --IlPasseggero (talk) 23:21, 8 October 2016 (UTC)
Symbol support vote.svg Support --ValterVB (talk) 17:32, 8 October 2016 (UTC)

File format magic numbers[edit]

   Under discussion
Description magic numbers used to incorporate file format metadata in form of a string coded hexadecimal number (usual encoding, "0" = 0 and "F" = 15, space ignored). Qualifiers can specify an offset and a padding value for this number.
Data type String
Template parameter Template:Infobox file format (Q10986167) magic number parameter
Domain file format (Q235557)
Example Graphics Interchange Format (Q2192) -> 47 49 46 38 39 61
Source Gary Kessler's File Signatures Table
Planned use I plan to add magic numbers to Wikidata items for the corresponding file formats.
Motivation

Magic numbers are constant numerical or text values used to identify file formats. Having this data in Wikidata will help make file format information more complete. Magic numbers are part of how we verify file signatures and are used in forensic computing. This is also a parameter of the Infobox:File format. It will be possible to transfer all of the magic numbers stored in infoboxes to Wikidata if we create this property. There is also this list [List of file signatures] that we could transfer to Wikidata. YULdigitalpreservation (talk) 15:43, 17 October 2016 (UTC)

Qualifier[edit]

(Additions to the proposal by TomT0m)

Offset[edit]
   Under discussion
Description qualifier of "magic number" for the number of bytes before the magic number to be searched in a file
Data type Number (not available yet)
Example Modelling the format "RVT" "
[512 (0x200) byte offset]
00 00 00 00 00 00 00 00 	  	[512 (0x200) byte offset]
........
RVT 	  	Revit Project File subheader
gives
< RVF > magic number search < 00 00 00 00 00 00 00 00 >
offset search <  512 >
.
Source Gary Kessler's File Signatures Table
Planned use qualifier for the property above

Talk[edit]

  • Symbol support vote.svg Support Symbol wait.svg Wait. author  TomT0m / talk page 17:31, 17 October 2016 (UTC)
  • Symbol support vote.svg Support but there are several other kinds of "magic numbers" so I think the name needs to be more descriptive - maybe "file format magic numbers"? Also, with string value isn't there some room for ambiguity in how the numbers are to be represented here? ArthurPSmith (talk) 18:18, 17 October 2016 (UTC)
    • Good point. If the numbers are string coded hexadecimal, this should be made explicit. The spaces seems also totally irrelevant and adds burden to parse. I can also see in the files that spec also specifies offsets : [11 byte offset] and [512 (0x200) byte offset]. This could be handled better than with an unspecified string format in a structured data projects. Also see if the string can't encode the non-hex version such as directly the string, for example in
    46 41 58 43 4F 56 45 52 FAXCOVER
    2D 56 45 52 	        -VER
    
    it should be possible to store more efficiently directly "FAXCOVER-VER", maybe an offset with a qualifier, and maybe a "padding value" also with a qualifier, something like
    < format > magic string search < FAXCOVER-VER >
    offset search < 0 byte >
    padding search < 0 >
    . author  TomT0m / talk page 18:32, 17 October 2016 (UTC)
    • Pictogram voting comment.svg Comment Thanks for this feedback. I revised the label for the property proposal. It looks like we will need a hexadecimal option as well as an ascii option. I welcome suggestions of how to further refine the proposal. YULdigitalpreservation (talk) 13:45, 18 October 2016 (UTC)
  • Symbol support vote.svg Support It will be very useful for data regarding file type identification. CC0 (talk) 11:45, 28 October 2016 (UTC)
  • Pictogram voting comment.svg Comment Could this property be specified to contain values which are Perl Compatible Regular Expressions (PCRE), allowing for more advanced signatures to be specified if desired? For example, "\x89PNG\x0D\x0A\x1A\x0A" for the PNG family, "\x00\x01\x00\x00Standard Jet DB" for Microsoft Access MDB, "GIF8[79]a" for the GIF family, etc. The advantages are: for ASCII-only-signatures (GIF), it's human-readable. For signatures containing binary/non-ASCII data (PNG), it's in a readily usable format (C/C++ strings for example) and for optionally complex signatures, it's in a format ready to use with a PCRE compliant parser. Pixeldomain (talk) 02:44, 17 November 2016 (UTC)
    Pictogram voting comment.svg Comment The offset could be identified in the PCRE expression, as an example: "(?s)^\x00\x01\x02.{38}ANSWERTOEVERYTHING" would look from the start of the file for \x00\x01\x02 then skip 38 bytes to offset 42 in the file where it would look for "ANSWERTOEVERYTHING". More advanced expressions could look at bytes from the end of the file (ZIP archives have a central directory tacked on the end of the file), perform negative look-aheads, etc. Whilst there is extra complexity with PCRE, it does not have to be used, and the fall-back is a simple C/C++ string representing binary data. Pixeldomain (talk) 03:09, 17 November 2016 (UTC)
  • Pictogram voting comment.svg Comment Also worth taking a look at is how the magic file of the "file" command stores file type signatures: https://github.com/file/file/tree/master/magic/Magdir Pixeldomain (talk) 03:32, 17 November 2016 (UTC)
    Pictogram voting comment.svg Comment Also take a look at the FIDO PRONOM database at https://raw.githubusercontent.com/openpreserve/fido/af3fc47791855ad7b955eb4272411113bfcff54d/fido/conf/formats-v88.xml which uses PCRE to define signatures for each file type. Pixeldomain (talk) 04:04, 17 November 2016 (UTC)
  • @Pixeldmain, cc0, YULdigitalpreservation, TomT0m, ArthurPSmith: what is the status of this proposal? Thryduulf (talk) 16:32, 22 April 2017 (UTC)
    • @Pixeldomain, CC0: (fixing pings) - obviously there was some debate here about the string format for this property. Of the proposals for format, I think the PCRE idea has a lot of merit. But I'd be ok with the original space-separated hexadecimal pairs too. No strong preference. ArthurPSmith (talk) 13:24, 24 April 2017 (UTC)
      • Pictogram voting comment.svg Comment @ArthurPSmith: My current view is that magic numbers or patterns are not a good property for a file format. See use of described at URL (P973) on Graphics Interchange Format (Q2192) for an example of an alternative approach I prefer for the identification and description of file formats. Pixeldomain (talk) 01:31, 26 April 2017 (UTC)
        • that means relying on a third party to provide the actual details of the format, but in some cases that may be all we have, so it's at least a good option to use. I still think a wikidata property specifically for something like this is useful though. ArthurPSmith (talk) 13:37, 26 April 2017 (UTC)
        • An alternative I have also considered is detailing the structure of file formats on Wikidata by creating items for each data structure and field within each format. This moves the data from external sources into Wikidata, whilst allowing external references and sources (typically international standards, RFCs, etc) be used to describe each new item. Do you have any thoughts on this possible approach? Pixeldomain (talk) 00:58, 27 April 2017 (UTC)
          • I'd probably want to see an example? Would there be several additional properties needed to do that, or can you make do with existing properties? ArthurPSmith (talk) 19:25, 27 April 2017 (UTC)

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Azertus
Pintoch
Jsamwrites
Pictogram voting comment.svg Notified participants of WikiProject Informatics Are there additional opinions about whether we should implement this property? ChristianKl (talk) 20:32, 24 May 2017 (UTC)

  • Symbol support vote.svg Support This property is really needed for file formats. Looking aback to the discussion, the best approach seems to be using PCRE. One last aspect may be adding a qualifier to add a weight or a probability on the proposed PCRE. This is a common practice in implementing format identification from magic numbers. Toto256 (talk) 20:51, 24 May 2017 (UTC)

IECIC 2015[edit]

Description Inventory of Existing Cosmetic Ingredients in China (2015)
Data type External identifier
Domain cosmetic ingredients
Allowed values numbers
Example 2,6-pyridinedicarboxylic acid (Q417164) → 3926
Format and edit filter validation number
Source http://cirs-reach.com/news-and-articles/new-inventory-of-existing-cosmetic-ingredients-in-china-launched-(iecic-2015,-final-version).html
Planned use import the whole Inventory in Mix n'Match
Robot and gadget jobs no
Motivation

Having chinese labels on cosmetic ingredients, linking it with the European and American systems. Teolemon (talk) 18:56, 17 October 2016 (UTC)

Putting it here to show the advantages:

2,6-pyridinedicarboxylic acid (Q417164) → 3926 → "3926 (2,6-二羧基吡啶) (2,6-DICARBOXYPYRIDINE)"

Discussion
  • @Teolemon: Seems reasonable, but the example given, "3926 (2,6-二羧基吡啶) (2,6-DICARBOXYPYRIDINE)", does not match the allowed values ("numbers") in the proposal. Please resolve this discrepancy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:13, 20 October 2016 (UTC)
  • I would like the long name as the label to make it easier to understand for the viewer what the property is about. ChristianKl (talk) 11:01, 29 October 2016 (UTC)
    • Then I think you probably want item datatype, with an item for the different ingredients. Thryduulf (talk) 01:03, 31 October 2016 (UTC)
  • @Teolemon: What's the status of this? Are you still interested in this property? What about the comments by ChristianKl and Thryduulf? Sebari – aka Srittau (talk) 14:50, 21 May 2017 (UTC)
  • @Strittau: Yes, still topical, still very interested as it will permit to link the Chinese and European Cosmetic systems and regulations together, and pave the way for more transparency, and apps like Open Beauty Facts (which is the reason I proposed it). Perfectly fine with the remaks from @ChristianKl: and @Thryduulf:: the numeric value is all that matters, although we can use the Chinese string as a label. As for the nature of the value: it's cosmetics ingredients in Chinese, as issued by the State Regulator for their authorized ingredients list.--Teolemon (talk) 22:01, 21 May 2017 (UTC)
@Teolemon: ✓ Done Sebari – aka Srittau (talk) 17:06, 22 May 2017 (UTC)

Web mapping service link[edit]

   Under discussion
Description Link to the external service, where the image or map can be retrieved as a zoomable resource
Data type URL
Domain image, map
Allowed values URL
Example MISSING
Planned use This property can be used to link to resources where an image or map is available as a zoomable resource
Motivation

It will be possible to link to resources where the map items (also images) can be found as zoomable tiles. Susanna Ånäs (Susannaanas) (talk) 10:04, 4 November 2016 (UTC)

Discussion
Could you provide an example? --Pasleim (talk) 10:22, 4 November 2016 (UTC)

Protocols Supported[edit]

If this property is used, it should have a qualifier of any of the following types:

  1. Web Map Service (Q974922)
  2. Web Feature Service (Q2296308)
  3. Tile Map Service (Q1280407)
  4. Web Map Tile Service (Q10908558)
  5. Keyhole Markup Language (Q79587)

>> Any other? --Batje (talk) 11:36, 4 November 2016 (UTC)

What is the unique ID of this property?[edit]

There are several ways of modeling this behaviour.

A. The URL is the key[edit]

That is the current proposal. This property becomes very flexible and can point to anywhere on the interwebs. There is not a lot of intelligence in this property, if the qualifier for the protocol (see below) of the link is ommitted, it becomes very error-prone.

B. The external qualifier is the key[edit]

This is similar to for example BnF ID (P268) which requires every external resource to register as a seperate property, and then use the formatter URL (P1630) property to tell us more about the required format of the URL. Every of these P's could then have multiple formatter URL (P1630) for every protocol qualifier (WMS/WFS/etc.) it should create a new one.

C. The external qualifier *and* the protocol are the key[edit]

We create properties for every protocol, similar to RDF URI template (P1921). Then, we go back to B, and create a Property for every service. Eg. The Mapwarper would have its own property:

  • PXXA: TMS URL
  • PXXB: WMS URL


Then the Wikidata Item for the map belonging to [ [File_dummy: New_haven_line_map.png] ] will have:

  • P18: File:New_haven_line_map.png
  • PXX: 1591

--Batje (talk) 11:36, 4 November 2016 (UTC)

  • Symbol oppose vote.svg Oppose as the proposal seems to be incomplete with no apparent interest at the moment in determining what structure is desired. Thryduulf (talk) 16:37, 22 April 2017 (UTC)
  • @Susannaanas: You never entered an example. Does that mean that you don't need this property and the proposal can be closed? ChristianKl (talk) 10:08, 24 May 2017 (UTC)
    • I would need input from the community to the above questions. It can also wait until later, when it's more articulated. – Susanna Ånäs (Susannaanas) (talk) 10:26, 24 May 2017 (UTC)

publication manager[edit]

   Under discussion
Description person legally responsible of the content of a periodic or another publication in france
Represents director of publication (Q3029421)
Data type Item
Template parameter "directeur de publication" of Template:Infobox newspaper (Q9460683) View with Reasonator View with SQID in frwiki
Domain human (Q5) View with Reasonator View with SQID
Example Le Monde (Q12461) -> Louis Dreyfus (Q16661304)
Motivation

Needed for the infobox. author  TomT0m / talk page 17:55, 3 November 2016 (UTC)

Discussion

Symbol support vote.svg Support. Tubezlob (🙋) 19:52, 3 November 2016 (UTC)

  • Pictogram voting comment.svg Comment can't the infobox use employer (P108) or corporate officer (P2828) with qualifier position held (P39) specifying director of publication (Q3029421)? ArthurPSmith (talk) 20:52, 4 November 2016 (UTC)
    • @ArthurPSmith: Probably, but it's supposed to work from the journal to the person - as it's an important role in a journal. And we still can't retrieve the information from the journal article if the statement is in the person one.
  • Pictogram voting comment.svg Comment Does this mean newspaper editor (Q17351648)? If so, how if it different from editor (P98)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 7 November 2016 (UTC)
    • @Pigsonthewing: I don't know, probably but I can't get much information from this item. There is no article to understand what it is and absolutely no definition in description of what it's supposed to mean. I proposed this property partly because it has a specific legal status. What I'm sure is that the two notions has different names in french (scientific editor and journal editor) - and distinct definitions can be found ( http://www.eurekoi.org/quelle-difference-y-a-t-il-entre-un-directeur-de-publication-dune-part-et-un-editeur-scientifique-dautre-part/ ) :
      scientific editor 
      Personne ou collectivité responsable du contenu intellectuel de l’édition d’un document, quel que soit son support_: édition critique d’un texte, édition d’un ouvrage collectif, etc. => person or organisation who is responsible for the intellectual content of the edition of a document, whatever the support : critic edition of a text, edition of a collective work, ... (translation almost word for word as I'm not sure I understand every subtlety of the original)
      journal editor 
      someone responsible of the editions of a journal [...]
      But digging a little more we can find arguments for the specialized denomination for newspaper of a similar role : in this human sciences help for publication : Si la responsabilité principale incombe à un éditeur scientifique sa fonction est indiquée par l'abréviation "éd.", entourée ou non par parenthèses. NB. Il n'y a pas de raison de différencier le directeur de publication par l'abréviation "dir." : le directeur de publication est effectivement un éditeur scientifique. => in bold, there is no reason to differentiate the director of publication by "dir." : the director is in effect a science editor".
      So maybe it's enough to add an alias and to put a different label in each infoboxes indeed. author  TomT0m / talk page 19:46, 7 November 2016 (UTC)
  • Pictogram voting comment.svg Comment. Maybe can we use the newly created significant person (P3342)? But this is just a suggestion to let you know that such an option is now available. Thierry Caro (talk) 20:34, 15 November 2016 (UTC)
  • Pictogram voting comment.svg Comment This proposal appears to abandoned? Thryduulf (talk) 22:15, 14 April 2017 (UTC)

Google Play Music artist ID[edit]

   Under discussion
Description ID of an artist on the Google Play Music website
Data type External identifier
Example Heikki Kuula (Q4276848)Alcizqffis4gtt7yjhjjftzlya4
Formatter URL https://play.google.com/store/music/artist?id=$1

Google Play Music album ID[edit]

   Under discussion
Description ID of an album on the Google Play Music website
Data type External identifier
Example Suomalainen mies (Q27687809)Biaqn6hnnzfac7fr2ppg4asoedu
Formatter URL https://play.google.com/store/music/album?id=$1

Tidal artist ID[edit]

   Under discussion
Description ID of an artist on the Tidal website
Data type External identifier
Example Heikki Kuula (Q4276848)4768947
Formatter URL https://listen.tidal.com/artist/$1

Tidal album ID[edit]

   Under discussion
Description ID of an album on the Tidal website
Data type External identifier
Example Suomalainen mies (Q27687809)63596443
Formatter URL https://listen.tidal.com/album/$1

Tidal track ID[edit]

   Under discussion
Description ID of a track on the Tidal website
Data type External identifier
Example Lambada (Q15897084)63596443
Formatter URL https://listen.tidal.com/track/$1

Tidal video ID[edit]

   Under discussion
Description ID of a video on the Tidal website
Data type External identifier
Example Tuulisii (Q20826667)50956283
Formatter URL https://listen.tidal.com/video/$1

Microsoft Store artist ID[edit]

   Under discussion
Description ID of an artist on the Microsoft Store website
Data type External identifier
Example Heikki Kuula (Q4276848)f3860700-0200-11db-89ca-0019b92a3933

Microsoft Store album ID[edit]

   Under discussion
Description ID of an album on the Microsoft Store website
Data type External identifier
Example Suomalainen mies (Q27687809)8d6kgx0s7tp6
Motivation

We have many properties about music streaming services and stores, like Spotify track ID (P2207), Deezer album ID (P2723) or iTunes album ID (P2281). I just discovered LinkFire and I think that Wikidata can compete for offering an up-to-date CC-0-licensed database of external IDs of music services and stores. By now I just added some of the most famous (Google Play Music (Q3238917), Tidal (Q19711013) and Microsoft (Q2283)). AFAIK there isn't a simple way to link to Microsoft Store. -- ★ → Airon 90 16:59, 4 November 2016 (UTC)

Discussion
  • Pictogram voting comment.svg Comment Hmm, is it feasible in the long run to create properties for every supported category on every service? I would prefer a generic property where the service can be specified as a required qualifier. Of course there is the question about formatter urls, right now I don't think there is support for having them be different for different qualifiers? To me adding that support in the UI and then removing all of these for one (either just one, or one for artists, one for albums and so on) and then differentiating them using a qualifier pointing to an item would be better. That would support all services with much fewer properties. I don't oppose adding these as this is the way we have to add them right now and a migration could easily be made by a bot later on. But I would at least like to discuss a generic solution first. --Pajn (talk) 20:47, 6 November 2016 (UTC)
  • Symbol support vote.svg Support. Given that no discussion of a generic solution has apparently happened yet, it seems pointless to delay this further even if it is only used for the interim. Thryduulf (talk) 16:35, 22 April 2017 (UTC)

strength[edit]

   Not done
Description the concentration or strength of a product, related to the amount or proportion of active ingredient(s)
Data type Number (not available yet)
Domain products, medicines, qualifier for the proposed legal status (medicine) property
Allowed values non-negative numbers
Allowed units milligrams, grams, percentage, proof, millilitres, units of concentration, probably others
Example ibuprofen (Q186969) → 200 milligram (Q3241121) [see below for more detail]
Planned use This is required for correct modelling of medicine sales restrictions, but is also intended for more general application
See also minimum explosive concentration (P2204), minimal lethal concentration (P2710), lower flammable limit (P2202), ceiling exposure limit (P2405), lowest-observed-adverse-effect level (P2718), short-term exposure limit (P2407), alcohol by volume (P2665) and other specialised properties relating to these
Motivation

In discussing how to model restrictions on medicine sales at Wikidata:Property proposal/legal status (medicine) it has become clear that we have no way of expressing currently the strength of a medicine. For example in the UK ibuprofen (Q186969) 200mg strength can be bought in a supermarket but a pharmacist can sell 400mg strength. quantity (P1114) is not suitable for this as that will be used to express restrictions like the number of tablets that can be legally purchased (in the UK acetaminophen (Q57055) can be bought in packs of 16 tablets from a supermarket but packs of 32 from a pharmacy for example). We have a alcohol by volume (P2665) property specifically for the strength of alcoholic beverages and several very specialised concentration properties but nothing for other products that have varying strengths (e.g. tobacco, glue, washing up liquid, etc). Thryduulf (talk) 14:28, 6 November 2016 (UTC)

Discussion
  • Those are all mass (P2067) units so why not use that property for this? ArthurPSmith (talk) 21:46, 7 November 2016 (UTC)
    • My first reaction is that I would expect mass (P2067) to be the mass of the product not the quantity of active ingredient(s) which can be measured by mass (relative or absolute), volume (relative or absolute), concentration, or combinations of these (and possibly other units too). Thryduulf (talk) 18:59, 8 November 2016 (UTC)
  • How do other ontologies call the relationship between ibuprofen (Q186969) and 200 milligram (Q3241121)? I wouldn't want to create this property the proposed way without investigating how the relationship is modeled elsewhere. We should only invent a new way to model this relationship if there's an argument made that existing ways of modeling the relationship aren't appropriate for Wikidata and currently I don't see such an argument made here. ChristianKl (talk) 20:27, 8 November 2016 (UTC)
    • I've not seen any other ontologies that model this, and nobody has linked to any in the months of discussion leading up to this proposal. In what other ways could it be modelled? Thryduulf (talk) 13:05, 10 November 2016 (UTC)
      • I don't think "nobody cared to do the research" is a good criteria for property creation. I look at how DrugBank models this property and it also uses strength (https://www.drugbank.ca/drugs/DB01050), so strength seems okay. ChristianKl (talk) 10:55, 15 November 2016 (UTC)
  • Is this property only supposed to be used as a qualifier? ChristianKl (talk) 20:28, 8 November 2016 (UTC)
  • Symbol support vote.svg Support ok, I've been thinking about this, I think it does make sense to have a dedicated property for this. However, the name needs to be more specific - maybe "medication strength per dose" ? ArthurPSmith (talk) 16:45, 15 November 2016 (UTC)
  • Strength per unit, perhaps? For use as a qualifier for modelling medicine sales restrictions both a minimum and maximum strength property would seem to be required though? Domswaine (talk) 19:45, 05 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose unless this property is: (1) named "concentration", (2) used as a qualifier on has part (P527) (or perhaps other more specific properties better suited to chemistry) and alongside additional qualifiers such as solvent (P2178), (3) has an allowed domain of mixture (Q169336) (including subclasses which currently need to be reorganised), (4) has units constrained to items which have measured physical quantity (P111) concentration (Q3686031)). This would make the property far more generic and allow specification of not just the "strength" of medicines, but also the recorded pollution levels in cities (particulates in parts per million, etc), concrete suspensions and many other aspects of chemistry. Dhx1 (talk) 13:55, 8 February 2017 (UTC)

Saehrimnir
Leyo
Snipre
Jasper Deng
Dcirovic
Walkerma
Egon Willighagen
Daniel Mietchen
Andy Mabbett
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Nothingserious
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Pictogram voting comment.svg Notified participants of WikiProject Chemistry for expert advice. Dhx1 (talk) 13:57, 8 February 2017 (UTC)

  • Symbol oppose vote.svg Oppose. As Dhx1 says: better named 'concentration', or maybe 'dose', 'quantity per unit'. While 'strength' may be the common wording in medicine context, especially spoken, it should be defined being a physical quantity with correct dimensions (in general: quantity = number × dimension; e.g., speed = 40 km/h). In the example "200mg" the dimension appears to be mg, but is understood and implied to be mg/unit. -DePiep (talk) 14:17, 8 February 2017 (UTC)
  • Pictogram voting comment.svg Comment A property "concentration" can make sense and can be used for other properties like pH for organic compounds (solvent or solid) when diluted in water to measure a pH. Snipre (talk) 17:09, 8 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose Useful information but not here. I don't see how this would be meaningful as a property of the compound especially without any context. Yes there are regulations and standards for formulations depending on country, but really it is completely arbitrary and can easily change in time and space. And the formulation and the prescription arn't necessarily related, for example with pain relief medication, one may need to gradually ramp or taper their dose by dividing or multiplying pills. Aswell the dose depends on what the drug is indicated for such as bupropion or trazodone. I suggest making a page for the formulation than use something like ingredient property with a quantity attached to it. See my comment on Wikidata:Property proposal/National Drug Code for more detail. Devon Fyson (talk) 09:44, 9 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose. There is no explanation how the "correct modelling of medicine sales restrictions" will be achieved using this property. What's more, adding this property, as proposed, to compounds would be wrong, because it's not a strength of a compound but a medicinal formulation. The units should be e.g. miligrams per dosage form in some cases but concentration in other. Wostr (talk) 12:17, 9 February 2017 (UTC)


Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:CFCF
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Pictogram voting comment.svg Notified participants of WikiProject Medicine, @Wostr: This property was initially proposed to qualify the legal status of medicinal drugs (P3493) - e.g. simvastatins can be bought over the counter in pharmacies in the UK where the strength of each unit/tablet is less than 10mg, stronger doses are only available on prescription. Domswaine (talk) 19:13, 09 February 2017 (UTC)

  • @Domswaine:, Yes, that's something I understand from the proposition. What I don't understand is the exact relation between pure compound element, formulation element, proposed property, legal status (medicine) (P3493), and maybe other necessary properties/qualifiers. The example given in the proposition tells nothing and is wrong. In other words, what is the "correct modelling of medicine sales restrictions"? Wostr (talk) 20:15, 9 February 2017 (UTC)
  • @Wostr: I imagined an applies to (min/max) strength property (of active ingredient) and the applies to territorial jurisdiction (P1001) property as qualifiers to the legal status of medicinal drugs (P3493) property. Domswaine (talk) 20:33, 09 February 2017 (UTC)
    • Okay, but how do you want to indicate min or max strength with only one property (strength)? I think there's a reason why we have e.g. lower and upper explosion limits properties, not only one property (explosion limit). From what you're saying, I can imagine a relation:
      Drug element (Q....)
      I don't know where the max/min is needed here, but the problem is we don't have medical fomulations as different elements in WD, and I don't think we should. The other option is to have such relation in chemical compound elements (like in ibuprofen (Q186969)), but this would be wrong, as strength is not a property of chemical compound. Wostr (talk) 20:17, 15 February 2017 (UTC)
  • Pictogram voting comment.svg Comment I am leaning to oppose, but... this property is not one of a compound like ibuprofen, but of products (as the proposal suggests). But I question if we really want to have every formulation of products in the database. That's pretty unbounded, different for many countries, and likely volatile (companies change products, new vendors arise, etc, etc). But if this community decides that medicinal products are considered good to have in Wikidata, then it makes sense to have this property. --Egon Willighagen (talk) 10:19, 11 February 2017 (UTC)
    • BTW, the example links strength to a compound, and that I definitely Symbol oppose vote.svg Oppose. But I think the given example in not in line with the given "domain". --Egon Willighagen (talk) 10:21, 11 February 2017 (UTC)
  • @Wostr: Agree dose may be better wording. As the legal status is dependent on the strength/dose (active ingredient in mg, per day), an 'applies to max strength/dose' and an 'applies to minimum strength/dose' property seem necessary to qualify the legal status, for certain medications. Eg. simvastatins can be purchased (in a pharmacy) without the need of a prescription where dose is less than 10mg per day, otherwise a prescription is required. Domswaine (talk) 16:57, 16 February 2017 (UTC)
  • @Domswaine, Egon Willighagen, Wostr, Snipre, Thryduulf, ArthurPSmith: Not done. No consensus for this property. We might need another property proposal to represent this domain. ChristianKl (talk) 16:42, 25 March 2017 (UTC)

consort (or consort of)[edit]

   Under discussion
Description noble title gained by the husband/wife of someone with a title
Data type Item
Domain royal or noble rank (Q355567) View with Reasonator View with SQID
Allowed values royal or noble rank (Q355567) View with Reasonator View with SQID
Example
< Monarch of England (Q18810062) View with Reasonator View with SQID > consort search < Q19946212 >
Motivation

Needed to model noble titles. author  TomT0m / talk page 19:03, 5 November 2016 (UTC)

Discussion
I don't see a reason to have both directions in the same property. ChristianKl (talk) 20:36, 8 November 2016 (UTC)
@ChristianKl: I'm not sure of which to choose. Or if we need both (with two properties). Any opinion ? author  TomT0m / talk page 10:50, 9 November 2016 (UTC)
  • Pictogram voting comment.svg Comment why would this specific relationship needed to be modeled? has quality (P1552) or an equivalent of relative (P1038) could do
    --- Jura 11:22, 11 November 2016 (UTC)
    • @Jura1: You mean something like
      < Queen consort > has quality (P1552) View with SQID < values in qualifier >
      spouse (P26) View with SQID < King >
      or something like that ? I think that's not a bad idea but that may not work all the time : I'm not really into noble titles and inheritance but stuffs like death of some spouse - say "Lady Diana" before the spouse become the king, remariage, and so on, could make a mess not really easy to model. This property is probably way simpler to model the relationship between the titles themselves. Not to mention the possibly esoteric and inconsistent rules of nobleship through the kingdom. That's safest to model this relation than to try to model and follow the rules, imho. author  TomT0m / talk page 11:36, 11 November 2016 (UTC)
      • To follow the sample you gave in the proposal, when using has quality (P1552) this would look more like:
        British consort (Q19946212) - has quality (P1552) - consort (Q5784340) - qualifier of (P642) - Monarch of England (Q18810062)
        I'd avoid "values in qualifier" as an item as it does tend to get messy. With an equivalent of relative (P1038) it would be:
        British consort (Q19946212) - "title for relative of" - Monarch of England (Q18810062) - qualifier type of kinship (P1039) - spouse (Q1196129)
        We could probably apply the 2nd solution to items for family relationships in general. Oddly, none of the items given in the sample seem to relate to specific titles .. Besides as titles differ by country and tend to evolve through time, you might end up doing lots of parallel statements.
        --- Jura 11:58, 11 November 2016 (UTC)
        • I don't really like the first one the first solution as it uses a general meaningless qualifier who tends to be used everywhere and is probably dispensable - to me this gets to be far more messier than the "values in qualifier" solution as it clearly means imho that we wil get a set of "property values pair". With "of", god knows what we will get. I really don't get the "has quality : consort" solution either as "consort" is by essence a relationship which is more naturally model by a relationship than by an item. That's why you have to use a qualifier to add the value of the pair (title/consort title) - this seems a petty attempt to spare a property that twists Wikibase data model to put a square into a circle. I'd expect "has quality" to point to something that is a property of the instances, something like or something like that. But we never properly tried to define "has quality" so this became somewhat of a mess which means everything and nothing (actually in my example the proper way to model that every disk (Q238231) View with Reasonator View with SQID is convex could be given that the item means "convex set" as "any set that have the convexity property", and that we don't have an item actually for "convexity property". "Has quality" could also be seen as a duplicate of properties for this type (P1963) View with SQID is some cases where we have an item corresponding to the property (for example we know that the fathership relationship father (P22) View with SQID has a corresponding wikidata item father (Q7565) View with Reasonator View with SQID by a statement subject item of this property (P1629) View with SQID - Does this mean that we could for example model any relationship in Wikidata by for example
          < Adam > has quality (P1552) View with SQID < father >
          of (P642) View with SQID < Abel >
           ? Then we would need no property at all except "has quality". So maybe "has quality" has to be restricted to apply on types. Then if we mean that  and
          < human (Q5) View with Reasonator View with SQID > has quality (P1552) View with SQID < father >
          , we get a triangle "class - relationship item - wikidata property" and one edge of this triangle is redundant. In the end, this property is a mess.

          The second proposition is way more interesting as things are way better defined here, including the qualifier who is already defined for similar case. It's clear that's the qualifier value has to be a relationship item and it's a good compromise if there could be a lot of relative titles. However I wonder if that would be necessary as I can't cite another title for relative than "prince" or "princess" ... Any idea ? author  TomT0m / talk page 13:11, 11 November 2016 (UTC)

  • It's probably better to see at least a dozen of samples. Generally, I noticed that some of the properties proposed by Tomtom remain unused and get potentially messy as users don't have any clear precedents to follow. As for the link to Adam and Lady Diana, it seems to be yet another digression.
    --- Jura 17:30, 11 November 2016 (UTC)
    • @Jura1: Any proof that stuffed got messy ? This looks like an ad hominem to me. author  TomT0m / talk page 11:31, 12 November 2016 (UTC)
  • Ok, since this seems primordial, then a list of usecase : pretty much every titles related to Category:Royal consorts (Q7024154) View with Reasonator View with SQID this category. An example of reated list : List of Hungarian consorts (Q2476718) View with Reasonator View with SQID. Is this enough for @Jura1:'s standards ? author  TomT0m / talk page 13:57, 12 November 2016 (UTC)
  • @TomT0m: Do you now know in which direction you want the property to be? ChristianKl (talk) 15:07, 1 March 2017 (UTC)