Re: [Wikidata-l] Locations and times

The input 1920s should be supported. On Fri, Jan 4, 2013 at 2:55 PM, Dennis Tobar wrote: > Hi, > > Thanks for the clarification. This is an ultra-low feature, and as I said: > this is only an [optional] feature for importing from data from sql or > similar and not for humans. > > Regards. > > >

Re: [Wikidata-l] Locations and times

Hi, Thanks for the clarification. This is an ultra-low feature, and as I said: this is only an [optional] feature for importing from data from sql or similar and not for humans. Regards. On Fri, Jan 4, 2013 at 8:50 AM, Denny Vrandečić < denny.vrande...@wikimedia.de> wrote: > The problem is is

Re: [Wikidata-l] Locations and times

I would say an error; that's more likely to be a typing error than a genuine but bizarre formatting decision. On 4 January 2013 13:37, Denny Vrandečić wrote: > Should the coordinates "456,-234" be understood as 84, 126, or should they > just be an error? > > > 2013/1/3 Andy Mabbett >> >> On 3 Ja

Re: [Wikidata-l] Locations and times

Should the coordinates "456,-234" be understood as 84, 126, or should they just be an error? 2013/1/3 Andy Mabbett > On 3 January 2013 16:11, Denny Vrandečić > wrote: > > > What it currently does not do is: > > > * enable dates like "Date of birth: 437-436 BC" > > That'a complex issue, but so

Re: [Wikidata-l] Locations and times

Whereas I would agree in the case of a calendar, in case of Wikidata I would think there are many historical dates. If someone enters "12", I would assume "the year 12 AD" and not "December 2013" or "January 12th, 2013". Also, since we show the interpretation immediately and the editor has direct

Re: [Wikidata-l] Locations and times

while i like your arguments generally a lot, this one i find not intuitive. imo the best guess is context dependent, and most likely the context is "now", i.e. current year. On Fri, Jan 4, 2013 at 12:53 PM, Denny Vrandečić wrote: > If you enter "15. Jan 2013" it will know the difference. The goal

Re: [Wikidata-l] Locations and times

Oh Horatio! Yes, that should be accepted too. Adding it to the todo list :) 2013/1/4 swuensch > I tried the coordinate tool with a cordinate i found on geocaching.com "N > 48° 22.250 E 010° 53.777" the problem is the parser needs data in the > formate "48° 22.250 N 010° 53.777 E". There should

Re: [Wikidata-l] Locations and times

It doesn't do time yet. Once it will, those should be parsed (if you give a date too -- i.e. 2:34:06pm is not a point in time, only together with a year and month and day it would be one). Regarding the last line, 2004-01-01 is being parsed. 2004-01-01T11:20:10Z is not yet, because we don't do pre

Re: [Wikidata-l] Locations and times

If you enter "15. Jan 2013" it will know the difference. The goal of the datatype is to understand a point in time within a given precision. 15th of January is not a point in time, it is a recurring date, and therefore not in the domain of this datatype (just as "Easter" is not, nor "Sunday"). The

Re: [Wikidata-l] Locations and times

The problem is is that 20120101 is ambiguous -- it could be either the year 20120101, or the 1st of January of last year. Whereas admittedly it is more likely to be the latter, it might be considered a bit too much magic to guess 2101 as the first of January of 2000 and 2000 as "in 20 Mio

Re: [Wikidata-l] Locations and times

We have an own datatype planned for shapes, probably something based on the GeoJSON. The alternative would be just to point out to the respective entities in OSM, but OSM has a policy against stuff like "historical country borders" or "geographic range of the long-eared hedgehog", so it is a good i

Re: [Wikidata-l] Locations and times

Yes, I knew EDTF, it came up in the previous conversation. Actually, it would be nice to add an EDTF export. (adding to TODO). Re Error detection: yes, that's true. Probably should be there. Adding to todo. (I am not so much worried about error detection, but rather about error reporting...) 20

Re: [Wikidata-l] Locations and times

I tried the coordinate tool with a cordinate i found on geocaching.com "N 48° 22.250 E 010° 53.777" the problem is the parser needs data in the formate "48° 22.250 N 010° 53.777 E". There should be an autodetection to accept both inputs. Sk!d On Thu, Jan 3, 2013 at 5:11 PM, Denny Vrandečić < denn

Re: [Wikidata-l] Locations and times

Some time specifications that aren't parsing: 2:34:06pm CDT 10pm 2004-01-01T11:20:10Z Meng On Thu, Jan 3, 2013 at 8:11 AM, Denny Vrandečić < denny.vrande...@wikimedia.de> wrote: > Hi all, > > continuing from last weeks data values discussion, I would like to invite > comments on the following

Re: [Wikidata-l] Locations and times

It should know the difference between "15. Jan" and "15 Jan". If the dot is submitted it is not a year its a day (15th of January https://www.wikidata.org/wiki/Q2260) Sk!d On Thu, Jan 3, 2013 at 5:11 PM, Denny Vrandečić < denny.vrande...@wikimedia.de> wrote: > Hi all, > > continuing from last we

Re: [Wikidata-l] Locations and times

Hi, I'm testing the timestamp format and I note that doesn't support date in ISO basic format (ISO 8601), as is documented in MS SQL Server pages: mmdd[1][2] (yes, without separator string). The expected value to 20120101 is Jan 1, 2012, but the script returns this json { "time": "+000201

Re: [Wikidata-l] Locations and times

Hi guy! The prototype is very good. But usually the locations described in wikipedia does not boil down to points, they also include polygons (administrative divisions) and lines (streets). But due to the inability to easily describe such coordinates such description is made using images [1]. I won

Re: [Wikidata-l] Locations and times

On 3 January 2013 16:11, Denny Vrandečić wrote: > What it currently does not do is: > * enable dates like "Date of birth: 437-436 BC" That'a complex issue, but some interesting work on a draft standard, has been done at Also, there's no error detection

[Wikidata-l] Locations and times

Hi all, continuing from last weeks data values discussion, I would like to invite comments on the following prototypes for understanding points of time and points on Earth. What it currently does not do is: