Wikifunctions:Type proposals/Wikidata value
There are many data types supported by Wikidata. This type proposal proposes representations for the ones that have their own structure.
(For string-based types, see Wikifunctions:Type proposals/Wikidata string-based value)
Geographic coordinate
Structure
As we do not have a float type yet, I have proposed using the string type.
We will copy Wikidata's structure:
Key | Label | Type |
---|---|---|
K1 | latitude | Z6/String |
K2 | longitude | Z6/String |
K3 | precision | Z6/String |
K4 | globe | Ziii/Wikidata item |
Example values
{
"type": "Wikidata geographic coordinate",
"latitude": "52.516666666667",
"longitude": "13.383333333333",
"precision": "0.016666666666667",
"globe": "Earth"
}
|
{
"Z1K1": "Zggg",
"ZgggK1": "52.516666666667",
"ZgggK2": "13.383333333333",
"ZgggK3": "0.016666666666667",
"ZgggK4": "Q2"
}
|
Validator
The validator ensures that:
- That the numeric strings are valid numbers
Identity
Two quantities are the same if they have the same representation
Converting to code
Python
It will be represented as a custom class
JavaScript
It will be represented as an object
Renderer
In the beginning, there will be no renderer, instead the standard tree structure will be outputted. In the future, we hope to be able to copy Wikidata's renderer
Parsers
In the beginning, there will be no parser, instead the standard tree structure will be shown and the user can input values as normal. In the future, we hope to be able to copy Wikidata's renderer
Quantity
Structure
We will copy Wikidata's structure:
Key | Label | Type | |
---|---|---|---|
K1 | amount | Z6/String | |
K2 | lowerBound | Z6/String | Optional |
K3 | upper bound | Z6/String | Optional |
K4 | unit | Ziii/Wikidata item | Optional |
The unit will not exist as a key if the unit is "1"
Example values
Value 42
{
"type": "Wikidata quantity",
"amount": "42"
}
|
{
"Z1K1": "Zqqq",
"ZqqqK1": "42"
}
|
Value 18.38±0.005 km2
{
"type": "Wikidata quantity",
"amount": "18.38",
"lowerBound": "18.375",
"upperBound": "18.385",
"unit": "square kilometer"
}
|
{
"Z1K1": "Zqqq",
"ZqqqK1": "18.38",
"ZqqqK2": "18.375",
"ZqqqK3": "18.385",
"ZqqqK4": "Q712226"
}
|
Validator
The validator ensures that:
- That either both upperBound and lowerBound exists or neither exist
- That the numeric strings are valid numbers
Identity
Two quantities are the same if they have the same representation
Converting to code
Python
It will be represented as a custom class
JavaScript
It will be represented as an object
Renderer
In the beginning, there will be no renderer, instead the standard tree structure will be outputted. In the future, we hope to be able to copy Wikidata's renderer
Parsers
In the beginning, there will be no parser, instead the standard tree structure will be shown and the user can input values as normal. In the future, we hope to be able to copy Wikidata's renderer
Point in time
Structure
We will copy Wikidata's structure:
Key | Label | Type |
---|---|---|
K1 | time | Z6/String |
K2 | precision | Z6/String |
K3 | calender model | Ziii/Wikidata item |
The time type has several unused fields: time zone is always 0 and before and after are completely unused.
Example values
December 31, 2001 with day precision
{
"type": "Wikidata quantity",
"time": "+2001-12-31T00:00:00Z",
"precision": "11",
"calendermodel": "proleptic Gregorian calender"
}
|
{
"Z1K1": "Zttt",
"ZtttK1": "+2001-12-31T00:00:00Z",
"ZtttK2": "11",
"ZtttK3": "Q1985727"
}
|
Validator
The validator ensures that:
- The time field is a valid ISO 8601 time
- That the precision value is less than 12
- The calender model is either proleptic Gregorian calendar (Q1985727) or proleptic Julian calendar (Q1985786)
Identity
Two quantities are the same if they have the same representation
Converting to code
Python
It will be represented as a custom class
JavaScript
It will be represented as an object
Renderer
In the beginning, there will be no renderer, instead the standard tree structure will be outputted. In the future, we hope to be able to copy Wikidata's renderer
Parsers
In the beginning, there will be no parser, instead the standard tree structure will be shown and the user can input values as normal. In the future, we hope to be able to copy Wikidata's renderer