The Voynich Ninja

Full Version: Transliteration and interpretation of the Voynich MS text
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
To render the Voynich MS text into a computer-readable form is called 'transliteration'.

Historically, this has been called 'transcription' but the two processes are not the same.

Take the letter from Marci to Kircher (1665). We have access to a graphical image of this letter, which is written in a known language (Latin) and a known alphabet. It can be (and has been) transcribed.

Other hand written manuscripts are more difficult to read, use abbreviations and omit characters. They can still be transcribed, but there is a set of conventions for resolving the abbreviations and omissions.

With the Voynich MS it is very different. We cannot read it and it is not Latin. The best one can do is to try to identify the individual forms, and render them in electronic form as consistently as possible. This process, which is also applied to texts in known non-Latin alphabets, is called transliteration.

This has been done many times for the Voynich MS, and different people/groups have come up with different results.
The 'easy' interpretation is that these people defined tables from the Voynich glyphs to alphanumeric characters, but the more complete and correct interpretation is that the decision rules have been different in all cases.

In the 'easy' interpretation they can be easily translated between each other back and forth, but in the more accurate interpretation this is not possible without loss of information.

This can be exemplified with the case of the character d.

It looks like an eight, so FSG transliterated it as 8, so did Currier, in Eva it is 'd' and in v101 it is again 8.
However, v101 (and also Eva) recognise several different forms. The main forms are transliterated as 6, 7, or 8.
In Eva there is the high-Ascii code &152; but this is hardly used in the LZ or ZL files.

The problem is not whether one uses 8 or 'd', but where one draws the limit.

I highlighted this last sentence, because I get the impression that even experienced Voynich MS researchers do not fully grasp this idea.

It is immaterial whether one transliterates e as 'e' or 'c'.
It is immaterial whether one transliterates Sh as 'sh' or 'Sh'.

Coming back to the title of this post, it is very tempting to map 'expectations' of the meaning of some glyphs to the way they are transliterated.
Even if we think that e  looks like a 'c', it does not mean that this is what it is supposed to represent. In fact, that is extremely unlikely, but that is subjective and can be ignored for now. What should be clear to Voynich researchers is that just mapping Voynich symbols to plain text characters in some language will not work.
(12-08-2020, 01:36 PM)ReneZ Wrote: You are not allowed to view links. Register or Login to view.
...
It is immaterial whether one transliterates e as 'e' or 'c'.


I agree, in terms of transliteration. It makes no difference. The computer doesn't care. However, in terms of a researcher's psychological perception of the text, it makes a difference.

Quote:Coming back to the title of this post, it is very tempting to map 'expectations' of the meaning of some glyphs to the way they are transliterated.


This is why I don't like mapping EVA-e to the "e" character when it is shaped like "c". It creates a psychological 'expectation' that EVA-e is a vowel. Some computational attacks have specifically treated it that way. Copying the shape is more 'expectation' neutral.



Quote:It is immaterial whether one transliterates Sh as 'sh' or 'Sh'.


If EVA-S S is used to transliterate a portion of one VMS glyph and EVA-s s is used to transliterate a completely different VMS glyph with different statistical properties, then it matters if they are treated the same because they are not the same. In the Basic EVA set, they are recognized as being different. In the Takahashi transliteration that uses capitalization consistent with the Basic EVA set, they are recognized as being different.

If they are remapped, they need to be remapped to two different slots, not collapsed into one (which is what happens if people are given the impression that they are the same).
Quote:Even if we think that e  looks like a 'c', it does not mean that this is what it is supposed to represent.


To me, this is obvious.

I have never said or implied that the c-shape is the letter c. In fact, I frequently refer to it as the c-shape specifically to avoid the implication that it is a letter. The c char is, however, closer to the shape of the VMS c-shaped glyph than the letter "e" and has fewer psychological 'expectations' of it being a vowel (it might be, but we don't know). That's why I prefer shapes that mimic VMS shapes as closely as possible over shapes that don't. Obviously we can't do this for all of the glyphs.

This is a personal preference. I have never imposed it on anyone else.
(12-08-2020, 01:36 PM)ReneZ Wrote: You are not allowed to view links. Register or Login to view.It is immaterial whether one transliterates Sh as 'sh' or 'Sh'.
That's an interesting question, and the real issue here is surprisingly EVA-h.

Using EVA-s both as standalone and as part of sh ligature is not extremely convenient, but normal parser can live with that: s before h - ligature, otherwise - standalone.

The question is how h is defined. If it is "ending symbol of a ligature" then the system works perfectly. Assuming that sh is "synonym" for Sh (just as we usually write ckh instead of more strict cKh) we get the required one-to-one correspondence between forms and notations. However defining h simply as "e with dash" or something like that we implicitly allow it to be standalone. And facing combination <EVA-s, then "e with dash"> we immediately get ambiguous notation.
(12-08-2020, 02:51 PM)farmerjohn Wrote: You are not allowed to view links. Register or Login to view.
(12-08-2020, 01:36 PM)ReneZ Wrote: You are not allowed to view links. Register or Login to view.
It is immaterial whether one transliterates Sh as 'sh' or 'Sh'.

That's an interesting question, and the real issue here is surprisingly EVA-h.

Using EVA-s both as standalone and as part of sh ligature is not extremely convenient, but normal parser can live with that: s before h - ligature, otherwise - standalone.

...


Yes, agreed. A parser can live with it, but I've noticed that numerous researchers are using apps (e.g., math visualization) or code from other sources, both of which would require preprocessing in order for the data to work within these external environments, and how they handle the text is not always transparent (or configurable) once it is fed into the engine. So... the closer the transliteration represents the text without having to do this kind of parsing, the kinder it is to those who are not coding everything from scratch.
(12-08-2020, 02:51 PM)farmerjohn Wrote: You are not allowed to view links. Register or Login to view.Using EVA-s both as standalone and as part of sh ligature is not extremely convenient, but normal parser can live with that: s before h - ligature, otherwise - standalone.

Yes, but there are a few instances of standalone EVA-S. Information is lost when converting to lowercase EVA, in these rare cases.
76r: qoteS
106v: toloS
(12-08-2020, 03:17 PM)nablator Wrote: You are not allowed to view links. Register or Login to view.Yes, but there are a few instances of standalone EVA-S. Information is lost when converting to lowercase EVA, in these rare cases.

Yes, that's why we cannot treat S as s, but still can treat Sh as sh if needed. Big Grin


(12-08-2020, 03:05 PM)-JKP- Wrote: You are not allowed to view links. Register or Login to view.So... the closer the transliteration represents the text without having to do this kind of parsing, the kinder it is to those who are not coding everything from scratch.

Even if your transliteration is 100% precise you have to make some choices (at least about aiin, ch, sh, ckh...) before feeding this transliteration to app/algorithm (do nothing is also a choice). So producing statistical analysis of any form and keeping it theory-neutral at the same time is impossible.
(12-08-2020, 03:58 PM)farmerjohn Wrote: You are not allowed to view links. Register or Login to view.
...
Even if your transliteration is 100% precise you have to make some choices (at least about aiin, ch, sh, ckh...) before feeding this transliteration to app/algorithm (do nothing is also a choice). So producing statistical analysis of any form and keeping it theory-neutral at the same time is impossible.


Yes, I completely agree with this and I don't think we are anywhere near agreement or have enough insight into what Voynichese is to make informed decisions about many of the glyphs or glyph-combinations (the benched gallows being a particular sticking point).

But we can separate out single glyphs from portions of those that have different statistical properties so that linguists and others who might not specifically be programmers (who might not know how to pre-process/parse/distinguish S from sh) can have a minimally unambiguous transliteration to feed into various apps that allow data analysis and visualization.
(12-08-2020, 03:17 PM)nablator Wrote: You are not allowed to view links. Register or Login to view.
(12-08-2020, 02:51 PM)farmerjohn Wrote: You are not allowed to view links. Register or Login to view.Using EVA-s both as standalone and as part of sh ligature is not extremely convenient, but normal parser can live with that: s before h - ligature, otherwise - standalone.

Yes, but there are a few instances of standalone EVA-S. Information is lost when converting to lowercase EVA, in these rare cases.
76r: qoteS
106v: toloS

Indeed, they are not common, but for the record, here is another one:
You are not allowed to view links. Register or Login to view. 04:05: Sody Sody
I have a more global question. Analyze the 3 from 4 suggested words. Why are “s” differently spelled in words? You are not allowed to view links. Register or Login to view. and  You are not allowed to view links. Register or Login to view.
Pages: 1 2 3