"The views of space and time which I wish to lay before you have sprung from the soil of experimental physics, and therein lies their strength. They are radical. Henceforth space by itself, and time by itself, are doomed to fade away into mere shadows, and only a kind of union of the two will preserve an independent reality."
Hermann Minkowski, 01809
Time and Space
In the previous post I surmised that current temporal standards offer poor support for historical data. I also know that modelling time at deep timescales is going to throw up some new problems. The thing is, once you start messing around with time outside of historical systems like calendars you run into another dirty little secret. Time and space are related. We've known this for over a hundred years but temporal specs are all geared towards events in the short now, so fiddly little problems like relativity are conveniently ignored.
Even if I ignored relativity, I can't ignore space. Recent temporal innovations like daylight saving time and the timezone system are all local modifiers based on spatial coordinates. What I find odd is that I haven't encountered a single specification that tries to treats time and space equally.
The German mathematician Hermann Minkowski (1869 - 1909) was the first to formalise the notion that space and time are not separate. He proposed that the best way to understand Einstein's special theory of relativity was to use a 4 dimensional space he called spacetime. It's often referred to as Minkowski spacetime to differentiate it from a slew of other modern multi-dimensional theories.
Getting your head around the ideas of relativity and spacetime isn't as hard as you might expect. I found some great articles here that walk you through all the concepts using simple examples. Getting my head around the mathematics of spacetime is another thing entirely!
Minkowski image via AIP Emilio Serge Visual Archives
Getting external data into Herodotus is an important part of the project. Data can be encoded in a wide array of formats and they all have to be parsed into Actionscript Value Objects. I've yet to define the metadata for these VOs so in an effort to find some commonality I spent much of the last few months digging through a mountain of temporal specifications, projects and APIs. It's been hard work and a journey peppered with surprises and revelations. Over this and the next two posts I hope to cover some of what I've learned and how this has shaped my semantic model of time.
The semantics of time
The properties of time are elusive. It's a fundamental concept with a myriad of definitions, each dependent upon the experiences and requirements of the individual or group who defines it. Disciplines as diverse as physics, chemistry, biology, astronomy, theology, philosophy, history, music and politics have all had a hand in shaping our definitions of time.
It's fascinating to watch different people approach the same problem. Some attempts make you want to scream "oi, no!", and others have you immediately reaching for your notebooks; throwing out old ideas in favour of new, each revelation informing your overall understanding of the problem.
The fundamentals and architecture of time require some deep thought and on the whole this is evident in the specifications I looked at. The introduction to the ISO8601 specification gives a good introduction to the basic temporal concepts of a Timeline, an Instant and an Interval. The Time ontology in OWL describes them in a little more detail. These three concepts seem to be universally applied or at least implied in all of the specs I looked at.
Old Father Time: ISO8601
In a review of Temporal Web Standards I showed that almost all web standards for DateTime have their roots in the ISO8601 specification. This was great because it gives me the commonality I was looking for.
Unfortunately this common ancestry throws up another problem, but before I get into that it's worth noting the main innovations to take from ISO8601:
When date and time are represented as strings they are formatted in order of granularity, from largest to smallest. This offers the following advantages:
Now for the bad news. ISO8601 models our modern civil "Gregorian" calendar. Introduced in the Inter gravissimas papal bull by Pope Gregory XIII this system of measuring time reformed the earlier Julian calendar. The difference between the two calendars is small - only a slight change to the leap year rule to correct the drifting date of Easter. In software terms the Gregorian calendar would be considered a patch: it's Julian 1.1.
The problem of dating historical events with ISO8601 is really one of practicality. The reform came into effect, in Catholic countries at least, in 1582. The thing is (rather obviously) a lot of history happened before then. These sorts of dating problems aren't new to historians but the conversion to Gregorian, and often back again, can be non trivial.
For example, meet Tom. Tom is a historian studying the French Revolution. He has found a date on a document that uses the short-lived put completely wonderful French Republican calendar. The FRC was a metric calendar (10 days in a week, 10 hours in a day etc.) adopted very briefly alongside the rest of the metric system. If Tom wanted to store information on the web about this document he would have to convert the date from French Republican to Gregorian.
The Proleptic Gregorian Calendar
The common response of spec writers to the problem of historical dating is to use the proleptic Gregorian calendar. A proleptic calendar is one in which the calendar rules are extended backwards in time before when the calendar was introduced. Now this sounds like a great idea until you actually try and use it.
Meet Tom again. This time he is studying the life of Julius Caesar. Caesar was born when one of many permutations of the Roman calendar was in effect, and he died two years into the counting of his eponymous Julian calendar. Dates in his life require conversion from at least two different calendar systems into the proleptic Gregorian. Just to add to the complexity all of those dates are considered BC in the Julian/Gregorian calendars. While most implementations of proleptic Gregorian (including ECMAScript) happily count zero and on into negative numbers, the proper BC/AD (or BCE/CE if you prefer) system doesn't count a year zero. 1AD is preceded by 1BC. Conversions like this are complex and error-prone. I really don't think the proleptic Gregorian is a very practical storage solution.
As if I haven't rammed the point home enough then consider a further example. Meet Dick, he's a geologist studying the Cretaceous Tertiary boundary. What is 65.5 million years ago in Gregorian? It's all a bit fuzzy. Don't even bother asking Harry the cosmologist.
Once you realise there is no practical support for historical events prior to 1582 it quickly becomes obvious why we don't yet have a deep-zoom for history. No online support = no online data. To pull this off I need a model of time (and space, but I'll get into that later) that goes back beyond the common Gregorian calendar and in fact beyond any calendar into the timescales of geology and cosmology.
Open Knowledge Conference 2009
A few weekends ago I gave a short talk about The Computus Engine at the Open Knowledge Conference in London. It was interesting to attend a con outside of the usual Flash circuit, and with Open Knowledge being so 'em... open, it meant there was a wide range of topics under discussion. I missed the first part of the day but in the afternoon we were treated to everything from open source fashion (image below), to aid work in Africa, to the intricacies of semantic markup.
The open philosophy is applied to the con as well as the subject matter. Much like BarCamp, speaking slots can be added to the schedule by audience members. Fitting everything in meant I rattled through mine at breakneck pace but I think I got my points across. I've submitted the slides to Jonathan Gray at The Open Knowledge Foundation and I'm told they have audio as well. If they put them up online I'll post a link.
New class documentation
I finally got round to configuring ASDoc (the Actionscript class documentation generator) in FlexBuilder. It's notoriously painful to configure but thanks to my friend Seb for publishing his efforts it gave me enough clues to get mine up and running. Since then I've worked my way through the current set of classes and marked them all up. Taking another tip from the PV3D team I'm checking the docs into the repo alongside the code so they'll always be in sync with the codebase.
GoogleCode repo updates
Yesterday I checked in a stack of updates to the Computus Engine repo on GoogleCode. In addition to the ASDoc markup and docs directory you'll also find updated examples for the Animated Main Preloader and the Timekeeper. The preloader now has a fix to resolve the problem of it stalling if the SWF is already cached.
More importantly I've made a change to the Timekeeper API. I've replaced a number of methods with single properties to reduce the complexity of the API. The affected methods are:
value:Number replaces getValue() and setValue()
tickDuration:Number replaces getTickDuration() and setTickDuration()
tickFrequency:int replaces getTickFrequency() and setTickFrequency()
I don't like changing a live API but I think these changes are sensible and greatly simplify things. The Timekeeper test example has been updated to use the new API.
A S.T.A.R. is born
Eagle eyed visitors will also spot a new set of unit tests and util directory called star. More about this in a forthcoming post!
The semantics of time have been defined by just about every standards body you can shake an egg timer at. Even within the internet space you will find overlapping definitions and specifications from ISO, ECMA, IMC, W3C, IETF and the Dublin Core Metadata Initiative. And that's without getting into individual language APIs, frameworks and data models. Oh yeah and just for kicks, some standards contain their own temporal entities and definitions.
This is the grandaddy of all temporal web standards and you'll find it referred to in every other specification. Originally released in 1988, ISO8601 defines a range of textual formats for the interchange of dates, times and time periods.
For all it's ubiquity, it is not without it's problems: parametrization can be a little loose. For example it'll accept hour values between 0 and 24, and early versions were comfortable with the dropping of centuries from year definitions.
In reality no-one implements all of ISO8601 - it's just too loose to be practical. What happens is, a standards body defines a subset (or "profile") of the full standard, and sometimes another standard will include or be based upon a child standard. The diagram below shows the ISO8601 family tree of adoption.
For an overview of the various formats check out HackCraft's Date and Time Formats on the web.
When the W3C came to define their date and time standards they very sensibly choose to adopt a profile of ISO 8601. Favouring reliability over flexibility, they achieve this by enforcing a stricter simplified subset of ISO 8601.
The W3C's specification for RDF semantics contains a recommended XML datatype for date time: xsd:dateTime. This is also a profile of ISO 8601 and can be use to express a W3C-DTF in the XML format.
IETF RFC 3339
The Internet Engineering Task Force took a similar approach when defining RFC 3339 Date and Time on the Internet: Timestamps. This standard enforces a subset of W3C-DTF and is consequently the simplest of the three formats.
It's worth noting therefore that any date conformant with RFC 3339 will also be valid in W3C-DTF and ISO 8601. This was the primary reason for adopting it as the date time format for Atom syndication. Talking of syndication, beware of the older RSS specification which uses the same archaic datetime format used by email and HTTP. You can find this specified in RFC 822 and modified in 1989 by RFC 123 to enforce four digit years.
The original internet calendaring standard was vCalendar. This and vCard were co-developed initially by Apple, AT&T, IBM, and Siemens, before being passed to the Internet Mail Consortium in 1996. This textual format can contain temporal and descriptive data about an event or task.
iCalendar ( RFC 2445 )
In many respects iCalendar can be considered vCalendar 2.0. It supports all the features of vCalendar and has a similar textual structure. The advantage of using iCalendar over it's predecessor is that you can also exchange journal entries and information about the free-busy status of an entity.
This is a microformat implementation of iCalendar. Microformats are small XML documents that can be easily embedded, read and exchanged across the web. The microformat datetime-design-pattern page hosts an interesting discussion about the need for a machine and human readable date time format.
This is a proposed XML implementation of iCalendar.
This is a proposed RDF implementation of iCalendar.
There is currently no support for temporal elements in HTML, but one of the proposals in HTML 5 is for a time element. This would support dates and times in the Gregorian calendar as well as timezones.
I've made a few changes and updates to the site over the last few weeks. I thought it might be worth posting a quick update.
This project now has it's own page and the BaseComponent class is checked into the repo. I've made a couple of updates to the code since the ahem, "finished" version I posted a few months back. Firstly I've added Grant Skinner's EventDispatcher optimization. And the second is a workaround for a weird bug in the Flash Player.
It turns out that a stage resize can fire the ADD_TO_STAGE Event twice. This causes the BaseComponent init() to be called twice. I didn't notice it when working with components on the Flash timeline but it becomes really obvious if you use it on an Actionscript only project in FlexBuilder. The fix is to remove the listener after the first event is fired.
This project also has it's own page and the Timekeeper class is in the repo now as well. I've built a new combined example to go along with it. If you're interested in music sequencing you might like to check out Studio Anuirin's remixed version of the Timekeeper class.
This is the current project I'm working on. The first two base classes are built and they happily pass all the unit tests I can throw at them. Although it's early days for this one I'm inclined to open it up as soon as possible to get some feedback. I'll put a proper post together about it soon.