Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет kassian ([info]kassian)
@ 2009-01-30 20:54:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
*** 103

Тут на московском Ностратическом семинаре был доклад про базу данных семантических переходов в языках мира (Анна А. Зализняк, [info]chingachguk@lj и др.).

Зашел спор, можно ли помыслить переход 'щека' <-> 'пятка'.
Так вот, такой пример есть.

Скр. pá:rṣṇi- ‘пятка’ ~ гот. faúrzna ‘пятка’ ~ лат. perna 'задняя часть бедра' ~ хет. parsna- ‘щека; ягодица’ [< и.-е. *persn-]

P.S. Типологический проект Анны, кстати, замечателен. Лично я был впечатлен адекватностью подхода и уже полученными результатами. К сожалению, сегодня практическое применение БД невозможно, т.к. авторы пока не сделали ее общедоступной, т.е. не поместили онлайн.

UPD-1. Если слав. *pьrsь 'грудь' и и.-е. этимоны сюда же, то еще один переход с морфологической деривацией > 'грудь'/'бок, ребро'

UPD-2. Кажется, что между 'щека'-'ягодица' обычное направление перехода 'щека'<'ягодица' (табуизация). Но если слав. *agodica (оба значения) к лит. uodegà 'хвост' (этимология Терентьева с метатезой), то первичное балто-слав. значение как раз 'ягодица'.


(Читать комментарии) - (Добавить комментарий)


[info]aahsaap@lj
2009-01-30 15:38 (ссылка)
Полезнейшее начинание!

(Ответить) (Ветвь дискуссии)


[info]kassian@lj
2009-01-30 15:46 (ссылка)
Преполезнейшее.

Как я понял, основная проблема с организацией онлайн доступа та, что БД сделана в MS Access, а для инета надо ее портировать в другую СУБД, что уже емкая техническая задача.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]fbmk@lj
2009-01-30 18:30 (ссылка)
а в какую другую?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kassian@lj
2009-01-31 01:52 (ссылка)
Не знаю. Кажется, еще даже не решено. Какую-нибудь, которая будет работать через браузер.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]fbmk@lj
2009-01-31 07:58 (ссылка)
Есть конкретный интерес. Потом напишу, почему.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kassian@lj
2009-02-01 14:06 (ссылка)
Ну, тут просто не у меня нужно спрашивать, как понимаешь.

(Ответить) (Уровень выше)


[info]fbmk@lj
2009-02-27 13:45 (ссылка)
на всякий случай уточнение (говорил с Ганенковым) - импортировать в другую СУБД не вопрос, проблема исключительно в том, чтобы в другой СУБД (типа My SQL) организовать последующую работу

т.е. Access удобен для распределенной работы простых лингвистов, для Инета в принципе можно использовать и данные в Access, но это будет тормозить, а My SQL не приспособлен для того, чтобы лингвист с нею работал

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kassian@lj
2009-02-27 13:54 (ссылка)
Если процесс портации автоматичен, то что мешает повесить на сайт MySQL, продолжать работать в акцесе, а раз в несколько месяцев переводить текущую версию в MySQL и апдейтить сайт?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]fbmk@lj
2009-02-27 13:58 (ссылка)
Тоже верно.
Когда я говорил с Димой (это было, на самом деле, уже довольно давно), он еще не сделал скрипт для конвертации базы данных, но утверждал, что с этим не должно быть серьезных проблем.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]fbmk@lj
2009-02-27 14:03 (ссылка)
что конвертировать несложно, мне подтвердили и другие источники
а мне собственно было важно знать только это, чтобы спокойно планировать работу в Access, не заморачиваясь о последующем

(Ответить) (Уровень выше)


(Читать комментарии) -