Wikidata talk:Property proposal/Pending

StringValue

It seems that StringValue data type is available! Special:NewProperty --Viscontino ^talk 21:28, 6 March 2013 (UTC)

TimeValue

As far as I see TimeValue will come. For me the problem is that not every date or time can be given exactly. E. g.:

1. "1604": Only the year is known.
2. "Born around 400": The date can be in the 4th century as well as in the 5th century.
3. "Died in the 7th century BC": Century is fix but year isn't known exactly.
4. "Founded on December 18th, 1891 or 1892": Day and month are well known but year in uncertain.
5. "Every full hour": The event is repeating.
6. "Every year since 1925 but not from 1940 till 1946": Repeating with a startingpoint and exceptions.
7. "Year of extinction unknown": The point in time is completely uncertain.

As far as I understand TimeValue the first and the third case seems to be easy. But the rest? --Duschgeldrache2 (talk) 22:41, 10 March 2013 (UTC)

Haven't thought about this yet. We probably have to distinguish between the values for these different types as necessary, include multiple values in one statement and leave out the unknowns. As for your example:

date	1604
date of birth	ca. 400
date of death	7th century
date of foundation	18th December 1891 1892 (would have to interpret as possible values)
interval	full hour (not sure about this one)
date	since 1925 until 1939 since 1947 until now (would have to interpret as time span with an exception)

Resulting in different groups of time values, from minute up to century (or even geographical time spans) and each as basic, ca., since/until... now that I think of it: Would be necessary to distinguish between two (or more) possible dates (as above; so possibly 1891 and possibly 1892) and two actual events (things can happen more than once); also, for uncertain dates (e.g. birth dates in the middle ages) there is often information like between ... and ... but I'm unsure how to implement it, maybe: after ... and before ...

So, I'm strictly against mixing different types of time values, because for instance 6th December 1965 is a subset of December 1965 is a subset of 1965 ... Also, I see no use in creating tons of interval values like since 1st July 1499 05:32 until 13th March 1783 18:09, since this can be done by combining start and end dates as proposed above.

It sure is a lot of work to implement a consistent system. Any thoughts? 23PowerZ (talk) 08:36, 14 March 2013 (UTC)

One more question: what about different calendars? For example, various countries switched from the Julian to the Gregrorian calendar at different times, so many articles state both the Julian calendar date as well as the corresponding Gregorian calendar date. And we sometimes use dates in other calendars such as the chinese, hebrew, hindu, islamic or mayan calendars as well. Should these dates be stored separately, or should they rather be stored as Gregorian calender dates and converted locally via templates? --Kam Solusar (talk) 16:09, 4 May 2013 (UTC)

Order of datatypes coming

For your information. I asked Denny_WMDE about the order witch datatypes are comming next. He says it's not sure now, but probably the order will be:

• numbers
• Geocoordinates
• Time
• Number with Units
• Multilanguage Text
• Geoshapes

-- MichaelSchoenitzer (talk) 13:39, 12 March 2013 (UTC)

What is the use of this page?

Hi!

Why copying positive proposals from Wikidata:Property proposal to here? If a proposal has enough agreement, then it can be created directly.

Issue: What if properties listed as “pending“ need further discussion? (E.g. I would like to change Charge to Electric charge) Change it here without discussion?

Confused--Svebert (talk) 13:23, 14 March 2013 (UTC)

Not all data types for properties are available in the software yet. For example, you can't create a property that uses a date or a number. That is why they are pending. As for renaming a property, that is relatively simple and can be done after it is made, so I suggest waiting, or alternatively be bold and go change the proposed name on the page. Espeso (talk) 14:58, 14 March 2013 (UTC)

ok, thanks. That makes sense :-)--Svebert (talk) 18:21, 14 March 2013 (UTC)

New data types

When will new data types come to the software?--Kozuch (talk) 18:33, 27 March 2013 (UTC)

Contesting pending properties

I see a "building height" and a "road length" properties that I am fairly sure should be changed to just "height" and "length", and I am fairly sure many users would agree with me, should I move back those properties to proposals ? --Zolo (talk) 06:55, 2 June 2013 (UTC)

Types with(out) Phab tickets

In my opinion, types which do not have a phabricator task, or which have a declined phabricator task, should not have sections devoted on this page. Given that opinion, I boldly removed the "boolean" type, as there is no Phabricator ticket dedicated to the type. There may be others.... @Lydia Pintscher (WMDE): Do you know of tasks for each of these types? --Izno (talk) 16:42, 3 June 2016 (UTC)

The ones we have should all be subtasks of phabricator:T91505. --Lydia Pintscher (WMDE) (talk) 17:11, 3 June 2016 (UTC)

@Lydia Pintscher (WMDE): Thanks, that got two of them, and then I was able to find one related to the time precision. --Izno (talk) 17:36, 3 June 2016 (UTC)

Geoshape datatype already deployed

There are a couple of pending properties awaiting the geo-shape type ("KML link" and "Sandbox-Geographic shapes"), and the datatype has been already deployed to Wikidata, so maybe it's time to create them. Currently, there is just a single property with this datatype: geoshape (P3896), maybe the "KML link" should be rediscussed, but I think should be no problem on creating the sandbox property. —surueña 07:49, 30 May 2017 (UTC)

The Sandbox type has been created as Sandbox-Geographic shape (P4047), so I'm removing it from the list of Pending properties. @Scott5114: And there is no exactly a "KML link" property already but I think the following ones are equivalent:

• geoshape (P3896) stores geographic data in Commons (but is in JSON format instead of KML)
• KML file (P3096) stores a KML file to be linked from Template:Attached KML (Q6690822) (but has Item datatype, instead of geoshape)

Both properties should fulfil the needs of the proposed "KML link", so unless there is no objection I'll remove it to from the list of Pending properties. —surueña 05:49, 12 June 2017 (UTC)