Minutes for the Open Theory Meeting, July 2, 2007

Minutes for the Open Theory Meeting, July 2, 2007
Submitted by DNB Staff - October 26, 2007

[Following are minutes for the Open Theory Meeting held at the Dance Notation Bureau, July 2, 2007.]

Present: Zack Brown, Jen Garda, Mira Kim, Mei-Chen Lu, Christina Schoenfeld, Charlotte Wile.

TOPICS
1. XML
2. Amount and Size of Paths

TOPIC #1: XML
The group read the following essay that Zack had posted on LabanTalk on June 15, 2007.

What is XML?
by Zack Brown

I was hanging out at the DNB recently and the question came up, what is XML and how might it relate to Labanotation? With the recent discussion of creating an XML schema for Labanotation on this list, it didn't occur to anyone to actually explain what XML is.

XML has some interesting facets that I won't go into here, involving ways that computers can interpret and modify XML files. I'll just explain the "front end" of XML, the part that regular people would use.

XML is a very generalized, text-based 'tagging' system, used to organize information. As a text-based system, it's fairly easy to read. The 'tags' are identified by '<' and '>' angle brackets. Information associated with a given tag is typed in-between a starting and an ending tag, like this:

<sampletag>Hi, Laban people!</sampletag>

Notice that the ending tag has a '/' after the opening angle bracket. That's the case for all ending tags. The example above could be interpreted as, "I have a 'sampletag' data element that contains the text 'Hi, Laban people!'."

It's possible to nest XML tags. So for instance, I could do something like this:

<sampletag>Hi <sampletag>there</sampletag></sampletag>

In that example, there are two 'sampletag' tags. One, containing the text 'there', is included as part of the data contained in the other.

In XML, the names (such as 'sampletag') of the tags are chosen by the people designing that particular XML 'schema'. In the case of Labanotation, our schema would include tags like <rightmiddle> or <floorworkstaff>

Notice that the relationships between XML tags are very simple: a tag can be inside of another tag, or it can be a 'sibling' with another tag, for example, <tag>hi</tag><tag>there</tag>". It's against the rules of XML to have overlapping tags, like this:

<onetag>this is an <anothertag>illegal usage</onetag> of XML </anothertag>

In the above example, the "onetag" tag contains the opening "anothertag" tag, while the closing "anothertag" tag is outside of it. That creates difficulties with interpreting the relationship between information, and so it's just illegal to do it in XML. XML keeps the relationships between information very simple.

It's also possible to introduce modifiers for tags. These are contained within the angle brackets, but look like variable assignments in programming languages. For example:

<expandedstaff name="personA" gender="female"></expamdedstaff>

The "name" and "gender" variables are just as subject to the needs of the user as the tags themselves. The people who design the 'schema' choose all the tag names and modifier names. In the XML world, these modifiers are called 'attributes'.

It is possible to represent extremely complex information relationships with XML. There would be no technical obstacle to creating an XML schema that could fully represent any Labanotation score.

There would be a number of benefits to this. Someone could write a computer program that would read the XML and output a well formatted Labanotation score. Or it could output video that depicted animated dancers to some degree of accuracy.

It would also be possible for a computer program to compose a dance sequence itself, using the XML tags as building blocks. These are much more compatible with computer data manipulation than an actual written Labanotation score.

It's important to bear in mind that XML is not concerned with typography or placement of symbols, or any of the visual aspects of Labanotation. It is simply concerned with the boiled down relationships between the movement ideas represented in Labanotation. For example, if we had a good XML schema for Labanotation, we might write a score using that schema. In the score, we might say that the body key applies to a forward arm gesture. XML could represent this as follows:

<bodykey><gesture><arm direction="forward" timing="1measure"></arm></gesture></bodykey>

As you can see, the actual meaning of this XML is something that must be interpreted by a computer program that knows how to interpret it. The XML schema does not contain information about the body key itself, or how it may be used, or where the arm symbol must be written in order for the body key to properly apply to it. All of those details are excluded from the XML schema intentionally.

In the above example, the computer program interpreting the XML score, would first look at the tag, and say to itself, "OK, everything inside this tag is going to be performed from the body key perspective." Then it would look inside the tag and see that it contained a tag. Now it knows a gesture is going to be performed. Within the tag it sees an tag. Now it knows the arm is going to move. It reads the arm tag to see that the movement will be forward, and will occur over a single measure.

Depending on the purpose of the computer program interpreting that XML, it might then want to output a standard Labanotation score. In that case, it would consult a complex database of information, to see what symbols to use, and how they should be laid out in order to express the movements represented in XML. That whole database and all its information is not part of XML, it is completely unrelated. That is the whole point. XML is used to express the relationships between data. What the computer program might do with those relationships, whether to produce a written score, or animation, or something else, is entirely outside the scope of XML.

So that is my very brief explanation of XML. It is a very powerful technology, and creating a good Labanotation schema would create a very powerful bridge between the Labanotation world and the computing world.

That said, no one should be under the illusion that creating a Labanotation XML schema will be easy. It would be a very difficult, long-term task that no one here is suggesting would be done quickly. But it's a very good and useful idea, that deserves whatever effort folks are willing to put into it.

[end of Zack’s LabanTalk posting]

After reading Zack’s posting the group discussed the topic:

Zack explained that XML is a way of representing information on the computer so it can be transformed and manipulated by the computer. Currently, if you have a L/N score on paper, you can’t do anything to it; you can just read it. Making changes in the score often involves a lot of work, even using LabanWriter. With XML the data is all in a form that is digitized. A L/N XML would make it possible to easily make complex changes in a score and to use Labanotation in many new applications.

Zack showed how L/N might look in XML (just an “on the spot” idea, which might be different if he had more time to think about it). In example 1a the XML describes the starting position in the notation. (The information for the entire score would begin with the tag , and end with tag , similar to HTML).

Could a L/N XML schema accommodate glossary issues?

Yes, as long as the glossary item can be explained in L/N symbols. For instance, the schema could include Ex. 1b.


The schema could be designed to accommodate anything one wants. However, including glossary items from many different scores could be difficult. The schema has to get bigger and bigger every time another tag is added to it. At some point in the creation of the schema, one would have to stop, and that stopping point will represent the limitations of that version of the schema. Anything someone wants to do beyond what that version of the schema provides, they won't be able to do.

The XML schema should be based on standardized, established L/N symbols and usage. This would make the schema versatile, so it could be used for a huge range of applications (including many that have not even been thought of yet).

It is important to keep in mind that the XML is just the data structure. Computer programs can be written to modify that structure for various applications.

Zack: There are two issues that need to be considered:

1) Representing data so it is an accurate representation of Labanotation. XML can do this.
2) Verifying the usage of the data. XML would not do this. XML represents only the data, precisely because that frees up the user from concern over how the symbols look, whether they are laid out properly, how they might be interpreted by a dancer, etc.

XML would act as a bridge so that Labanotation can be used in many applications. Several examples were mentioned during the course of the discussion:

• A computer could compose its own dances by using the generic Labanotation elements and then “splashing them together.” (The group wondered if this would be a dance, or just a score of symbols.)
• Manipulating themes, e.g., to create a “theme and variations” dance.
• Creating an animation of a score.
• Analyzing the movement in a dance, e.g., comparing how many or where given movements occur.
• Analyzing spatial components in architecture or interior design.
• Converting scores directly into LabanWriter.
• Transferring information between different systems or programs.

[Addendum from Zack: The XML schema would make a new kind of innovation possible, that would be different from those that currently take place. Computer application writers would be able to write programs that were compliant with the XML schema, i.e., that allowed the user to make correct use of all the elements of the schema. But those application writers would also be able to 'extend' the schema in their own ways, to accommodate their own ideas of what Labanotation should do. While these 'extensions' would not be part of any standard, they would be divergent modifications of the standard schema, and could be incorporated into future versions of the schema, just as ICKL incorporates current nonstandard usage into the standard Labanotation.]

The process of creating the XML would require skill that DNB notators do not have, so initially it may not be directly useful to them. However, XML would greatly expand the application of Labanotation, which would ultimately be beneficial to the DNB and the development of L/N.

The creation of a good XML schema would need to be a collaboration between experts in XML and Labanotation.

Practical issues involved with creation of the schema: It would involve a lot of time. One would have to codify every aspect of Labanotation, design key words for each part of the system, and clarify how those parts should be interpreted by a computer. Funding would probably be needed to pay for a Labanotation expert. However, Zack, who has expertise in XML, would be willing to work on the project for free. [Addendum from Zack: My role would be to explain the requirements of an XML schema, and work with the Labanotation experts to design that schema. The value I would bring to the project would be to explain the technical aspects and requirements of XML; to clarify when an element of the schema would be appropriate or inappropriate to include; to prevent the project from falling into certain common pitfalls that could have long term negative repercussions.]

Since creating the XML would be an enormous project, would it be helpful to start by having it created for a specific application? Perhaps knowing exactly how XML might be useful to notation could encourage the investment needed for such a project.

Zack: Creating the XML schema without thinking first of a particular application might be better way to proceed. As often happens in scientific research, many advances come from abstract ideas which at first do not seem to have a practical use, but ultimately inspire completely new innovations.

Some people in the group were concerned that starting with a huge grandiose project that included all aspects of Labanotation would not be practical or productive. It would not be possible at the DNB, given its limited resources. Maybe it would be better to work on the schema incrementally, piece by piece. For instance, first there might be a small project that would just need “elementary” symbols. Then the schema could be expanded and refined over time.

[Addendum from Charlotte: Issues related to this topic are discussed in “International Conference Exploring Research and Programming Potential for Labanotation”


TOPIC #2: Amount and Size of Paths

The group read the following posting which Charlotte and Ray had placed on the Theory bulletin Board (Paths thread, June 15, 2007).

Indicating the Amount and/or the Size of a Path
by Ray Cook and Charlotte Wile

Last summer at ICKL, Ann Guest presented a paper about the confusion that sometimes arises because measurement signs, such as those in Ex. 1 and Ex. 2 below, have various meanings. Her paper got us thinking about the use of those signs in path indications.

For instance, according to standard usage, Ex. 3 indicates 1/4 of a large circle. In other words, the measurement sign shows the size of the path design and the pin shows the amount of that design that is traveled on or traced. Ex. 4 just indicates an amount (size is not stated). Following this pattern, Ex. 5 just indicates a size (the amount is not stated).

In Ex. 3 and Ex. 4 the pin states a specific amount (1/4). How would one indicate a general amount, e.g., a relatively "large amount," or a relatively "small amount"? The measurement signs in Ex. 1 and Ex. 2 should not be used, because, as stated above, they are already used to indicate the size of the circle.

To deal with this issue, we suggest the following:

The amount of the path that is traveled or drawn could be indicated with a pin (to show specific amount) or a plain measurement sign (to show a general amount). (Ex. 6)

The size of the path design could be indicated with a measurement sign inside the sign for space, as in Ex. 7. This corresponds with the meaning of that sign inside a design drawing indication, as in Ex. 8.

Thus size and/or amount could be clearly and consistently stated, as illustrated below.

Ex. 9) any amount of any size circle
Ex. 10) small amount of any size circle
Ex. 11) any amount of a small size circle
Ex. 12) small amount of a small size circle
Ex. 13) small amount of a large size circle
Ex. 14) 1/4 of a small size circle
Ex. 15) any amount of any large size path

Question: How would this idea apply to straight paths? For instance, is there a difference between Ex. 16, which says to move a small amount (i.e., move a short distance) on a straight path, and Ex. 17, which says move on a straight path that is short in size? Could both modifiers be used, e.g., move a small amount of a long straight path Ex. 18?

[end of Charlotte’s and Ray’s Theory Bulletin Board posting]

The group discussed the ideas presented in the posting.

The difference between path size and distance traveled on a path were clarified with drawings. Ex. 2a depicts traveling a short distance on a small sized circle. Ex. 2b depicts traveling a short distance on a large sized circle.

The group felt the ideas expressed in Charlotte’s and Ray’s posting could be useful in Motif Notation.

Would the proposed changes be appropriate for Labanotation?

In Labanotation a size sign inside a path sign can have different meanings. For instance, in Ex. 2c the “x” indicates a small distance, whereas in 2d it indicates a small size circle (see Guest, Labanotation, 4th edition, 2005, pp. 162, 453).

Some people in the group felt this is not a problem since the meaning of the indications is clear when they are used in the context of a score. The size of a circular path is shown by the number and length of the steps, as in Ex. 2e, so there is no need for a generic sign such as Ex. 10 in Charlotte’s and Ray’s posting. They said the established signs work well and changing them would be confusing.