[sw-l] Sign Variants via SWML
Sandy Fleming
sandy at FLEIMIN.DEMON.CO.UK
Mon Oct 18 10:18:26 UTC 2004
Hi List!
There are bits of SWML in this post but if you want to skip it I hope you'll
still find some of the ideas expressed in plain English to be an interesting
read :)
Antônio Carlos wrote:
> Only that it will perhaps be another level of abstraction than that
> at which SWML is operating at the moment. Currently, it is operating at
> the level of the graphical representation of the signs, as a simple
> translation of the numerical description of the SignWrirint picture.
>
> Adding information like the possible range of values seems to me to
> go beyond that very low level of description. It brings information that
> concerns things outside the scope of the visual representation of a
> (standard) way of making a sign.
>
> It goes into semantical and pragmatical issues. To me, this would
> mean a new level of operation for SWML. Let as name SWML Level 0 the
> current level. Other SWML levels would have to be defined: SWML Level 1,
> SWML Level 2, etc., according to the complexity of the issues that are
> added to the representation of the sign, going beyond the representation
> at the basic level.
I've been thinking about this and I think the solution is very simple
(famous last words! :)
Two variants of "fish" I know in BSL are "fish" and "flatfish" (see attached
gif).
Here's the SWML for those two signs as they might appear in a dictionary
(I've used glosses here but the idea works just as well in a gloss-free
system):
<signbox>
<gloss>fish</gloss>
<symb x="79" y="57" x-flop="0" y-flop="0" color="0,0,0">
<category>01</category>
<group>05</group>
<symbnum>007</symbnum>
<variation>01</variation>
<fill>05</fill>
<rotation>03</rotation>
</symb>
<symb x="33" y="58" x-flop="0" y-flop="0" color="0,0,0">
<category>02</category>
<group>05</group>
<symbnum>001</symbnum>
<variation>03</variation>
<fill>01</fill>
<rotation>03</rotation>
</symb>
<symb x="40" y="45" x-flop="0" y-flop="0" color="0,0,0">
<category>02</category>
<group>02</group>
<symbnum>008</symbnum>
<variation>01</variation>
<fill>02</fill>
<rotation>01</rotation>
</symb>
</signbox>
<signbox>
<gloss>flatfish</gloss>
<symb x="79" y="57" x-flop="0" y-flop="0" color="0,0,0">
<category>01</category>
<group>05</group>
<symbnum>007</symbnum>
<variation>01</variation>
<fill>06</fill>
<rotation>03</rotation>
</symb>
<symb x="33" y="58" x-flop="0" y-flop="0" color="0,0,0">
<category>02</category>
<group>05</group>
<symbnum>001</symbnum>
<variation>03</variation>
<fill>01</fill>
<rotation>03</rotation>
</symb>
<symb x="40" y="45" x-flop="0" y-flop="0" color="0,0,0">
<category>02</category>
<group>02</group>
<symbnum>008</symbnum>
<variation>01</variation>
<fill>02</fill>
<rotation>01</rotation>
</symb>
</signbox>
Here's a new version of this SWML, where I simply add a "variant" attribute
to anything that's different between the two signs. This makes it possible
to represent the two signs as a single dictionary entry, with variants:
<signbox>
<gloss variant="1">fish</gloss>
<gloss variant="2">flatfish</gloss>
<symb x="79" y="57" x-flop="0" y-flop="0" color="0,0,0">
<category>01</category>
<group>05</group>
<symbnum>007</symbnum>
<variation>01</variation>
<fill variant="1">05</fill>
<fill variant="2">06</fill>
<rotation>03</rotation>
</symb>
<symb x="33" y="58" x-flop="0" y-flop="0" color="0,0,0">
<category>02</category>
<group>05</group>
<symbnum>001</symbnum>
<variation>03</variation>
<fill>01</fill>
<rotation>03</rotation>
</symb>
<symb x="40" y="45" x-flop="0" y-flop="0" color="0,0,0">
<category>02</category>
<group>02</group>
<symbnum>008</symbnum>
<variation>01</variation>
<fill>02</fill>
<rotation>01</rotation>
</symb>
</signbox>
The simplifying principle here is to leave all the semantics up to the
lexicographer.
Imagine, for example, a lexicographer building a dictionary and coming to
the sign for "child". If his aim is to build a small dictionary for
educational use (for example, for English-speaking learners or
schoolchildren who are learning both BSL and English), he might decide on
three variants as follows:
child
infant
teenager
He then enters all three in the dictionary but the dictionary entry tool
enables him to specify that these are variants of the same sign.
On the other hand, if his aim is to produce a very comprehensive dictionary
with all-purpose variants for advanced users he might take a different
approach and gloss, say:
child-of-about-3
child-of-about-4
child-of-about-5
etc.
This would be quite feasible because they would all be just one sign in the
dictionary and take up only a a little extra space for each variant.
Or he might be writing a pure BSL dictionary with no glosses, which is even
easier.
There are quite a lot of advantages to this sinmple upgrade to SWML.
Lexicographers can create bigger, better dictionaries with less work and
less disk space used. Word processors and educational tools could display
all variants of a sign, so, for example someone looking up "fish" could
request to see all variants and discover the sign "flatfish" as well, which
might be the sign they really need they but didn't know it (it's a little
bit like having a thesaurus!). People who don't use glosses but prefer to
type purely in BSL could still check all variants and just select the
variant that best suits what they're trying to express.
Note exactly what is happening here in sign language terms - a simple
data-entry technique begins to automatically provide a partial thesaurus
because of the nature of sign languages. Meanings like "annoyed", "angry"
and "furious" are all variants of one sign in BSL. Thus what in spoken
languages would require a thesaurus to discover is a simple matter of
inflection in sign languages, and this "variant" attribute in SWML makes
this information available to dictionaries. It's like when in spoken
language dictionaries they define "walk" and then list "past pl: walked;
present pl: walking" etc. It perhaps ought to be considered an essential
feature SWML.
If all we had to worry about was position then this wouldn't be so great -
the writer could just drag things into the position he wanted. And yet his
drag and dropped document isn't likely to have any precise positioning
standards - it would all depend on how precise his drop was. And with signs
like "fish" we get variants that signers with weaker vocabularies might not
even have thought of.
What do you think? Or anybody?
Note that unfortunately there is a slight problem, in that when it comes to
a sign such as "child" in which the variation is actually in the position of
a symbol rather than the orientation, fill and suchlike, the variant has to
be applied to the <symb> tag attributes. I think this is actually an
indication that these attributes should be tags, not attributes, eg:
<symb x-flop="0" y-flop="0" color="0,0,0">
<x>33</x>
<y>58</y>
<category>02</category>
<group>05</group>
<symbnum>001</symbnum>
<variation>03</variation>
<fill>01</fill>
<rotation>03</rotation>
</symb>
I don't know what a "flop" is so I've left it alone :)
So you can have a dictionary entry like
<gloss variant="1">child</gloss>
<gloss variant="2">infant</gloss>
<gloss variant="3">teenager</gloss>
etc...
<symb x-flop="0" y-flop="0" color="0,0,0">
<x>33</x>
<y variant="1">50</y>
<y variant="2">40</y>
<y variant="3">80</y>
etc...
</symb>
To put it another way, the symbol position is spelling information the same
as all the other information that goes to make up the sign, so it should be
treated in the same way in the SWML. If there is good reason for the
position to be expressed as attributes, however, the variant positions could
be expressed as offsets from a "default" symbol position, eg:
<gloss>child</gloss>
<gloss variant="1">infant</gloss>
<gloss variant="2">teenager</gloss>
etc...
<symb x="79" y="50" x-flop="0" y-flop="0" color="0,0,0">
<y-offset variant="1">-10</y>
<y-offset variant="2">30</y>
etc...
</symb>
Or perhaps the <signbox> should have a position and the symbol positions
should be specified as offsets from the sign position. This makes a lot of
sense, doesn't it, since signs should have the same spelling regardless of
where they're positioned? I suppose the <cell> could be used for this
purpose rather than the <signbox>, but this would create problems with
different dialects of SWML, which might not use the concept of a cell.
I think by far the best solution (even if we're not adopting variants) is to
let the <signbox> have position attributes, so that spellings in different
SWML-using software can be made consistent. Positioning of symbols should be
relative to the sign, not to some software-dependent construct such as the
cell.
Sandy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fish.gif
Type: image/gif
Size: 1592 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20041018/894831dd/attachment.gif>
More information about the Sw-l
mailing list