Musi-Cal Email Interface

(Note: Anywhere you see something like send a "foo" command to the Musi-Cal command processor it means to send an email message to concerts@musi-cal.com with a message body of "foo".)

Musi-Cal(tm) is a live music calendar created and managed by Mojam Media, Inc. Two interfaces are provided, one via email and one via the World-Wide Web. This document describes the email version of Musi-Cal although there is lots of useful information for Web interface users as well.

For people just getting started with Musi-Cal there are a number of shorter documents than this that describe individual aspects of the email interface. They are a bit less daunting than this tome, although they haven't yet been converted to HTML so they aren't real purty. Available are:

Help on searching: Describes the basics of the get command.
Help on the new itinerary@musi-cal.com alias: Teaches you how to use the new itinerary@musi-cal.com email alias to easily submit tour itineraries to Musi-Cal.
Help on submitting: Teaches you about the add command, gives a brief introduction to the Slicer-Dicer and lists some common problems people have when just learning to submit data to Musi-Cal.
Help on patterns: Teaches you the ins and outs of the patterns used to describe different formats for raw input to the Slicer-Dicer.
Help on regular expressions: This is a very cursory look at regular expressions used by Musi-Cal when searching for performers, venues and events.
Help on editing: This short document describes the steps you take to edit entries already in Musi-Cal.
Sample templates: This file contains three heavily annotated templates, one for adding entries directly to Musi-Cal and two for using the Slicer-Dicer.

Now, on with the show...

The list processor supports the following commands:

get - get various lists from the calendar
add - add an entry to the calendar
clear - clear saved information from previous add commands
delquery - delete a repetitive query
convert - convert entries from other formats into Musi-Cal format
default - establish defaults for a subsequent convert command
edit - select entries from the database to edit
change - modify entries in the database
help - get this document in plain text form by email
faq - get the frequently asked questions by email

Commands are given on a line by themselves. Subcommands are given one per line as a keyword followed by zero or more extra words. Leading and trailing whitespace is ignored. A line ending in a backslash ('\') causes the immediately following end-of-line to be ignored. The Subject field of the message is ignored. All messages sent should receive a reply. If you send a message but don't get a reply within a reasonable amount of time, please let us know.

Get Command

The get command is used to query the Musi-Cal database. It accepts a set of subcommands followed by an end subcommand and generates a query to the calendar.

The following subcommands are available. At least one must be given. Unlike the add command values given do not carry over between successive get commands.

keywords constrains the search based on one or more keywords that describe the music in some way. Keywords are in some sense modifiers of the type field or describe the music in a different way. At the moment the following keywords are known to the processor:
a cappella, acid, acoustic, african, alternative, american, americana, asl interpreted, avant garde, ballet, barber shop, bebop, big band, bluegrass, blues, brass band, brazilian, cabaret, cajun, calypso, celtic, chamber music, children's music, choral, christian, classical, comedy, conference, contemporary, country, dance, death metal, dixieland, early music, eclectic, electric, ethnic, experimental, folk, funk, fusion, gospel, gothic, grunge, hawaiian, heavy metal, hip hop, house concert, indian, indie, industrial, instrumental, jazz, jewish, klezmer, latin, light opera, looping, mainstream, musical theater, native american, new age, old-time, oldies, opera, original, other, poetry, pop, progressive, punk, r&b, ragtime, rap, rave, reggae, religious, rock, rockabilly, roots, salsa, seafaring, seminar, ska, slack key, solo, soul, spoken word, storytelling, surf, swing, symphonic, techno, tejano, traditional, vocals, workshop, world, zydeco
date specifies a date or range of dates in which to constrain the search. Dates may be given in American (e.g., August 12, 1993), European (e.g., 12 August 1993) or numeric (e.g., 8/4/95) form. Numeric dates must be of the form month/day/year. Multiple dates can be given (e.g., August 12-13, 1993, 12 December 1994 - 4 January 1995 or 4/5/95-4/9/95). Note that if multiple dates are given, both dates must be in either American or European form. Month names must be given in English.
city constrains the search to a particular city.
state constrains the search to a particular US state or Canadian province. It may also be called province. State and province names should be case-insensitive. Full names (e.g., Pennsylvania or Ontario) and two-letter postal abbreviations (e.g., PA or ON) are understood. Other abbreviations (e.g., Penn. or ONT) are not recognized.
country constrains the search to a particular country outside the US and Canada. Currently only full country names are understood. Eventually the two-letter ISO country codes will be understood.
performers constrains the search based upon the name of the performer(s). Multiple performers must be separated by '/'. You can query using the full name (e.g., Doc Watson or Watson, Doc) or by regular expression.
radius lists the radius about a given city to search. For this to be effective both a city and state, province or country must be given. Radius calculations are based on the latitude and longitude of a city. Simply giving the city name is not enough. For instance, there are two cities named Albany in Canada, one in Australia, and seventeen (!) in the United States. Units of miles or km may be given. miles is the default.
nhits identifies the maximum number of matching entries to return. The most that will be returned (regardless of what you specify) is currently 200.
age restricts matches by the age of the entry. Each entry has a submission date. age 5 would restrict the query to entries that are no more than 5 days old.

Here are some examples of valid get commands. The first returns all upcoming performances by Doc Watson within a radius of 100 miles of Philadelphia, Pennsylvania, returning at most 20 hits.

    get
        performers Watson, Doc
	city Philadelphia
	state PA
	radius 100 miles
	nhits 20
    end

The following command returns all upcoming folk and country music events in Austin, Texas between 1 March and 15 June 1995.

    get
        keywords folk, country
	city Austin
	state Texas
	date 1 March 1995 - 15 June 1995
    end

Repetitive Queries

Musi-Cal supports repetitive queries. These work just like regular queries except they are not only executed when submitted, but are saved and repeated with either daily, weekly or monthly frequencies. Mail will be sent to you only if the query yields positive results. The repeat subcommand takes either daily, weekly or monthly as an argument. When a repeat subcommand is given the age subcommand is restricted to have a value no more than twice the length of the query frequency:

    Query frequency		Maximum Entry Age
    ---------------		-----------------
	daily				 2
	weekly				14
	monthly				60

Here is a simple example:

    get
	city Austin
	state TX
	age 1
	repeat daily
    end

The above query would be repeated every day. No entries over one day old would match.

You can also select the format of repetitive queries. By default, they are returned as HTML, but you can specify plain text also, using the format subcommand:

    get
	city Austin
	state TX
	age 1
	repeat daily
        format text
    end

Delquery Command

When a repetitive query command is submitted an id is assigned for it and returned to you. It is also returned whenever the query is executed. To delete a repetitive query, simply send a delquery command. For instance:

    delquery
    	id user@somewhere.com.daily.18522
    end

Add Command

The add command accepts a set of subcommands following it up to an end subcommand and creates an entry in the calendar database. Several different subcommands are accepted. The following subcommands are required:

date is the date of the event. Dates may be given in American (e.g., August 12, 1993), European (e.g., 12 August 1993) or numeric (e.g., 8/4/95) form. Numeric dates must be of the form month/day/year. If an event spans multiple days or if the same performer will be giving concerts at the same location over multiple days, multiple dates can be given (e.g., August 12-13, 1993, 12 December 1994 - 4 January 1995 or 4/5/95-4/9/95). Note that if multiple dates are given, both dates must be in either American or European form.Dates may be given in American (e.g., August 12, 1993) or European (e.g., 12 August 1993) form.
city is the city where the event will take place.
state is the state where the event will take place. It may also be called province. The state or province can be given in full (e.g., Pennsylvania or Ontario) or abbreviated using the US Postal Service abbreviations (e.g., PA or ON). Anything else will be rejected by the command processor.
country is the name of the country if the concert occurs outside the US or Canada. Currently only full country names are understood. Eventually the two-letter ISO country codes will be understood.
performer names the performer(s) (band, conductor, soloists, ...). Multiple performers are separated by '/'. Performers' names should be given in sorting order. For individuals this is usually Last Name, First Name (e.g., 'Watson, Doc'). The performers subcommand is not required empty if the event subcommand is given. If the performer plays a particular instrument or conducts this can be given in parentheses following the performer name (e.g., Ma, Yo-Yo (cello)).
event is used to identify an event other than a single concert. This includes music festivals, songwriter workshops, and fiddle and dance contests. It is required if no performers are listed using the performer subcommand. The only use currently made of the event field is display it in query output. Eventually event-specific listings will be available.

The following subcommands are optional:

type is the type of music event. Valid values are currently blues, classical, country, rock, newage, religious, ethnic, folk, jazz, rap, and other. Multiple types can be listed, separated by commas. Note: Although this field is optional, it should be given where known to improve the chances that people constraining searches by the type of music will see all appropriate events.
keywords are in some sense modifiers of the type field or describe the music in a different way. At the moment the following keywords are known to the processor:
a cappella, acid, acoustic, african, alternative, american, americana, asl interpreted, avant garde, ballet, barber shop, bebop, big band, bluegrass, blues, brass band, brazilian, cabaret, cajun, calypso, celtic, chamber music, children's music, choral, christian, classical, comedy, conference, contemporary, country, dance, death metal, dixieland, early music, eclectic, electric, ethnic, experimental, folk, funk, fusion, gospel, gothic, grunge, hawaiian, heavy metal, hip hop, house concert, indian, indie, industrial, instrumental, jazz, jewish, klezmer, latin, light opera, looping, mainstream, musical theater, native american, new age, old-time, oldies, opera, original, other, poetry, pop, progressive, punk, r&b, ragtime, rap, rave, reggae, religious, rock, rockabilly, roots, salsa, seafaring, seminar, ska, slack key, solo, soul, spoken word, storytelling, surf, swing, symphonic, techno, tejano, traditional, vocals, workshop, world, zydeco
Note: Although this field is optional, it should be given where known to improve the chances that people constraining searches by keyword will see all appropriate events.
venue names the site of the event (e.g., Sports Arena, The). Note that venue names should be presented in sortable order.
info lists contact information about the event. This can be a phone number (don't forget the area code!), a URL (e.g., http://www.mojam.com/) or an email address. Email addresses should be given in URL form, for instance, mailto:concertmaster@musi-cal.com. When a URL is given if it is the first word, a hypertext link will be generated when the listing is displayed on the World-Wide Web. The remaining words will be the highlighted text.
program lists the program the performers will be playing. This is mostly interesting for classical music concerts. As with multiple performers, if more than one piece is being played, they should be separated by '/' characters. Where appropriate, each piece should be given as 'composer: opus' (e.g. Mozart: The Marriage of Figaro). We plan to eventually support searching by composer.
time lists the time of the event (e.g. 4:30PM or noon-6PM). The time can be shown in any format that is convenient. It is displayed but not manipulated in any fashion other than to distinguish potentially duplicate events for database maintenance.

Here are two complete examples that demonstrate the major subcommands of the add command:

    add
	type classical
        keywords symphonic
	performer Philadelphia Orchestra/Sawallisch, Wolfgang (conductor)/Serkin, Peter
	date 31 January 1995
	venue Academy of Music
	city Philadelphia
	state Pennsylvania
	info (215)893-1999
	time 8PM
    end

    add
        keywords country,folk
        keywords
        performers Cash, Johnny
        date May 20-21, 1995
        venue Acull Theater
        city Nashville
        state TN
        info
        time
    end

Note that the keywords, info and time fields of the second entry are blank. If you are submitting multiple entries to the calendar only the information you specify changes between submissions. This can be both a help and a hindrance. If you are submitting lots of similar entries it simplifies the task considerably. On the other hand, if you're not careful, your Green Day entry might wind up in the classical music section if you forget to give a type rock subcommand following a classical entry.

If the same group is playing at the same site on a weekly basis all you need to change is the date. The following four add commands create four entries in the database for the Madison Jazz Orchestra on four successive Thursday nights in January.

    add
	performer Madison Jazz Orchestra
	type jazz
	venue Dotty Dumplings Dowry
	city Madison
	state Wisconsin
	info (608)255-3175
	date 5 January 1995
    end
    add
	date 12 January 1995
    end
    add
	date 19 January 1995
    end
    add
	date 26 January 1995
    end

If you want to clear a single field, simply enter it with no arguments. For instance, the following entry makes sure the info field from the previous entry is not used inadvertently.

    add
	performer Sturm, Hans/Grassel, Jack/Richeson, Dane
	venue Reunion, The
	date 6 January 1995
	info
    end

Adding Notes Index Entries

A special variant of the add command allows you to add information to Musi-Cal's Notes Index. The Notes Index stores long-lived information about artists, venues or cities. For artists the database can contain URLs or keywords. For venues and cities the Notes Index contains only URLs.

When you want to create a Notes Index entry in Musi-Cal, the static field is added to the command. The performer, venue or location keywords (city, state, country) are used to name the relevant item. The url and keywords fields are used to associate values with a particular performer, venue or city. The url field can be used multiple times in the command, each time to add a single URL to the database.

A few examples should serve to demonstrate the use of the static form of the add command. There are several things to note in the examples that follow.

URLs can be more than just "http://somewhere/spam/eggs/barley". They can be a short snippet of HTML in the form of an HTML anchor. Please do not include any graphics (IMG tags)!
Information about venues must include the city and state or country to be complete.
Keyword information is only useful for performers. It is silently ignored for venues and cities.

The first example associates a URL, and two keywords with the performer Michael Jackson.

    add
	static
	performer Jackson, Michael
	url <a
	href="http://www.music.sony.com/Music/ArtistInfo/MichaelJackson.html">Sony
	Music's MJ page</a>
	keywords rock,vocal
    end

The second example refers the user to City.Net for information about Portland, Oregon. (Note that the keywords field is not relevant for city information.)

    add
	static
	city Portland
	state OR
	url <a href="http://city.net/countries/united_states/oregon/portland/">City.Net</a>
    end

The third example directs users to the home page for the Bluebird Cafe in Nashville, Tennessee.

    add
    static
    venue The Bluebird Cafe
    url http://www.hidwater.com/bluebird/bluebird.html
    city Nashville, TN
    end

Clear Command

To clear all fields, simply issue a clear command. This is often more convenient than entering multiple blank fields to guarantee they are empty.

    add
	performer Sturm, Hans/Grassel, Jack/Richeson, Dane
	venue Reunion, The
	date 6 January 1995
	info
    end

    clear

    add
	performer Hellerman Quartet, John
	date 7 January 1995
	venue Cafe Europa
	info (608)255-0770
        city Madison
        state Wisconsin
        keywords jazz
    end

If you use software that generates add commands for Musi-Cal from some other format, each command generated should use all possible subcommands (even if they are blank) or a clear command should be generated following each add command.

Convert Command

It is very common to see lists of concert entries where each concert is described by a single line. For example:

    April 10 Carpenter,Mary Chapin/McGarrigle Sisters/Baez,Joan
    April 11 Ian,Janis/Black,Mary/Baez,Joan
    April 16 Indigo Girls,The/Farina,Mimi/Baez,Joan
    April 17 Hinojosa,Tish/Baez,Joan

Coupled with several pieces of constant information the above list contains much of the information necessary to submit all four concerts to Musi-Cal. The convert command performs the necessary conversion and returns the result to you via email.

To use the convert command simply place the lines to be converted between convert and end lines:

    convert
    April 10 Carpenter,Mary Chapin/McGarrigle Sisters/Baez,Joan
    April 11 Ian,Janis/Black,Mary/Baez,Joan
    April 16 Indigo Girls,The/Farina,Mimi/Baez,Joan
    April 17 Hinojosa,Tish/Baez,Joan
    end

The real interesting aspects of format conversion are described in the next section. Read on.

Default Command

Although concert entries such as those described above contain the information that changes between concerts, the constant information is usually implicit. A list of concerts for a single performer rarely identifies the performer on each line. Similarly, the concert listing for a venue does not normally contain the venue name, city, state or ticket information. While all listings will (or should) contain dates, they almost never contain complete dates, simply the month and day as in the example above. Finally, the format of the concert entries is itself constant and must be given to the command processor in a suitable form.

Taken together, we refer to the convert and default commands as the Slicer-Dicer. The default command allows the Musi-Cal submitter to identify this constant information. Here is a simple example:

    default
	venue Bottom Line
	city New York
	state NY
	type folk,country,rock
	pattern %{Smonth} %{sday} %{performers}
    end

The pattern subcommand describes the format of the entries.

The keys to using the convert and default commands to simplify event submission are to understand a little about how entries are described and what pieces of information can be described.

Each piece of information in a concert entry is associated with a tag, a string enclosed in %{...}. For the most part these tags correspond one-to-one with the subcommands available with the add command. A set of tags, coupled with some literal characters, are grouped together to form a pattern. The pattern is converted into a regular expression that is used to match lines in the convert command. If you're not a techno-nerd and don't know what a regular expression is, don't worry. A deep understanding of them is not normally necessary.

The following tags are used to build patterns. The columns of the table name the tag, describe it and identify the characters it can contain.

    tag		description			characters
    ------------------------------------------------------
    performer	performer name (in sorting	anything
		order!) 
    type	music type (rock, jazz,		letters, comma, spaces, &
		folk, classical, etc)
    keywords    other descriptors (symphonic,   letters, comma, spaces, &
                early music, a cappella, etc)
    city	city of the event		anything
    state	state name spelled out		letters, spaces
    province	province name spelled out	letters, spaces
    country	country spelled out		letters, spaces
    st		abbreviated state name -	letters
		always printed upper case 
    prov	abbreviated province name	letters
		- always printed upper
		case 
    cty		abbreviated country name -	letters
		always printed upper case 
    venue	venue name			anything
    info	concert information		anything
    program	concert program			anything
    sday	day of the month for the	digits
		start of the event 
    smonth	numeric month (1..12) for	digits
		the start of the event 
    syear	four-digit year of the		digits
		start (e.g., '1995') 
    syr		two-digit year of the		digits
		start (e.g., '95') 
    Smon	abbreviated month name for	letters
		the start (e.g., Jan) 
    Smonth	full month name for the		letters
		start (e.g., January) 
    eday	day of the month for the	digits
		end of the event 
    emonth	numeric month (1..12) for	digits
		the end of the event 
    eyear	four-digit year of the end	digits
		(e.g., '1995') 
    eyr		two-digit year of the end	digits
		(e.g., '95') 
    days        dates or date ranges,           digits, comma, spaces
                separated by commas (e.g.,
                '21, 22, 25-26')
    Emon	abbreviated month name for	letters
		the end (e.g., Jan) 
    Emonth	full month name for the		letters
		end (e.g., January) 
    number	one or more digits with no	digits
		intervening white space 
    alpha	one or more letters with	letters
		no intervening white space
    string	one or more letters,		anything
		digits or punctuation
		characters with possible
		embedded white space
    date        "Smart" date parsing            anything
    location    "Smart" address/city/state      anything
	        parsing

Each of the tags listed in the table above can be used as a subcommand for the default command. The default command takes one extra subcommand not listed above. The docaps subcommand forces the processor to capitalize all words (strings of characters separated by white space). THIS IS USEFUL WHEN THE AUTHOR OF THE ITINERARY WAS SHOUTING. The syear and eyear are by default set to the current year so they rarely have to be given. Watch out if you are submitting itineraries that cross the end of the year, however. (Either submit two separate itineraries with different default years or make sure the year is given where it is not the default.)

Three special tags (number, alpha and string) are also available. They may not be used as subcommands of the default command. Instead, they are used to ignore fields (such as the day of the week) that aren't useful when submitting concerts.

For many tags it is sufficient to separate them from the tags that follow by spaces, but for tags that can contain spaces (performer, city, type, state, province, country, venue, info, program and string) a character that does not occur in that field must occur in the entries and immediately follow the tag (with no intervening white space!) to keep the regular expression matcher from gobbling more input than it should.

If the first character after the leadin string '%{' is non-alphabetic, the tag can contain various punctuation characters, including possibly nested tags. If the first character after '%{' is '?' the tag is optional. For instance, if event dates are listed as month/day with a possible hyphen followed by a second day (e.g., 1/15 or 1/15-16), a set of tags that recognizes both is '%{smonth}/%{sday}%{?-%{eday}}'.

To create a pattern for an event consider the following one-line item:

	23 FEB: Norway:  Bergen

It lists the day, month, country and city. The pattern specifying this event would be:

	%{sday} %{Smon}: %{country}: %{city}

Since this entry does not indicate performer name or music type, they must be given as subcommands to a default command. The set of commands to parse events of this format for the Celtic music group Shane & the Popes would be:

    default
	performer Shane & the Popes
	type folk
	pattern %{sday} %{Smon}: %{country}: %{city}
    end
    convert
    23 FEB: Norway:  Bergen
    end

The resulting output would look something like:

    # 23 FEB: Norway:  Bergen
    add
       performers Shane & the Popes
       keywords folk
       city Bergen
       country Norway
       date 23 February 1995
    end

Note that all input lines are echoed to the output as comments for the concerts@musi-cal.com parser. This gives the user feedback necessary to either correct the output manually or correct the input before submitting another convert command.

Note that the output from conversion is not automatically submitted to Musi-Cal for inclusion in the database for several reasons. First, it is possible that your pattern description will contain an error, especially when you are first learning to use the command processor. Second, there may be some improperly delimited lines that cause them to not be recognized or worse, to be recognized as something they aren't. Finally, the command processor attempts to verify that the city and state (US) or province (Canada) exist by looking up their latitude and longitude. If they can't be found the processor returns a warning. (Cities outside the US and Canada are currently not subjected to this check because we have relatively little lat/long information for them.)

The use of the %{days} tag can cause more than one add command to be generated. For instance, if the above Shane & the Popes data was

    23, 24, 25, 29-30 FEB: Norway: Bergen

and the pattern subcommand was

    %{days} %{Smon}: %{country}: %{city}

two add command would be generated, one with a date of 23-25 February 1995 and one with a date of

29-30 February
1995

Hints About Patterns

Generally speaking, the fields must be well-delimited. Fields that can't contain spaces can rely on white space as a delimiter, but fields that can contain spaces must use some sort of punctuation character to separate them from the next field. Venue names are often multiple words, so it is important to follow them with a delimiter that does not occur in the name if there is more information on the line following them. For instance:

    2/24/95 Albany, NY, Eighth Step; (518)434-1703

Numeric fields, month names and state, province or country abbreviations are well-defined since they consist of a set of characters without intervening spaces. White space serves as an adequate delimiter in this case.

Make it easy on yourself. Make sure the input is delimited consistently. The pattern that recognizes the Albany event above is

    %{smonth}/%{sday}/%{syr} %{city}, %{st}, %{venue}; %{info}

If you leave out a comma:

    2/25/95 Albany NY, Eighth Step

the input line won't be recognized or fields in the output will be shifted. If the venue is optional:

    %{smonth}/%{sday}/%{syr} %{city}, %{st}%{?, %{venue}}

the above line will be recognized, but the city will be "Albany NY" and the state will be "Eighth Step".

Don't choose delimiter characters that have special meaning to regular expressions. They include periods, asterisks and plus signs. The pattern you create is converted into a rather complex regular expression that is then used to match input lines. Special characters like '+' really confuse things...

If you anticipate submitting concert information to Musi-Cal on a regular basis, pick a format that is convenient for you and has the information necessary for the converter to do its work. That way, once you get a pattern that works submitting new events will be that much easier.

Consistency Checks

The Slicer-Dicer performs a few consistency checks on all input. This helps you correct your data and catches some very common mistakes (like misspelling location names, omitting required default information or incorrectly constructing patterns).

If any required fields are missing, the entry generated will contain a warning. Required fields include date, performers or event, city, and state, province or country.
An attempt is made to look up latitude and longitude for US and Canadian cities. If this fails a warning is generated. This usually suggests a misspelling.
A query is generated using the date(s) and performer(s) being added. If any matches are found a warning about a possible duplicate is generated.

Repeated Updates

Submitting data for the same artist or venue repeatedly can be a chore. Determining which items need to be changed or deleted and deciding which items are new can be tedious. To simplify that task, a specially formatted keyword can be associated with a group of entries to make it easier to performer wholesale updates. The delkey command allows you to delete entries based on this special keyword, e.g.:

    delkey
	key .matthewabelson.40917
    end

The Slicer-Dicer will generate a delkey command just before the series of add commands. When the whole set of commands is submitted to the concerts email interface, all items having the special keyword will be deleted just before all the new entries are added.

These special keywords are hidden. You won't see them in query or edit command output. They can't be deleted, even if you attempt to delete all the keywords in an entry. The keyword must be of a special form. It must start with a dot. The dot must be followed by one or more alphabetic, hyphen or underscore characters that do not make up an existing keyword in the system and another dot. The second dot must be followed by one or more decimal digits.

Editing Entries in the Database

You can edit entries in the Musi-Cal database for which you are responsible. Editing entries is a two-step process. During the first step you send an edit command to the list processor that selects one or more entries to change and returns them to you. The second step is to modify the reply and send it to the list processor.

The edit command understands the same subcommands as the get command. Additionally, it constrains the result to those entries associated with your email address. A simple edit command is

    edit
	city Regina
	state SK
    end

The result will be a message containing (hopefully) one or more change commands similar to

    change
	id 19950330-user@somewhere.com-239
    to
	type folk
	performer Bogle,Eric
	date 03 May 1995
	city Regina
	state SK
	venue Holy Rosary Hall
	info (306)949-6594
    end
    change
	id 19950405-user@somewhere.com-7742
    to
	type folk
	performer Kaldor,Connie
	date 20 April 1995
	city Regina
	state SK
	venue Travelodge Conference Room
    end

To edit the entry, change the relevant fields in the response. For instance, in the example above, if Boogaloo Bob was to be added to the Connie Kaldor entry above, edit it to

    change
	id 19950405-user@somewhere.com-7742
    to
	performer Kaldor,Connie/Boogaloo Bob
    end

To add new fields (such as missing info, event or keywords fields), add them into the second section of the change command:

    change
	id 19950330-user@somewhere.com-239
    to
	event Regina Folk Festival
    end

To delete a field, return it as a keyword with no value:

    change
	id 19950330-user@somewhere.com-239
    to
	event
    end

To delete an entry entirely, delete all lines between the to and end lines:

    change
	id 19950330-user@somewhere.com-239
    to
    end

Once you are satisfied with the changes, return the result via email to concerts@musi-cal.com.

Licensing | Help | FAQ | Home