Wikidata:Property proposal/Pending

From Wikidata
Jump to navigation Jump to search
Tracked in Phabricator
Task T91505

Awaiting multilingual text type

[edit]
Tracked in Phabricator
Task T86517

Sandbox-Multilingual texts (en)

[edit]
Agreed to be created; waiting for multilingual text datatype
   On hold
DescriptionA sandbox type per available data type
Data typeMultilingual text (not available yet)
Domainany
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byGZWDer (talk) 09:37, 6 June 2013 (UTC)[reply]
Discussion

IUPAC name

[edit]
Agreed to be created; waiting for multilingual text datatype
   On hold
Descriptionen:IUPAC name
Data typeMultilingual text (not available yet)
Domainchemistry
Examplesee Wikidata:Chemistry_task_force/Properties.
Sourceen:PubChem
Proposed byGZWDer (talk) 03:07, 7 June 2013 (UTC)[reply]
Discussion
 Support Snipre (talk) 21:41, 10 June 2013 (UTC)[reply]
 Support --Kaligula (talk) 07:06, 19 June 2013 (UTC)[reply]
Hmm, this is for some compounds still a disputed property .. --Beetstra (talk) 13:05, 24 June 2013 (UTC)[reply]
There is always one IUAPC and most of the time you can put more than one. And as IUAPC is going to publish some rules to select the preferred name when several possibilities exist (see here, we can define one name for that property. Snipre (talk) 12:49, 26 June 2013 (UTC)[reply]
I have noticed French language using alternative characters with accents for the names, which does not quite match use in English. So is the non accented use correct? Graeme Bartlett (talk) 08:15, 29 June 2013 (UTC)[reply]
In French non accented names are not correct. That's why a multilingual property is proposed: each language will have its own name, so the value of this property will be a list of chemical names associated with a language. Snipre (talk) 08:32, 29 June 2013 (UTC)[reply]
 Support, though the domain should probably be refined to "chemical compounds". Otherwise perhaps I'll finally get to see the IUPAC name for titin! It would also help to have an example, if only for documentation. Proposing a canonical source for IUPAC name claims would be helpful, too. Emw (talk) 12:14, 29 June 2013 (UTC)[reply]
 Support - additionally it should be investigated if this can be filled in by a bot because it is pretty standardized. --Tobias1984 (talk) 14:51, 11 July 2013 (UTC)[reply]
 Support -- Andrew Su (talk) 23:10, 19 July 2013 (UTC)[reply]
 Support – IUPAC name property should be available. It's rather a unique identifier in a sense that a IUPAC name defines single compound. There can be more different IUPAC names for single compound (but it is the case for SMILES strings, maybe even "canonical" as well). For that type of uniqueness, the PIN (Preferred IUPAC Name, introduced in 2013) can be used (which however is still somewhat open problem, e.g. for natural compounds). —Mykhal (talk) 18:44, 29 March 2020 (UTC)[reply]

Description/review (en)

[edit]
Agreed to be created; waiting for multilingual text datatype
   On hold
Descriptionvoy:Template:Listing A brief description of the listing
Data typeMultilingual text (not available yet)
Template parametercontent
DomainItems with Wikivoyage listings
Allowed valuesany text
ExampleExploratorium (Q206518) -> A great kid friendly option, with lots of interactive exhibits teaching about science, with intriguing displays about the mind, natural systems, sound, sight, and much much more.
SourceWikivoyage listings
Proposed byFilceolaire (talk) 00:11, 19 August 2013 (UTC)[reply]
Discussion

Awaiting time type with precision second

[edit]
Tracked in Phabricator
Task T57755

checkin time (en)

[edit]
Approved for creation; waiting for Number datatype
   On hold
DescriptionTime of hotel reservation or airport flight check-in
Representscheck-in (Q1068755)
Data typePoint in time
Template parametervoy:Template:Listing : "checkin" - Template:Listing (Q14330485)
DomainHotel reservation or airport flight
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byGZWDer (talk) 10:39, 18 June 2013 (UTC)[reply]
Discussion

checkout time (en)

[edit]
Approved for creation; waiting for Number datatype
   On hold
DescriptionTime of hotel reservation check-out
Data typePoint in time
Template parametervoy:Template:Listing : "checkout" - Template:Listing (Q14330485)
DomainHotel reservation
Example 1MISSING
Example 2MISSING
Example 3MISSING
Proposed byGZWDer (talk) 10:39, 18 June 2013 (UTC)[reply]
Discussion

Epoch

[edit]
Approved for creation; waiting for Number datatype
   On hold
Descriptionepoch of the elements of the orbits of artificial satellites and astronomical objects
Representsepoch (Q2703)
Data typePoint in time
Template parameteren:Template:Infobox spaceflight: "orbit_epoch" (Template:Infobox spaceflight (Q14907524)); en:Template:Planetbox orbit: "epoch" (Template:Planetbox orbit (Q8116171))
Domainastronomical objects, artificial satellites, spaceflight
ExampleApollo 11 (Q43653) => July 19, 1969, 21:44 UTC; Gliese 876 d (Q869944) => 2,450,602.093 HJD (!!)
Proposed byPaperoastro (talk)
Discussion

Epoch is the seventh parameter of an orbit: it is necessary to define an orbit. In this proposal I'd like to discuss:

  1. we need a new property (this) or we can use point in time (P585)?
  2. epoch refers to 6 orbital parameters: how to join them?
  3. for spaceflights and artificial satellites the epoch is expressed in usual calendar unity; for extrasolar planet in Julian day or some its variants. How to solve it?

Paperoastro (talk) 12:32, 25 October 2013 (UTC)[reply]

  •  Support It might be useful to have a specific property because it can be further developed to have customisations and different representations (J2000, TT, etc.). As for bundling orbit parameters, one possible solution is to have an item to represent the orbit and link it with a property "orbit parameters". --Micru (talk) 20:37, 12 November 2013 (UTC)[reply]
  • I am not an astronomer and having read the en:Epoch (astronomy) article I am still confused.
On the one hand epoch refers in some way to unusual ways for expressing calendar dates - for these we could use the current wikidata time variable type and ask the devs to offer alternative ways of displaying this at some future date
on the other hand it seems to refer to unusual units of time (Julian years and Julian days) - for these we can use seconds until the devs get round to creating alternative units of time
on the third hand it refers to IAU standards - we can create items for these
What have I misunderstood? Filceolaire (talk) 13:28, 3 June 2014 (UTC)[reply]

Contact times of eclipses

[edit]
waiting for datatype
   On hold
DescriptionContact times of eclipses: P1, U1, U2, U3, U4, P4
Data typePoint in time
Domainlunar and solar eclipses
Allowed valuestime in UTC
Example6 April 2015, 03:22 UTC. qualifier <applies to part:U4 - solar eclipse>
SourceWikipedia list article, e.g. en:List of 21st-century lunar eclipses
I have amended the example as I understand it should be used. Please check I got it right.
Can this property be extended so it can be used on solar eclipses as well? Creating a property that can only be used on lunar eclipses seems a bit narrow. Filceolaire (talk) 00:10, 29 April 2015 (UTC)[reply]
Yes, I believe this is correct (see en:Solar eclipse of August 11, 1999#Notable times and coordinates for example. I will ask someone more knowledgeable to comment here. MSGJ (talk) 09:52, 29 April 2015 (UTC)[reply]
P1-4 and U1-4 apply to solar and lunar eclipses, but differently. A solar eclipse is a en:Transit (astronomy) so the timing is based on the viewing location INSIDE a shadow, while a lunar eclipse has viewers looking at an object INSIDE a shadow, so everyone sees the same appearance at the same universal time. So knowing the P1-4,U1-4 times for a solar eclipse are less useful for any given observer. Tomruen (talk) 01:08, 30 April 2015 (UTC)[reply]
If U4 for a solar eclipse is different from U4 for a lunar eclipse then we should have separate items for these with the "applies to part" qualifier linking to the appropriate item in each case. This means this property could be used for solar eclipses if we just change the label. I would  Support this property if you made this change to the property label and description. Filceolaire (talk) 03:04, 30 April 2015 (UTC)[reply]
Could you explain what you mean by "This means this property could be used for solar eclipses if we just change the label." Does that mean that properties can have more than one label? Or do you mean that you could have two statements for "subject item of this property"? Or do you mean something else? MSGJ (talk) 12:24, 30 April 2015 (UTC)[reply]
Rename the property as "Contact time for eclipses". Change the description to "Contact time for lunar and solar eclipses (U1, U2 etc. lunar and U1, U2 etc. solar)". Filceolaire (talk) 16:41, 30 April 2015 (UTC)[reply]
✓ Done, although no corresponding items created yet MSGJ (talk) 09:22, 5 June 2015 (UTC)[reply]
I ammended the example a little. I think this is good now and support - as my comment above. Joe Filceolaire (talk) 16:48, 12 September 2015 (UTC)[reply]

Awaiting IP Address ranges datatype

[edit]
Agreed to be created; waiting for IP Address ranges datatype

IP address or range

[edit]
Originally proposed at Wikidata:Property proposal/Organization
   On hold
Descriptionsingle IP address or range of IP addresses
RepresentsIP address (Q11135)
Data typeIP address (phab:T235389)-invalid datatype (not in Module:i18n/datatype)
Domainorganization (Q43229),
Example 1University of Oxford (Q34433) → 2001:630:440::/44
Example 2Wikimedia Foundation (Q180) → 198.35.26.0/23
Example 3Johns Hopkins University (Q193727) → 128.220.0.0/16
Example 4University of Chicago (Q131252) → 2a03:b600:640::/107
Planned useMove existing values of IPv4 routing prefix (P3761) and IPv6 routing prefix (P3793) into the new field
See alsoIPv4 routing prefix (P3761) and IPv6 routing prefix (P3793)

Motivation

[edit]
Tracked in Phabricator
Task T235389
I would like to make a tool in toolforge that will allow a user to input an IP address and get the organization (Q43229) associated for that IP address. Unfortunately, you cannot query a range unless you have the start and end of that range. Based on the discussion in the previous proposal it seems best that a new datatype would be created for this property, one that extends from Quantity. Then organizations will be able to be queried by the IP address. U+1F360 (talk) 20:59, 1 November 2019 (UTC)[reply]

Discussion

[edit]

Awaiting support for lexeme datatypes on Commons

[edit]
Agreed to be created; waiting for support for lexeme datatypes on Commons

depicts lexeme form

[edit]
Originally proposed at Wikidata:Property proposal/Sister projects
   On hold
Descriptionlexeme form depicted in the media file
Data typeForm
DomainCommons images
Example 1File:Bandera_de_los_Treinta_y_Tres_Orientales.JPG → L562031#F1 invalid ID (L562031#F1)
Example 2File:Protests_in_Puerta_del_Sol,_Madrid_-_Ahora_o_Nunca.jpg → L56980#F1 invalid ID (L56980#F1)
Example 3File:BULLSHIT_rubber_stamp_(mirrored)_on_the_desk_of_a_street_photographer.jpg → L299205#F1 invalid ID (L299205#F1)
Example 4File:Mrs._Susanna_Morin_Swing_160028v.jpg → L9656#F1 invalid ID (L9656#F1)
Example 5File:Vignet_Ende.jpg → L29356#F1 invalid ID (L29356#F1)
See alsodepicts (P180)

Motivación

[edit]

In Wikimedia Commons there are thousands of images depicting lexemes (a few of them: c:Category:Images by text, not categorised by language yet). Creating a property to indicate the lexemes depicted in a file would be great (IMHO) with regard to structuring linguistic data in media files. This was posted here. Apparently this was also proposed here a few months ago. strakhov (talk) 16:06, 16 July 2022 (UTC)[reply]

Discussion

[edit]

 Comment To make this really useful, wouldn't it be better if it was "depicts lexeme form"? That way, we would capture more specifically what is on the image. Ainali (talk) 17:31, 16 July 2022 (UTC)[reply]

Is it only for qualifiers? What if we want to add it as a statement to 🆓 (Q87576444), for example? AntisocialRyan (Talk) 18:14, 17 July 2022 (UTC)[reply]
@AntisocialRyan: In fact this property is not intended to be used as a qualifier, but as a main statement. But not (at least not mostly) here, but in Wikimedia Commons, with media files. strakhov (talk) 16:10, 18 July 2022 (UTC)[reply]
Oh, I see, I misunderstood the examples.  Support. AntisocialRyan (Talk) 17:00, 18 July 2022 (UTC)[reply]
@ChristianKl: with regard to the description, mirroring P180's English description, "word visually depicted in an image, see also P180 for entities depicted" may work (?). But please feel free to propose a better one.
With regard to what's valid and what not... I guess it's valid when the lexeme form is depicted in the file. Since depicts (P180) has no indication for what's not valid and what is valid, I do not know why this one would need such prescription. Use of P180 is at the discretion of the user and common sense. Anyway, if you believe there are situations when a form is depicted in a file but using this property would not be valid, please indicate them here. strakhov (talk) 15:59, 18 July 2022 (UTC)[reply]
@Strakhov: How is a person supposed to decide whether to use items or lexemes to tackle descriptions? ChristianKl ❪✉❫ 10:23, 19 July 2022 (UTC)[reply]
@ChristianKl: When depicts (P180) should be used and when not IMO falls under the scope of that property (not this one's), and IMO we cannot decide that here (it's a bit tricky and there are still discussions in Commons about when it's appropiate and when not). Anyway, for example, IMHO in the file c:File:Spain Poznan Spain could by You.jpg it would ok using "depicts lexeme form" = L254265#F1, but it would not be ok using depicts (P180) -> Spain (Q29) (the image is not even taken in Spain, but in Poland). On the contrary, in the file c:File:A.L. Hickmann's geographisch-statistischer universel-Taschen-Atlas. 1900 (80112515).jpg IMHO would be "OK enough" using "depicts lexeme form" = L36513#F1 and depicts (P180) -> Spain (Q29) (both properties). strakhov (talk) 15:20, 19 July 2022 (UTC)[reply]
@Jheald: inscription (P1684) is for entities, concepts, etc, not text: it's language independent, it does not capture different languages being used nor synonyms in the same language (but it captures senses). I guess the problem with someone adding a lot of "depicts lexeme form" statements is not different to someone adding too many P180/P1684P6568 statements (that properties could also be abused). Anyway, if someone believes a big "please, do not try to transcribe full book/newspaper pages such as this one while using this property, try to use common sense" is needed... Cheers. strakhov (talk) 15:59, 18 July 2022 (UTC)[reply]
 Comment Sorry, I confused inscription (P1684) with inscription mentions (P6568). strakhov (talk) 14:51, 19 July 2022 (UTC)[reply]
You are absolutely right about this proposal not relating to that property. My bad, I did not consider that one. Well, I guess inscription (P1684) is good for transcribing full sentences (they can be added in the file description, file caption, as free text,... too). But it's pretty bad when it comes to crosslinking Wikidata Lexicographical data and Wikimedia Commons. I am interested in the latest. strakhov (talk) 15:20, 19 July 2022 (UTC)[reply]
  •  Support with the change to lexeme form, great! Ainali (talk) 08:32, 31 August 2022 (UTC)[reply]
  •  Support in thinking about this, this would open up some interesting possibilities. If we want to document information about what a word looks like written by hand, which can often differ from the digital representation, this would be useful for linking photos showing this to lexeme forms. I uploaded an example of سلسہ just now which I would add this property to if available.
 – The preceding unsigned comment was added by Middle river exports (talk • contribs).
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Pending&oldid=2195836150"