SWML

[rocha at ATLAS.UCPEL.TCHE.BR]

Dear Sandy,

  I think you spotted an important aspect: SWML, in the various dialects
in which it evolved, is a format for the lowest of the various levels in
which texts may be represented, namely, a sequence of symbols. I would
call all of them "SWML level 0".

  Higher-levels of text representation are possible, and I think should be
defined, in order for higher-level processing be feasible, including
input-output of texts (as you mentioned), other kinds of dictionary
searches (based on linguistic features like morphology or semantics, for
instance), and automatic translation (between different sign languages,
and between sign and oral languages).

  The reason the original SWML format was much more complicated then the
versions that appeared later is that those later versions were optimized
for the particular applications and programs in which they were to be
used.

  The original SWML format was defined as a level 0 representation for
signs and sign texts, assuming that higher levels would be defined,
which would possibly require a very detailed identification of each
feature of the lower level.

  Unfortunately, those higher level SWML formats were never defined, so
the complexity of the original format looked unecessary for everybody.

  But I think that there should be no essential conflict between a
operational description of how programs should operate with sign texts,
like you are considering, and a declarative description as SWML is able
to give. I think they are complementary and both necessary.

  All the best,

  Antônio Carlos


  All the best,

  Antônio Carlos
> Hi Steve, Jonathan,
>
> On Wed, 2007-05-30 at 11:50 -0400, Steve Slevinski wrote:
>> Hi Jonathan,
>>
>> You are right that we need a general format for importing / exporting
>> between SignWriting applications.  I'd say that we should clean up
>> SWML-S.  I was also working on a SignPuddle Markup Language that I
>> used internally to import the 1.0 dictionaries into 1.5.  I never
>> finalized the DTD.
>
> I have a problem with SWML, which is that it doesn't describe sign
> structure at all. It acts as a container for SignWriting rather than a
> description of the structure of SignWriting signs (or "characters" as I
> tend to call entire written signs these days).
>
> If programs didn't need to know about sign structure, then it wouldn't
> matter, but I think they do need to know about it.
>
> For a keyboarding program, for example, the software needs to know which
> channel of communication (face, active hand, passive hand &c) it's
> typing in: the keyboard doesn't have enough keys to type every symbol so
> the program needs this structural context.
>
> The software also needs to know such things as which movements belong to
> which channel, so that it can flip, slide or anchor between the active
> and passive hand/arm configurations, replace one head with another and
> so on.
>
> I don't see how you can give the user these sort of features with SWML.
>
> I also don't think programmers should get too hung up on formats! The
> core of a program should respond to a series of procedure or function
> calls and respond with a series of calls. Nothing about the formats
> should be written into the program: instead there should be input and
> output packages that interface between the program's calls and the
> input/output formats, so that different formats can be handled just by
> writing the appropriate package for each one.
>
> As for whether we need two different formats for text and dictionaries,
> well, in text I suppose we need to have styles and suchlike, which we
> wouldn't want in dictionaries. In dictionaries we'd need semantic
> definitions, which we wouldn't want in the text. I suppose we could just
> leave these out as appropriate, but then again, having a dictionary in
> the same format as text could hamper dictionary lookup: a dictionary
> stored as a database would make more sense whereas a text stored as a
> database would make less sense (perhaps?).
>
> Sandy
>
>
>


-------------------------------------
Antônio Carlos da Rocha Costa
Escola de Informática
Coord. Prog. de Pós-grad. Informática
Universidade Católica de Pelotas