[Up: design lab][Robot Wisdom home page]
Abstract: Starting with a simple XML-like vocabulary, it should be possible for amateurs to build a unified world history on the Web, in the form of thousands of specialised timeline-pages. An authoring application should be created to facilitate this.
<EVENT TIME="1492.10.12" PERSON="Christopher_Columbus" PLACE="Caribbean.Bahamas" RELATION="visited"> 1492: 12Oct: Columbus 'discovers' America </EVENT>
I've been making lots of thematically-overlapping timelines within my James Joyce pages-- there's a main one of his full life, a close-up of his 'Dedalus years', parallel timelines for Yeats, Gogarty, Nora, and many other friends, relatives, and associates, plus a timeline for a Dublin community of Theosophists that overlaps the timelines of all its individual members, and another overlapping timeline of Theosophy itself.
But as I build each of these separately, it's becoming a complete nightmare to 'synchronise' the inconsistencies that crop up, when any new item might fit into many different timelines, and may well contradict something copied from an earlier source.
So what I want is a 'timeline processor' that can merge the items from any set of timelines, allowing me to quickly spot and correct problems, or just to copy a new item to all the appropriate target-pages.
The 'geekthink' solution here would require all the timelines to use a standard date-format... but I don't accept this. [more] I want complete flexibility in what my readers will see... so I have to accept XML-like hidden tags, that do use a fixed vocabulary.
But as long as I'm doing this for my own timelines, there's no reason other timeline-authors on the Web couldn't use the same hidden markup, so that the authoring tool could 'merge' any number of timelines from anywhere as part of the synchronisation process. So I'll call this markup 'ITP' (or 'ITPML') for Internet Timelines Project.
Getting started on this using Emacs or Perl should be pretty simple, but there are a few standards needed from the start: dates, names, and maybe places. Standardising the attribution of sources will also be a high priority.
Dates
The basic date-format is very simple: 2001.5.22 (cf ISO 8601)
You can make this vaguer-- 2001.5 --or more precise: 2001.5.22.2340
BCE-dates can just use a minus sign: -586.5.22
The date-format needs to allow for events that take place over a span of time, giving a start and finish in this format:
<event time1='2001.4.10.0900' time2='2001.4.10.1045'>
To reduce bandwidth, it will probably be convenient to do 'relative indexing' of dates:
<EVENT TIME="1492">
<EVENT
TIME=".8.3"
PERSON="Christopher_Columbus"
PLACE="Europe.Spain"
RELATION="departed">
1492: 03Aug: Columbus sets sail
</EVENT>
<EVENT
TIME=".10.12"
PERSON="Christopher_Columbus"
PLACE="Caribbean.Bahamas"
RELATION="visited">
1492: 12Oct: Columbus 'discovers' America
</EVENT>
</EVENT>
As long as these 'wrappers' are fixing the reference-date for the EVENTs they enwrap, they might also fix reference places and maybe reference persons, too.
Uncertainty
A very simple way to include uncertainty might be via a questionmark: TIME="2000.5.22?" You could add a margin of error after the qmark, too: TIME="2000.5.22?2" could mean between the 20th and the 24th.
Names
On comp.text.xml recently I proposed something like a 'Universal (or Uniform) Celebrity Identifier'.
This would require a central registry, that assigns a single, fixed name to every celebrity in history (and ultimately to every known person).
For simplicity, this should be based on the most common way they're usually named. So Richard Nixon has been called Richard Nixon, Dick Nixon, Richard M Nixon, Tricky Dick, RMN, etc etc etc, but using search-engine statistics one can determine which of these is most common (surely just 'Nixon') and register that as his UCI.
When ambiguities arise you can add a birthyear to the less-well-known of the two:
Richard.Nixon.1961
or if needed
Richard.Nixon.1961.4.10
Authors could then query the registry if they have any doubt about the proper UCI.
Groups
A group of unnamed people might be handled as: PERSON="group.535" where 535 is the size of the group.
Places
Places probably need a comparable registry:
Ireland.Dublin.Eccles-street.7.1st-floor.bedroom.bed.rightside
Person-place relationships
People tend to have a single place as their home address for spans of dates:
<event person='joyce' relation='home' time1='1894.10' time2='1896.4' place='ireland.drumcondra.millbourne-avenue.holywell-villas.2'>
Other person-place relationships could include: vacation, school, work, visit, born, died, convalesced
(These start to require my fractal-thicket indexing.)
If places are specified using a standard markup, any timeline could be automatically 'animated' on a custom-generated map, as well.
Attributions
If a timeline-item is copied from another page, the authoring tool should make a note of the source URL for future reference. Sometimes you'll want to display this, but more often with a 'level of indirection' than with an actual HTML href. So we should expect timeline pages to have a bibliography-list that includes the URLs of source-pages, with a local shorthand code for each one. The same bibliography-codes can be used for offline sources.
Example:
rff = RF Foster's WB Yeats
dtm = Gomes's Dawning of the Theosophist Movement
gds = RA Gilbert's The Golden Dawn Scrapbook
(Once this indirection is implemented, local shorthands for persons and places could also be added. XML 'entities' may fit the bill.)
Complications
'Person' and 'place' are the barest minimal level of representative detail. What gets added next starts to become a much greater semantic challenge:
- schools attended
- jobs taken
- organisations joined
- organisations founded
- friends, romances, marriages, affairs
- financial budgets-- income and outflow
- books (etc) read
- books written, creative works
- public appearances, performances
- critical reactions
- motives, goals, and ideals as they change
As these are gradually accumulated, a truly powerful 'knowledge engine' should begin to emerge.
Largescale history
Some events that involve individuals can also be viewed on the scale of larger groups, or populations. In particular, historical migrations could use the same markup as an individual changing their residence. This suggests a top-down approach to discovering a good limited-vocabulary: [more]
Readability
The requirements of ITP markup should not constrain what the reader sees in any way. In the long run, it's the reader's experience that's most important-- a perfectly gigantic database is worthless if it's unapproachable by ordinary readers.
So ITPML should not have any styles associated with it. The reader should see an esthetically pleasing page, with any arbitary style-variations that seem to work, and not a boringly uniform database-dump.
You can submit a new URL or any other suggestion for this page by typing it into the box below. It will instantly become visible to anyone at this comments page. I should get around to checking it out and updating it above within a week or three, at which point I'll delete it from the comments page.
If you want credit, include your name and email (otherwise it's anonymous). You can use HTML but you don't have to.
Web-design pages:
main :
academia :
info-design :
adding value :
resource-pages :
lessons-learned :
best-worst :
plugging leaks
Special topics:
surfing-skills :
url-hacking :
open content :
semantics :
pagelength :
linktext :
startpages :
bookmarklets :
weblogging :
colors :
autobiographical pages :
thumbnail-graphics :
web-video :
timeline of hypertext
Anti-XML/W3C/etc:
structure-myth :
page-parsing :
firstcut-parser :
html-history :
semantic web
Design prototypes:
topical portal :
dense-content faq :
annotated lit :
random-access lit-summary :
poetry sampler :
gossipy history :
author-resources :
hyperlinked-timeline :
horizontal-timeslice :
web-dossier
Website-resource pages:
RobotWisdom.com :
Altavista.com :
1911encyclopedia.com :
Google.com :
IMDb.com :
Perseus.org :
Salon.com :
Yahoo.com
Older stuff:
design-lab :
design-checklist :
HyperTerrorist :
design-theory :
design cog-sci
Hosting provided by instinct.org. Content may be copied under Open Web Content License.