An attempt to formalise notation for String Figures

Introduction

There are as many ways of describing string figures as there are anthropologists, but codifying these currently falls into two camps - 'SFN', and the ISFA conventions. Both have their advantages and disadvantages (which I shall not go into for fear of upsetting either), but neither is a true 'code' as I (as a computer programmer) understand the term - at some point, they both rely on (potentially untranslatable) English descriptions to either describe or clarify a move, and are better described as shorthand rather than code as such.

Again, as a programmer, I have the geeky urge to collect / formalise / manipulate the thousands of figures out there, which calls for two things - a standard storage / transfer format, and a means of translating the figures' instructions in such a way that they can be reproduced by human *or* computer - in fact, a string programming language. Ideally, it should be possible to write (say) some VRML that reads a set of instructions, manipulates virtual fingers / strings and ends up with a 3D model that can be viewed from any angle. This would also remove the need for either a diagram or a formal 'knot description' as part of the storage format, as this could be recreated by a parsing tool. In addition, the instructions would be much more easily translated into other human languages, having a simpler but more formal grammar.

The file format was fairly simple - I took the ABC Music format as a model, it being a very simple human-and-computer-readable format that describes much the same kind of information - a bunch of 'meta-information' (Name, Origin, String size etc.) and then instructions for reproducing the 'figure' (as it were). I considered an XML-based format, then decided against it. Were the format any more complicated than simply a bunch of headers and steps, then maybe it'd be worth the effort - but the thrust is towards a programming language. XML is a data transfer format, and attempts to turn it into a programming language are doomed. (That's my ha'pence anyway).

The notation obviously was (and still is) a lot more difficult. SFN 'looks' more code-y, so I took that as a primary model (not least because of busybee's large collection) and attempted to formalise the grammer in Backus-Naur Form - a standard way of describing grammars. (Once this was done, I converted it to Damian Conway's excellent Parse::RecDescent format, which is similar, but slightly more useful :) This is the form that it currently takes - when finished, I'll re-convert to BNF). Some useful code-tokens were taken from ISFA, and wherever possible, the same terminology is used as in both SFN and ISFA.

Finger Descriptions

There were two reasons for using letters rather than numbers to describe fingers, one to do with personal preference (I still mix up 1 & 2 - "but it's my *first* finger..." - and find T and F a lot easier to 'connect with'), but more importantly from a coding point to view - numbers descibe *numbers* of things (2bTN = 2 bottom Thumb Nooses) rather than things themselves, and I was sure at some point it would cause almighty confusion in the mind of some poor programmer writing a parser...so I make no apologies to the ISFA camp :). If it's that much of a problem, I'm sure you'll be able to tick the "Use ISFA Finger Notation" checkbox in whatever tool is reading and translating the code. I give in! Of course, 1 to 5 is much less anglocentric, and actually makes parseing easier, leaving me more letters to play with! Ooops - all fixed now! :)

The File Format

A (.sfn?) file consists of a number of records, separated by blank lines. A record consists of a number of header lines, followed by a set of instruction steps. Here is a complete record:

NAME:Opening A
CODE:OA
[P1]
R2 pu LP ex
L2 mt rl R1N pu RP ex

Line 1 assumes that elsewhere is defined:

NAME:Position 1
CODE:P1
1 pu SN ex
5 pu 1f ex

The only compulsory header is the NAME: field, but if the figure is to be referenced elsewhere, it needs a unique CODE: field. This also allows for alternative names / origins for figures - for instance:

NAME:Jacob's Ladder
CODE:JACOBSLADDER
ORIGIN:?
[OA]
etc.

NAME:Osage Diamonds
ORIGIN:Navaho
[JACOBSLADDER]

NAME:Fishnet
ORIGIN:Australia
[JACOBSLADDER]

The Grammar

A Step is made up a single instruction, which can be any one of:

A Code Reference, in square brackets, referring to a set of previously defined instructions with the corresponding CODE: header field. This can be a simple opening/ending such as [P1] or [CE], or a reference to another full figure, used for continuations. For instance, the complete record for 'Tahiti and Moorea' looks like this:
```
	NAME:Tahiti & Moorea
	ORIGIN:Tahiti
	[SCISSORS]
	re 1 ex 
	
```
where the 'Scissors' record has a (unique) CODE:SCISSORS header line. I suggest the keeping of two figure codes for the common openings / endings (OA, NE etc.) but then being as verbose as possible with 'full' figures. Code 'fragments' could also be re-used this way, such as the "1 mu 2N, 1 pu 5n, 5 mo 2f, 5 mu 2n, 5 pu 1n" sequence in 'The Bed' / 'Pole Star' / 'Darkness' figures.
A 'Full Move' - fingers do something with or without strings.

A Repeat instruction, such as 'rep 2-4' . This may have an optional 'swap' modifier, meaning 'all references to the first token are to be replaced with the second token and vice versa'. For instance:

L1 pu RP		# left thumb picks up right palmar string
L1 >> ret		# left thumb rotates a full turn and returns
rep 1-2 sw L R		# repeat steps 1 to 2 swapping left for right

could be expanded to:

L1 pu RP		# left thumb picks up right palmar string
L1 >> ret		# left thumb rotates a full turn and returns
R1 pu LP		# right thumb picks up left palmar string
R1 >> ret		# right thumb rotates a full turn and returns

So, in P::RD grammar, a step looks like this:

step: (code | fullmove | repeat) comment(?)

(Actually, these days it looks like...)

validstep:	code_ref | repeat | fullmove | voice 
stepline:	"{"(?) validstep "}"(?) comment(?)

where the braces indicate alternative steps.)

Moves

You'll notice above that in general code lines are very short. The grammar is designed to be as 'tight' as possible - a 'move', for instance, consists of a bodypart designation, a movement instruction and a string designation in that order. The bodypart and string designations can be multiple (eg: L12 mo L4nL5n), and if only a single bodypart is involved, moves can be 'chained'. For instance, lines 1 & 2 above could be concatenated to:

L1 pu RP >> ret	# l thumb picks up r palmar string, rotates and returns

A 'fullmove' is defined as

fullmove: ( manouvre | action | transfer | tension | extension | flip ) modifier(?)

where we have already defined:

manouvre: do [something] to fingers/bodypart. eg:

re 2	# release index fingers
na 1	# navaho thumbs

action: fingers/bodypart do [something] (rotate, move, pick up)

2 pu 1n			# forefingers pick up near thumb strings
2 mt di 5N pu 4n ret 	# forefingers move distally through little finger noose, pick up near ring finger string and return

transfer: move a noose to another bodypart

tr 2N 3	   # transfer forefinger nooses to middle fingers
tr 5N 2 di # distally transfer little finger nooses to forefingers 
           # (proximal transfer is assumed if no direction specified)

tension: bodypart holds tight / lets slip

ls 2	# let slip the forefinger strings
1 ht 2n	# thumbs hold tight near forefinger strings

extension: extend (an optional bodypart)

ex	# extend shape
ex 2 up	# extend forefingers up

flip: flip a loop in a direction

fl nHS nf	# flip near hanging string to far side of hand

modifier: keep loose, extend, return etc.

re 2 ex		# release index fingers and extend
re 2 kl		# release index fingers and keep loose
re 2 ret	# release index fingers and return
re 2 ,		# release index fingers *then*... (do the next move immediately, or as part of this one)

The full grammar definition can be found in 'SFNParse.pm' on the files page.

Between them, SFN & ISFA define around 30 separate single moves (move away from you, twist, depress etc.) Ideally, these would be pruned as much as possible. In many cases, this can be done with simple rephrasing ( where say, a 'distal' or 'proximal' pickup could replace some more complicated 'move over strings x and y, pick up string z' etc.), but I fear that as more and more figures get translated, we may end up needing much of the existing 'instruction set'. A lot of the descriptive instructions though ('between', 'around') I'm sure can be replaced simply by using stricter move instructions.

Sometimes though, defining a move can be tricky. Part of the problem lies in the fact that what actually *happens* may differ from *how* it happens. For instance, the '5 mt di 2N pu 1f' sequence in 'The Bed' (little fingers distally move through forefinger noose and pick up far thumb string) is a complete description as far as a parser is concerned, but is in real life a lot easier if the ring fingers get involved in a pincer movement. Often though, this can be indicated using comments.

Alternative steps can be placed in braces to indicate differing routes to the same destination - for instance, given two slightly different moves in 'The Bow' (from Diné and busybee respectively):

1. Navajo Opening.
2. 1, over 2n, picks up 2f.
3. 345 hook down 2n.
4. 3 picks up lower 1f and points upward
5. Release 1 loops and extend. 

1 NO:T mo-pu fFS
2 M mo-pu fTS:RL mu-gr nFS
3 re T, ex

we can do:

[NO]			# Navaho opening
1 mo 2n pu 2f		# Thumbs over near index & pick up far index
{ 3 mo 1n pu 1f		# Middle over near index pick up far thumb...		}
45 mu 3f gr n2}	# {...then Ring & Little under far middle + grab n index	}
{345 gr 2n		# ALTERNATIVELY { MRL grab  nF...}
3 pu 1tf ex}		# { then Middle picks up bottom far thumb and extends}
re 1 ex

Specifying a single string can be confusing. A stringdesc: allows for bracketed alternatives after a string description - eg:

5 pu HCS (HXS)	# little fingers pick up hand center strings (hand crossed ones) (hand is the 'default manipulator')

Figures.

An example figure is shown below.

NAME:Fishing Spear
ORIGIN:Pacific
STRING:8
[P1]
R2 pu LP >> ret
L2 mt lr R2N pu RP ret
rel R15N

Here is the original SFN.

1 P1
2 rF pu lPS
3 ma-tw rFN
4 lF pu rPS th rFN 
5 re rTN+rLN (at same time)

Not only is the first form more concise, but as the grammar is clearly defined, it can be translated back into English with a simple parser:

C:\Work\String>perl testparse.pl spear
Name : Fishing Spear    Origin : Pacific  String: 8
1 Perform P1.
2 Right forefinger pick up left palm string , twist a full turn away from you and return.
3 Left forefinger moves from left to right through right forefinger noose , pick up right palm string and return.
4 Release right thumb noose / right little finger noose.

A more complicated parser could improve the readability of this further. For instance, by swapping the word order and sprinkling in some articles, we get:

1 Perform Position 1.  
2 Pick up the left palm string with the right forefinger, twist it a full turn away from you and return to position.
3 Move the left forefinger from left to right through the right forefinger noose, pick up the right palm string and return.
4 Release the right thumb and right little finger nooses.

while a 3D graphical-representation parser may do something like this:

do_code("P1");
move_hand("r",-80, 0, 0); # move over to other hand
pickup("rF","lP");	  # do the pickup
twist("rF",360) ;	  # twist +360 
move_hand("r",80, 0, 0);  # return back to position

...etc. More examples can be found in the 'figures.sfn' file on the files page.

(Also in the files page is the extremely rough Italian version, as a 'proof of concept', which produces...

1 Eseguire P1.
2 Destra dito indice far salire sinstra palmo spago , deformare intero giro e lo
ntano e ritornare.
3 Sinstra dito indice movesti da sinstra a destra attraverso destra dito indice
cappio , far salire destra palmo spago e ritornare.
4 Rilasciare destra pollice/dito mignolo cappio.

I know it's awful, but if anyone out there would like to have a play, please feel free...).

The future

There is some marvellous work going on out there, and I hope this small paper and the associated software will spur others to greater heights. Comments are most welcome - this is simply the result of a few days work on what I hope will be an ongoing project, and I'm sure it'll be many moons before it's finished to the satisfaction of the cogniscenti - and all offers of help would be gratefully received :) General comments can be posted on either of the Yahoo stringfigures / string-figures lists, or you can mail me at bdaglish [at] oxhut.co.uk. Thanks for reading.