Hi Magnus,
I agree with your assessment - we probably need a location model.
I think our time handling is OK, as it is event driven, and underlying math structures (Allen Algebra) rigorous. Policy of recording date as in Source is a solid one, otherwise into problematic area of calendar conversions. By leaving as is, and using +/- time tolerance, events maintain their integrity. W3C has an ontology for time, from 2006, but about to be updated to allow non-Gregorian calendars. There is also work just started in OGC and ISO to allow ISO8601 strings to be enhanced for non-Gregorian, so software-wise, life should get better.
Location implies at least three models:
1. Geo-Location, needed for people to relate to real world: Google maps, Open Street Map, etc. GPS ad WGS 84 probably good enough - to nearest 10 m or perhaps even 100metres. Geo-loc people tend to ignore time aspects ( e.g. Australla moving north at several cm/year -> several metres per century).
2. Gazeteer/named places. Generally OK but:
2.1 Names in sources may no longer be current, or no longer exist.
2.2 Any gazeteer or registry should recognise variants/synonyms/exonyms/etc (e.g. Londres for London) . I use Cumbria Family History publication on "Place Names of Cumberland" for standardised names and UK National Grid reference (which is not WGS84).
2.3 Again, time aspects tend to be ignored. E.g. Cumberland UK became part of Cumbria in 1974. Again, policy of using names in sources good. However, some sources, (e.g. Censuses) use admin districts not useful for anything else, either now or at the time of source.
2.4 Also flawed for regions, rather than 'points'. E.g. USA is not some isolated farmstead in the middle of Kansas, but whole country - a polygon or bounding box.
3. Addressing. Great variety across countries. Some international standards, not used in USA or UK or Venice/Venezia. Postal Codes really for delivering, but probably do not need to distinguish front door from goods entrance.
So, does that help in scoping the 'location model'?
Chris