[sw-l] Are We Going in the Wrong Direction?

[dparvaz at MAC.COM]

>> If we want to tackle linearity, it's worth looking at where other
>> linear systems fail. So SignFont, HamNoSys, Stokoe, and related
>> systems
>
> These fail because they're not visual and don't express all necessary
> aspects of sign language. This doesn't apply to SignWriting.

When you say a writing system is 'not visual', what do you mean?

> Firstly, the writing system we're trying to store is 2-D not 3-D, so
> it's not as difficult as you might think!

Right, but if you're storing them in linear format, it's a 1-D
representation of a 2-D writing system for a 3-D language. The part
which makes the strings longer is precisely the part which has to do
with position. In these other systems, there are characters for
position that either amount to a place on the body, or a 3x3x3 signing
space in front of the upper body. Furthermore, the systems designed to
be linear make contact explicit, as in 'the dominant handshape is
contacting the torso on the ulnar side.' In SW, that 'necessary aspect
of sign language' has to be inferred by looking at the 2-D
representation. Perhaps that's what you mean by visual -- the writing
system depends on our visual systems to fill in the informational gaps.

What I think I didn't get is that this is not a substitute for SW, just
a means of storage, so it doesn't matter if it's legible :-)

There is also another concern. If we're using fonts, which I presume
are scalable, how are the coordinates stored? As percentages of the
space? At what point does the scale interfere with rendering (e.g. make
things touch which aren't supposed to be touching, introducing awkward
distances which might be solved by further fractional percentages)?

And how does this influence our searches one way or another? Right now,
I can do a search in SWML looking for signs which have, say, a head and
a contact symbol, regardless of linear order. The hierarchy in the DOM
gives me that for free. The complexity comes when I look, say, for
contact at the temple, which means the contact symbol is in a region at
a certain range of distances (either city-block or Euclidean) from the
head symbol. Using scalable fonts and linear representations do nothing
to simplify that problem.

Perhaps your system makes sense for typing, assuming that coordinates
can be entered in a meaningful way at a speed which makes a difference.
But for searching, and other forms of text processing beyond entry, I'm
not convinced that we're served by flattening the structure. Perhaps
the signs could still be stored internally in a tree?

Not trying to _make_ things difficult, but I find that oversimplifying
a solution at the outset simply delays the headaches. :-)

-Dan.