|SignWriting List Forum|
Bill Reese |
Date: Mon May 8, 2000 10:34 pm
Subject: Re: SW in Databases
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.
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 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
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.
Stuart Thiessen wrote:
> At 17:08 05/08/2000 -0400, you wrote:
> >On Mon, 8 May 2000, Stuart Thiessen wrote:
> > > Using Perl and Perl/Tk, you could come up with a program that could
> > > store the spoken language, meaning, etc. as text and SW as an image.
> > So you would have to store the "meaning" in a spoken language?
> SMILE so I wasn't very precise in my message SMILE What I meant was if
> desired, fields could be added to explain meaning. If the goal is a
> dictionary that could be searchable, etc. then why not have a field or two
> that can reference meaning as well. For example, if we are defining
> "bear", we could have a field definition such as:
> bear, aslbear.gif, "A mammal that takes walks, finds little girls, and eats
> porridge", aslbear_def.gif
> where we have two gif's that represent the sign itself and the definition
> of that sign in the signed language. There would be a corresponding entry
> for the spoken language giving the word and its definition in the spoken
> language. That was the concept.
> > It's fairly easy to read in a SGML file into a set of Perl arrays
> >and use Perl's sort() function.
> I was pretty sure Perl could do it, but I am still learning what Perl can
> and cannot do.
> > -Angus B. Grieve-Smith
> > Linguistics Department
> > University of New Mexico