[sw-l] Sign Variants via SWML
Stephen Slevinski
slevinski at SIGNWRITING.ORG
Mon Oct 18 19:59:27 UTC 2004
Variants are trying to express related signs (fish and flat-fish) and signs
with a range of expression (child). Signs with a range of expression are
very interesting because they communicate additional information. Not just
a child, but the age of the child. Not just a ball, but how big of a ball.
Not only happy, but how happy. A single written sign can not encompass all
of the variation for the sign. There are also directional verbs that have
similar transformations; like ask, give, and help.
I ask/give/help you.
I ask/give/help her.
I ask/give/help them.
I ask/give/help all of them.
I ask/give/help each of them.
I think it is too early to include more information about the construction
of the sign than just the symbols and their positions.
Ultimately, I think we are talking about a searching issue. If so, we need
to discuss what we are searching for and how we will store the information.
Searching for construction is a complicated topic, and a programming effort.
When searching for minimal pairs, a program would be ideal.
Searching for meaning is a nuanced topic, and a linguistic effort. Meaning
can be hierarchical (good, better, best), or related (happy and glad), or
opposing (happy and sad).
XML was not created for searching, but communication. It is possible to
search XML, but a database is the best place to store information that needs
to be searched. The idea is to query a dictionary and have the dictionary
return the results. The dictionary may return the information in SWML, but
the dictionary will not maintain the information in SWML. A database can
also include pre-processing that optimize the information for quicker
searching.
We need more information in the dictionary, such as specific types or
relationships between signs. Is the idea of hierarchy, related, and
opposing sufficient? What types of relationships exist betweens signs that
a linguist can maintain?
We also need advanced searching based on a signs construction. Papers have
been written on this topic. It will require enormous efforts in design,
usage, and redesign. The Sign Puddle dictionaries will supply a large
testing bed for searching scheme based on construction.
For what it's worth,
-Stephen
-----Original Message-----
From: owner-sw-l at majordomo.valenciacc.edu
[mailto:owner-sw-l at majordomo.valenciacc.edu]On Behalf Of Sandy Fleming
Sent: Monday, October 18, 2004 6:18 AM
To: sw-l at majordomo.valenciacc.edu
Subject: [sw-l] Sign Variants via SWML
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
More information about the Sw-l
mailing list