[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: smart words (questions for KBF)
- Subject: Re: smart words (questions for KBF)
- From: scarter@xxxxxxxx (Stephen A. Carter)
- Date: Mon, 03 Nov 1997 16:18:43 +0900
In message <118F301871DFD011807900207810948C051EED@ttgnt1>,
"Frank Kenneth B." wrote:
>The database is freely modifiable. There are probably several ways in
>which could probably be a useful tool in translation, but I'd have to
>understand a little more about how you visualize it working. There are
>numerous ways to have the system select alternative materials. As you
>know far better than I, translation involves more than merely
>substituting words and phrases, so if the objective were to provide a
>predetermined document that, based on the same deal information, was
>produced correctly in both languages, the system would be able to handle
>that reasonably well.
I'm involved in Japanese-to-English technical translation. A lot of
the work that crosses my desk is patent documentation, either for
information purposes or for filing in the US. The for-filing docs are
often based on applications submitted to the Japan Patent Office, and
therefore need a certain amount of rearrangement to bring them in line
with the different format required by the USPTO.
I'm no patent attorney, and I don't pretend to be one, but my clients
who are patent attorneys expect me to do a certain amount of this
rearrangement as part of the translation process. Also, as a service
to my clients, I make an effort to flag what appear to be errors in
the original Japanese documentation (typos, inconsistent terminology,
icorrect references to drawings, etc.). Of course, I present all
these rearrangements and corrections merely as translator's
suggestions to my clients, who are the actual patent attorneys and
have the ultimate authority, control, and responsibility regarding
content.
You're quite right that translation is much more than a word-for-word
substitution of vocabulary between two languages, but consistency in
terminology is very important in technical translations, especially
for patents. It wouldn't do, for example, to call the same component
an "LCD screen" in one place and an "LCD panel" in another.
>I am sure the system could prepare patent docs for filing. My only
>reservation about using if for patents as opposed to other types of
>legal docs, is that my uneducated perception is that the overwhelming
>bulk of the content of patent documentation is unique to the particular
>patent, and wouldn't particularly benefit from a rule-based assembly
>from a text fragments, You could certainly use the product to store
>information about the patent applications, organize the documents for
>each filing, and automatically assemble those portions of the documents
>that are susceptible to that sort of activity. Patent filings is an
>area we have always been interested in, but really don't know enough
>about to pursue. If you can shed any further light on it I would be
>interested.
You're correct that in many cases a lot of the text in a patent
specification is unique to the particular patent, but there is a
certain amount of formulaic "boilerplate," as well as a fairly rigid
structure for the document itself (especially in the claims). There
is also the issue of maintaining internal consistency throughout a
single application, which can sometimes extend to several hundred
manuscript pages. Often there's also need to maintain consistency in
terminology, etc. for a family of related patents (such as, say, a
family of airbag triggers all developed by the same manufacturer).
My wish-list for the database and selection system would look
something like this:
1) A semi-automatic template-generating function that can map Japanese
or international (PCT) patent-application format (document
structure) to the format expected by the examiners in the USPTO
2) Ability to maintain consistency in terminology within a single
application
3) Ability to maintain consistency in terminology across a set of
related applications
4) Ability to identify and flag passages that are *almost* identical
5) Databases that can be updated on the fly (like Xy's SPL files)
6) Databases that can be swapped in and out on the fly according to
the client, technical field of the device, etc. (again, like Xy's
SPL files)
>As to double byte, we have done some experimentation. We did have a
>functioning Chinese language editor which Nathan tested a while back,
>but I do not think it used unicode. Right now we are focused on making
>some money in the English speaking world, but if the product is
>successful it would be only natural to extend it. An intelligent
>product like this that supports multiple languages would certainly have
>interesting potential.
I agree!
--
Stephen A. Carter High-Tech Information Center Nagoya, Ltd.
mailto:scarter@xxxxxxxx Nagoya, Japan
* Team OS/2 *