forum SignWriting List Forum
  Message 3375  |  Previous | Next  [ Up Thread ] Message Index
From:  Stuart Thiessen
Date:  Tue May 9, 2000  2:25 pm
Subject:  Re: SW in Databases


At 18:34 05/08/2000 -0400, you wrote:
>You know... there's an interesting concept when developing things like this to
>do so in the mother tongue of the speaker or in the dominant language. I'm
>wondering, though, if such a database could be open-ended enough to
>include all
>the other spoken languages that have been connected with sign writing. I
>think
>Valerie said there were 17 so far. Of course, if it's open ended enough, it
>could include any future ones added. It may be overkill - perhaps it would be
>better to develope separate translation databases for foreign language
>instruction - but think of the potential. Of course, there would be the
>obvious problems, like a sign meaning a concept in one language that is
>explained by two signs in the other. But perhaps there could be room
>enough to
>include the concepts rather than a single word. So "bear" in one language
>could be "large furry creature" in another.

Theoretically speaking, it would be possible, but probably it is better to
have different databases for each language. If concepts are similar (that
is, if this ASL sign and this DGS sign are roughly the same in meaning),
then we could create a linked field between the ASL and DGS databases.

It is also important to remember that it is possible to create
comma-delimited (or other text-based databases) where there is not a static
number of fields. Unlike most relational databases, the structure of a
text-based database is not required to follow any particular structure. So
long as your database program knows how to interpret the data, you can have
whatever structure you like.

>One other thing. If we eventually get an ISO for sign language would the
>database be flexible enough to change from the linking to picture files to
>linking to the new ISO standard? And then, of course, that begs the question:
>If there are ISO definitions for the different parts of the sign that compose,
>say "bear", how would such a database present the linking of the different
>parts? Would we have to reserve positions? Or will the ISO standard be
>concept orientated - so that "bear" would have a unique ISO number that would
>show up all the pertinent components of the sign into a whole?

I would suppose that the ISO numbers would be to each individual component
of a sign. Linking them to signs themselves would be no different than
having an ISO number for each English word.

>I did some work for someone once who was changing from a DOS version of
>Filemaker to a Windows based database. The more I looked at Filemaker the
>more
>I had to ask the question "Why?" This man had his client database in a format
>where records could be added to ad infinitum. It was a nice, simple setup
>that
>worked but he was "upgrading for the future." Sorry pal, the future is a
>humongous headache.

I have seen the same. Just because it is WYSIWYG does not *necessarily*
make it better or more efficient. Sometimes it is. Sometimes, if it isn't
broke, it oughtn't to be fixed. (SMILE)

>So, I'm thinking... how far can a record go in a simple comma-delimited
>database? If memory serves me right, were talking a finite number of
>characters - so the database would be inherently limited.

Well, for example, I have the entire New International Version of the Bible
-- several MBs of data in one text-delimited database. I have one verse
per record. Granted it is not strictly a comma-delimited file, but that is
actually irrelevant. The character you use for delimiting is not what is
important as much as your program being able to sort out your records based
on that delimiter. BASIC tends to focus on comma-delimited files. Perl
can use any kind of delimited file as long as the delimiter is unique. My
observation has been that most DOS-based programming languages were limited
to 255 or so characters per line. But Perl and other languages these days
are not quite so limited. Perl, I believe, will read in a string as long
as you have memory to contain.

For what it is worth,


Stuart

  Message 3375  |  Previous | Next  [ Up Thread ] Message Index