[sw-l] Sign Variants via SWML
Bill Reese
wreese01 at TAMPABAY.RR.COM
Mon Oct 18 11:39:56 UTC 2004
Sandy,
Very thought provoking. I think your initial use of the variation
variable to show a range of a sign is valid. Beyond that and it gets a
little thorny. "Teenager", "child", "infant" are signed completely
different in ASL instead of as variations of the same sign. Different
sign languages will have different constructions and a complete
thesaurus would show all the signs that have the same or similar meaning
of a sign and those signs may or may not be variants of that sign.
I believe the problem with defining the collection of signs as a
"dictionary" is that we tend to attribute the values of a dictionary to
it. In truth, however, what is being collected is not a dictionary as
much as it is a vocabulary. If we would to expand the concept of the
dictionary, we would need to include a definition. Then all the
attributes of the definition would need to come into play, including
anonyms and synonyms, the use of Val's "pronunciation" symbols, the
meaning(s) of the sign, variations (dialect) of the sign, parts of
speech (noun, verb), etymology, forms (plural, past tense, present
participle, etc), words created from main entry (eg: teach, teacher),
comparative and superlative forms of adjectives, etc.
Bill
Sandy Fleming wrote:
>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 --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20041018/3da11613/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1592 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20041018/3da11613/attachment.gif>
More information about the Sw-l
mailing list