• Home
• About
• Articles
• Contact
• Downloads
• Glossary
• Links
• Projects

Revelation

Posted on May 14, 02009
Filed Under Development, Drake, Herodotus, Journal, Kepler, Latham | Leave a Comment

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:

• Dates are human readable.
• Dates are stored internally in UTC and converted to local time as required.

When date and time are represented as strings they are formatted in order of granularity, from largest to smallest. This offers the following advantages:

• Dates are language neutral.
• Dates are unambiguous.
• Dates are machine sortable.

Julian 1.1
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.

The revelation
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.

Project updates April 2009

Posted on April 29, 02009
Filed Under Bede, Development, Drake, Flash, Herodotus, Inspiration, Journal, Kepler, Latham | Leave a Comment

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!

A review of Temporal Web Standards

Posted on April 6, 02009
Filed Under Development, Flash, Herodotus, Journal, Latham | 2 Comments

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.

ISO 8601
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.

Timestamps

W3C-DTF
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.

XSD:DateTime
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.

Calendaring and Scheduling

vCalendar
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.

hCalendar
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.

xCal
This is a proposed XML implementation of iCalendar.

RDF Calendar
This is a proposed RDF implementation of iCalendar.

Client side language specifications

HTML
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.

ECMA 262 v3 (Javascript and Actionscript)
This is the standard that Actionscript and Javascript are derived from. The Date class is an implementation of the Gregorian calendar and although it models UTC, leap seconds are ignored. Some of these issues are under review and proposals are in motion to make changes in version 3.1 and version 4.0.

Big History

Posted on February 25, 02009
Filed Under DaVinci, Development, Flash, Herodotus, Inspiration, Journal, Latham, Projects, Timelines | Leave a Comment

When I came up with the fanciful notion of an interactive timeline that stretches back as far as the Big Bang I thought I was onto something exciting and new. The problem with new ideas these days though, is that you're only one quick web search away from the realisation that they are anything but.

Although I think the interactive visualisation aspect is still new, it turns out that the unified (multi-disciplinary) approach to history has been around for about 25 years. The study of Big History attempts to combine the timescales of cosmology, geology, paleontology, archeology and history into a single unified timeline. As we have more detailed information about events closer to the present, the result is a naturally logarithmic timeline.

Big History courses have been taught in Australia and the US and David Christian's excellent lecture series is available from the Learning Company. The information and insights contained in these books are going to be invaluable for structuring periodization for Herodotus.

The project architecture

Posted on February 16, 02009
Filed Under Bede, DaVinci, Development, Drake, Flash, Harrison, Herodotus, Journal, Kepler, Latham, Projects | Leave a Comment

After reviewing what I want to achieve from the project I have identified seven areas I need to work on. Each area will become its own project and is named after a major figure in that field. The plan is to post about the work here and check in newly completed functionality into http://code.google.com/p/computus/ .

The Model View Controller declarations in the diagram below are only intended to be broadly indicative of the functionality. As you'll see most of the work falls into the Model domain as it involves managing historical data. This should be good news for anyone wanting to use this work elsewhere. Although I'll be using Flash to build my UI, all of the model classes will be in pure AS3; meaning they can be used as-is in Flex or AIR (and with a bit of fiddling, converted to Javascript).

Much of last years work falls easily into the new structure. The Timekeeper class becomes part of Harrison, a project focusing on timekeeping in AS3. The Flash BaseComponent class will form the foundation of the user interface, a project that could only be named after Da Vinci, the archetypal artist/engineer.

Herodotus concerns itself with the accumulation and management of historical data. Named after the first ever historian this project will focus on importing and parsing all kinds of temporal data.

The twin project to Herodotus will be Bede. This is a project concerned with the generation of temporal data. These classes will principally be used to calculate the dates of movable feasts and other days of observance.

Both Herodotus and Bede will make use of the calendrical framework Latham. This project is named after the late Lance Latham, who's Standard C Date/Time Library was one of the original inspirations for The Computus Engine. Latham will support the storage of historical dates and simplify conversion between different timescales and calendar systems. Algorithmic calendars will be the first to be supported.

Astronomical calendars will follow in Latham after the completion of Kepler. I find it ridiculous that we don't yet have an open source astronomical framework in Actionscript. It looks like Im going to have to build my own. I really only need to generate ephemeris data for the earth, sun and moon but hopefully this might be enough to jump start a full astronomical framework in AS3. This is the International Year of Astronomy after all.

The last part of the puzzle is Drake which concerns itself with spatial calculations, and geocentrics is a prerequisite for Kepler. I may not need to do much with this as there seems to be a fair bit of good geo code kicking around already - mainly due to the huge number of PV3D earth demos!

The diagram below shows how the different projects fit together.

keep looking »