[sw-l] Sign Variants via SWML
rocha at ATLAS.UCPEL.TCHE.BR
rocha at ATLAS.UCPEL.TCHE.BR
Mon Oct 18 13:16:07 UTC 2004
Dear Sandy,
Thanks a lot for the message! Very interesting ideas!
First, let me clarify: sign-boxes and cells, as you mentioned, are
concepts regarding different issues, the first concerns the rendering of
the sign itself, the second concerns formatting issues. So, conceptually
each should have its own position information, sign-boxes being
positioned inside cells, and cells inside lines (or pages). In SW-Edit,
since we allow only one sign-box per cell, we fused their position
information. But you are right, they are conceptually distinct.
"Flop" is the word Valerie and Rich Gleaves used to refer to the
mirroring of symbols. In SignWriter, there are only flops regarding the
vertical (y) axis. In SW-Edit, since we were not able to put a rotation
button in the current version of the program, we were forced to
introduce the flop regarding the horizontal (x) axis, so all symbol
rotations could be produced by combining vertical and horizontal flops
(using the right button of the mouse over the selected symbol).
Now, with respect to your very interesting idea of variants. It made me
realize that we can think of various kinds of variants:
1) variants of complementary symbol features, like variation, fill,
rotation and position (the offset variant idea is perfect!)
2) variants at essential symbol features, like category, group and
symbol id, which amount really to the use of different symbols for the
same sign (e.g., different face expressions for different uses of the
sign)
3) variants at the sign level, where different signs are to be
considered variants of one another
I was more concerned with variants of kind 3, when I suggested levels of
conceptualization for SWML. Also, I was thinking of information like the
one you suggested (ranges of variations) which I still think should be
kept separated from the level where SWML describes the visual
organization of the signs, because such variants and information are
more of a linguistic kind, not essentially concerned with writing
issues.
But now you introduced a very interesting new idea, variants at the
level of the written organization of the signs. That's great!
Variants of kind 1, as you mentioned, are certainly of that kind.
Variants of kind 2 have to be examined in more detail. Perhaps they
should be merged with variants of kind 3, as variants concerned with
linguistic features of the signs, not with writing issues.
The introduction of variants of kind 1 will certainly place additional
complications in the rendering producedure of signs, but your examples
convinced me that those variants are worth being supported in rich sign
databases (dictionaries).
All the best,
Antônio Carlos
> 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
>
>
-----------------------------
Antônio Carlos da Rocha Costa
Escola de Informática - UCPel
More information about the Sw-l
mailing list