Mike Schuh's EventFinder Markup Language Home Page

Copyright © 2004 by Michael Schuh, Seattle

The EventFinder Markup Language is an XML compliant language intended to facilitate the distribution of information about particpatory events. It includes markup constructs for events, the venues where they are held, and other supporting data.

This is the "official" home page of the EventFinder Markup Language project.

I am reorganizing how I do and present this effort. My previous work on this project (which I started in 1999) is at www.farmdale.com/ef/.

Jump to: The Current Situation  |  Why The Status Quo Fails  |  Technical Overview  |  How You Can Participate  |  Tools

The Concept

The EventFinder Markup Language is a means to distribute information about events - folk dances, orienteering meets, etc., via the web. The broad idea is that a user, attempting to locate, for example, dance opportunities in a region can formulate a query based on what kind of event (dance), where it take place (a city), and when (a date or range of dates), and submit this query to an EventFinder site instead of searching through numerous web pages. The event organizers will create a single web page with EFML data about their event. They might, optionally, forward the location of their EFML page to an EventFinder host (but they will need to do this at most once). They will not need to forward the information (nor any corrections!) to several web page hosts. Hosts of EventFinder sites will not need to manually collect and edit data from event organizers. Instead, they can "crawl" (search) through known EFML source pages and collect the information from them. If this is done on a regular (daily? hourly?) basis, then the EventFinder site will be as up to date as those of the organizers.

The Current Situation

I often assert - usually with a mixture of facetiousness and humour - that "all truth can be found on the web" ("and plenty more", adds my housemate). It follows, then, that information about events that I might wish to attend (folk dances, orienteering meets, etc.) can also be found somewhere - but where?

One method to find, say, folkdances in a distant city that I will visit in the near future is to google (yes, it's a verb now) for that city and style of dance, e.g., "Seattle contra dance". In this example, the first hit is Matt Fisher's seattledance.org Contra Dance list. The page currently includes information for 17 contra dance series (dances that take place at least once a month on a regular basis) in and around Seattle.   [all of the examples in this section are from late August, 2004]   For several of these series, Matt publishes additional information on what band is scheduled to play and who will call.

The fifth link from the above google search was to the Folk Dance Association's folkdancing.org website. This page includes information on all kinds of folk dance opportunities in Washington State, organized by city. For Seattle, it lists 29 dance entities including 8 contra dance series (4 of them defunct, or no longer being held).

A third solution is Ted Crane's DanceDB, which attempts to be a central repository for contra dances nationwide. It presently shows 9 dance series for all of Washington State, including one English Country Dance series, and two obsolete entries.

Dwayne Johnson's Contra Corners has a similar web site at contracorners.net. It lists 22 dance series in Washington State, including one in Moscow, Idaho, one that is out of date, and one dead link.

Of course, no mention of national web pages listing local contra dances would be complete without at least a passing reference to Kiran Wagle's colossal page, which I have used on several occasions. Presently, it lists 7 web pages for Washington dances (including Pendleton, which actually is in Oregon); 4 of the links don't work. Nonetheless, I thank you, Kiran, for the inspiration to work on this problem - and for guiding me to many enjoyable dances around the country.

All of these resources are useful, and I personally know that Matt's is heavily used (and Ted claims nearly 150,000 hits since late 1998).

(I have summarized the above on a separate web page. I have also sent corrections and updates to the respective web persons.)

Why The Status Quo Fails

For each of these, the flow of information is from the organizer to the web page's maintainer. That is, a dance organizer forwards to the web page's maintainer information about their dance. The maintainer then incorporates it in their web page, usually by editing the text of the web page or, as Ted does, by updating records in a database. The accuracy of the data that these web sites present is thus dependent on two separate actions: transmitting the data to the maintainer, and incorporating it in the web site.

In my descriptions above of the various web sites, I highlight the errors not to criticize the maintainers of the web pages, but to illustrate how difficult it is to keep everything up to date. Matt does a very good job with the Seattle information, largely because he is very active in the Seattle contra dance scene. The others are maintaining very large collections, usually for areas far away from where they live. I imagine that Ted's data for Ithaca, New York, region (where he hangs out) is quite good, and similarly for the others.

But keeping the data up to date is a never ending effort. For Matt, it is manageable - just a handful (17) dances to keep track of (actually, he also maintains information on several other forms of folk dancing in the Seattle area, but still less than 100). The other folks have several hundred dances to keep on top of - and their lists are incomplete (so is Matt's, for that matter).

Event organizers have a similar problem, only in reverse. If their information is published on, say, a dozen web sites, then any change they make must be disseminated to each of these dozen sites. Yes, a mailing list could be maintained, but this, too, is subject to change, typically without notice.

Basically, if an organizer doesn't get updated information to a web maintainer, or the maintainer doesn't update the web page, there will be inaccurate information broadcast to the users.

I started to automate the process of updating event information in my first pass at this, in a fashion similar to the Folkdance Association (that is, a form that an event organizer submits with new information) but concluded that it is not the best solution. Why? It would simplify the work of the web page maintainer, but it is less than ideal because event organizers would have to fill out a form for my EventFinder AND the Folkdance Association AND Ted's database AND Matt's page AND ... Clearly, this Ain't Gonna Work.

But wait a minute - isn't the web already distributed? So, isn't any piece of information that's on the web available everywhere? Why, then, must we send to others information that's already published? Why can't we just tell them where to look? This is the essence of my proposal for an EventFinder.

Wait - There's More!

In addition to the updating hassles, there is another shortcoming in the current model. For the dance listings described above, they are sorted (or grouped, pick a verb) by state. This works well enough, but misses some opportunities. For example, there is a regular contra dance in Moscow, Idaho, that draws a good crowd from Pullman, Washington, which is just a few miles away. Searching for dances in "Washington" would miss this. Yes, a user could search for dances in Washington and then in Idaho (if they knew how close Pullman is to the border), but why not just one (1) search for "dances near Pullman"?

Further, unless the user is familiar with the local geography, place names alone aren't very useful. A visitor to Seattle might discover from the above web sites that there are several dances coming up - one each in Tacoma, Yakima, and Spokane. How close to Seattle are these?

Personal example: In the fall of 2002 I was going to be in Albany, New York, on a (second) Sunday evening. From Ted's DanceDB I found one possibility at the "Buhrmaster Barn" in "Colonie, NY" Where in the heck is that? It turns out that "Colonie" is part of the greater Albany area, and was about a mile from my motel! But I had to dig to figure this out - and searching for dances in "New York" skipped over anything in nearby states.

Technical Overview

So, here's how I see this working. The organizer of an event creates a web page, written in EFML (an XML variant; see below), that describes their event and where and when it takes place. They can also provide links to EFML pages that they know about, from other event organizers nearby. On their traditional (HTML, human readable) web page they create a link to their EFML page, using some obvious (i.e., searchable) label like "Our EFML page is here". The file name should end in .efml (users handicapped by operating systems that limit file names to three letter extensions can use .efm).

The organizers forward the URL of their EFML pages to the maintainers of EventFinder web pages. The EventFinders then fetch the EFML pages on a regular basis, perhaps daily. References to other EFML pages can be followed to extend the EFML web.

How the EFML data is used is up to each EventFinder site. The goal is to present to the users a search interface that addresses the issues described above.

When an organizer needs to update their information, they simply do so on the EFML page that they already have. They shouldn't have to do anything else! The next time an EventFinder fetches their file, their information on the EventFinder's web site will be updated. As long as the EventFinders crawl the EFML pages on a regular basis, the organizers don't need to send out update notices to the mulitude of sites.

An extra benefit for the event organizers comes from using XSL and XSLT to transform their EFML pages into HTML web pages, or just about anything else. The idea is that they need to write the data once, in an EFML file, and then it can be used in several ways without addtional effort. (This is gonna take some work to be functional...)

Technical details are on a separate web page. The current draft of the EFML schema is here.

How You Can Participate

If you are an event organizer:
If you maintain a web page with event schedules and calendars: If you use the web to find information about events: Everyone:


Creating XML can be tedious, so why not use a computer to do it for us? Here are links to "fill in the blank" forms to create EFML entries for:
(Actually, these links have been deactivated - the scripts aren't ready, they were being abused by spammers, and I'm going with a different solution.)
After generating the EFML text for an item, copy it into your .efml file. Remember to start the file with an <efml> tag and to end it with an </efml> tag.
More to come...
Copyright © 2004 by Michael Schuh, Seattle
Last update: September 28, 2004 14:17:03 PDT
To EventFinder home page
To Mike Schuh's home page
Mail (but not spam) is welcome to:
schuh AT farmdale D0T com

Thank you for the visit.