[okfn-labs] Calendar fields (date/time)

Sat Feb 22 22:07:14 UTC 2014

A couple of points/questions,

On 21 February 2014 17:32, Rufus Pollock <rufus.pollock at okfn.org> wrote:
[snip]
>
> I like this proposal a lot but there are certain questions I have:
>
> - What do data packagers do with time series data they get that is just a
> year (e.g. as in your example of bond yields). Personally i've found myself
> more and more just converting these to actual dates e.g. 2004 => 2004-01-01,
> 2004 Q3 => 2004-10-01 etc. This means you get a real date but at the cost of
> adding some precision that wasn't really there.

I also follow this approach. For a cartodb-based project recently; I
wanted real dates but also only had years for *some* entries. My
simple approach had a "year only" boolean column, if true the
visualization only showed the year part of the date.... not ideal

[snip]
>
> So, to summarize: I agree with making the change you propose re types - are
> you happy to open an appropriate issue re JSON Table Schema on
> https://github.com/dataprotocols/dataprotocols/issues
>
>>
>> Information that a field contains a year or any other combination of
>> calendar units should be in some kind of analytical metadata. We don't have
>> to define them yet, as they might be very case-specific.
>
>
> I think string plus pattern/format attribute should be ok for this. I also
> note we have a units spec http://dataprotocols.org/units/ (not much used yet
> and not formally integrated into JSON Table Schema but it could be)

Just to check I understand, Rufus, your proposal is to always require
a full (date)(time) in a full format (agreeing with Stefan) but then
to use a format specifier to specify which elements are actually data
that should be used?

One other possibility would be to consider adding year, month and
yearmonth types. It's probably too much, but on the other hand only an
extension of the concept of date, time and datetime. I suspect there
are many open data sets where year meaning "the whole year" is used.

Matt

>
> Rufus
>
> [snip]
>
>
> _______________________________________________
> okfn-labs mailing list
> okfn-labs at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-labs
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-labs
>