LINUX.ORG.RU

структура БД англо-русского словаря

 ,


2

3

Где бы стырить? Или, может быть, есть какой-то движок для составления специализированных англо-русских словарей, который можно уже взять в готовом виде и сделать к нему веб-интерфейс? Или даже может быть уже готовый движок с веб-интерфейсом? Интерфейс должен позволять не только читать словарь, но и пополнять его.

И желательно, чтобы пополнять его было не крайне сложной задачей, а постижимой простым ламером.

★★★★★

Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

вопрос не про яровизацию, а вообще про создание русскоязычных аналогов всяким там fixme, src и т.п.

Я про это и говорю, да... С «яровизацией» я попал в слово, которое вы уже забили за другим? Ну пардон.

Протокол интересный

Я не столько про протокол, сколько про *формат*. Ну вы же про него фактически спрашивали.

Писать в структурированном тексте, версионировать — в системе контроля версий, не? Неужели правда хочется навелосипедировать что-нибудь ни с чем не совместимое?

Zmicier ★★★★★
()
Ответ на: комментарий от Zmicier

Приставку «яро» я применяю, когда речь идёт о каких-то моих предложениях. Так что тут приставка вроде не в тему получается. Я неправильно выразился - речь даже не про создание, а про сбор вариантов. Microsoft, Oracle, IBM, 1C, Оберон - вот, как минимум, 5 источников терминологии, которые наверняка имеют расхождения. По идее, государство должно утвердить стандарты и всех (в т.ч. и международные корпорации) обязать ими пользоваться, если они работают в России. Я на эту роль не претендую. Там, где вариантов нет, есть мой стиль, к-рый я применяю в Яре - это плюс ещё один вариант. Ну и каждый желающий может создать свой. Если у государства дойдут до этого руки, у них будет готовая база данных, из которой останется только выбирать. Мне показалось, dict - это протокол обмена инфой, а не формат. Ща ещё раз посмотрю.

den73 ★★★★★
() автор топика
Ответ на: комментарий от Zmicier

Писать в структурированном тексте, версионировать — в системе контроля версий, не?

Не, это изврат. Нужен доступ разным пользователям на запись и суммирование их результатов. СУБД это запросто делает, а при использовании системы контроля версий придётся гору из костылей строить.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Писать в структурированном тексте, версионировать — в системе контроля версий, не?

Не, это изврат.

Ну да, как же я не подумал... Засунуть текст в прокрустово ложе формочек — это норм, а держать текст в тексте — это изврат.

Нужен доступ разным пользователям на запись

Ну дык!

и суммирование их результатов

Это называется «слияние».

СУБД это запросто делает

Ага, после того, как оператор идеально грамотно разложит все по полочкам.

Zmicier ★★★★★
()
Ответ на: комментарий от Zmicier

Основная операция в словаре - это поиск по нему и просмотр данных. Данные нужны как минимум в двух вариантах:

  • конкретное слово в конкретном словаре
  • конкретное слово во всех словарях

Как сделать поиск на гитхабе без «формочек»?

Далее, нужны гиперссылки на другие слова (например, на словосочетания с этим словом, на синонимы, ссылка на источник перевода и т.п.).

Я планировал изначально сделать редактор в формате md. Теперь думаю, что лучше xdxf, т.к. это всё же специализированный формат. Придётся написать шпаргалку и прикрутить подсветку синтаксиса XML. Ну тут как бы ежу ясно, что редактировать одну статью в формочке - удобнее, чем, допустим, мегабайтный XML файл словаря целиком.

Это программисты искушены в нахождении грамматических ошибок в тексте по скудным отчётам парсеров, а обычные люди - нет.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Основная операция в словаре - это поиск по нему и просмотр данных.

Да, и никакого отношения к операциям редактирования они не имеют.

Я потому и напомнил про существование стандартного dict’а.

Браузерные интерфейсы для него, разумеется, есть.

Как сделать поиск на гитхабе

Не знаю, и знать не желаю. Спросите у тех, кто этой проприетарщиной активно пользуется.

Далее, нужны гиперссылки на другие слова (например, на словосочетания с этим словом, на синонимы, ссылка на источник перевода и т.п.).

Бинго! Вы это тоже все собираетесь по полям базы данных раскладывать? А главное — всех остальных обучать делать это без ошибок. Ну удачи, чо.

Я планировал изначально сделать редактор в формате md. Теперь думаю, что лучше xdxf, т.к. это всё же специализированный формат.

Возможно. Я его не видел.

Ну тут как бы ежу ясно, что редактировать одну статью в формочке - удобнее, чем, допустим, мегабайтный XML файл словаря целиком.

Могу только повториться:

«Я правильно понял, что этой вашей яровизацией лиспа (это же лисп был, да?) будут заниматься особо отобранные «ламеры», для которых структурированный и версионированный текст — это не то, что не самый дружественный вариант, а просто уже за пределами понимания? Так что нужен обязательно велосипед на веб-формочках?

Кажется, путь ваш свернул не туда».

И да, это вы сами сейчас поставили условие на «мегабайтный файл». Не исключено, что целесообразнее иметь и более дробные файлы, мне это сейчас неведомо.

Это программисты искушены в нахождении грамматических ошибок в тексте по скудным отчётам парсеров, а обычные люди - нет.

О, господи! Поэтому я вам и говорю, что брать надо *простой текст*, а не XML. В нем почти не может быть грамматических ошибок.

Zmicier ★★★★★
()
Последнее исправление: Zmicier (всего исправлений: 1)
Ответ на: комментарий от Zmicier

Да, и никакого отношения к операциям редактирования они не имеют.

Ага. Итак, полные требования: операции поиска должны быть удобны без всяких компромиссов. Т.е. окно поиска «как в яндексе», возможно, с автодополнением. И список находок. Набор словарей, как в StarDict, с возможность включить/выключить конкретный словарь. Вот минимальный интерфейс для поиска.

Но и операции редактирования нужны. Я пока вижу это так: кнопка «редактировать», открывается XML с подсказкой, далее preview, далее «сохранить». Кнопка «сохранять» может работать как угодно, хоть пересобирать весь словарь, но сохранение должно занимать несколько секунд, не более того.

И естественно, надо не писать с нуля, я не велозавод. Надо взять крупные блоки и их них собрать.

Нашёл программу CrossDef, но SourceForge сегодня барахлит - не могу скачать. Выглядит похожим на то, что надо, хотя примеры непонятны.

Браузерные интерфейсы для него, разумеется, есть

А для xdxf? Очень уж заброшен этот dict, плюс старый формат, оптимизированный под скорость, а не под простоту.

Не знаю, и знать не желаю. Спросите у тех, кто этой проприетарщиной активно пользуется.

Хорошо, не на гитхабе, а где ты предлагаешь.

Бинго! Вы это тоже все собираетесь по полям базы данных раскладывать?

Например, можно сделать такую структуру

create table словарь (словаря_код, название, автор)
create table доступ_на_запись (логин, словаря_код)
create table входное_слово (слова_код,слово)
create table статья (слова_код,словаря_код,XML)
Тогда не нужно будет раскладывать ВСЮ структуру по полям. И даже если структура будет более сложной, можно от пользователя принимать XML, а дальше его парсить и превращать в реляционную стр-ру. Это уже отдельный вопрос.

На данный момент главное - это сделать структуру, к-рая позволяет учесть все нюансы предметной области. Будет ли она разобрана до косточек в реляционную структуру или это будут куски XML - дело десятое.

den73 ★★★★★
() автор топика
Ответ на: комментарий от Zmicier

О, господи! Поэтому я вам и говорю, что брать надо *простой текст*, а не XML. В нем почти не может быть грамматических ошибок

У словарной статьи есть структура. Её нужно как-то выразить. Я вижу, по сути, два варианта - либо XML и далее парсер, к-рый сразу показывает косяки, либо жуткий WYSWYG редактор с массой кнопочек. Который я не осилю и который вообще не нужен ввиду неэффективности работы в нём.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73
<abbreviations>
    <abbr_def type="grm"><abbr_k>n.</abbr_k><abbr_v>noun</abbr_v></abbr_def>
    <abbr_def type="knl"><abbr_k>polit.</abbr_k><abbr_v>politics</abbr_v></abbr_def>
    <abbr_def><abbr_k>Av.</abbr_k><abbr_k>Ave.</abbr_k><abbr_v>Avenue</abbr_v></abbr_def>
</abbreviations>

Чтоб вы понимали специфику предметной области. Например, сокращения. Это определённое понятие. Писать его просто в виде текста - вроде поначалу легко пишется, но потом нельзя запросить список всех сокращений. Если формат не будет чётким, продуманным и контролируемым, в результате может получиться только помойка.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

В общем, придётся подождать, пока sourceforge поднимется. Если crossdef не устроит, придётся делать велосипед.

Проглядел стандарт xdxf. Видимо, нужно сделать разбор подмножества этого стандарта, разбирать хотя бы ключи, ссылки на другие слова, область применения, ссылки на внешние ресурсы.

Ну и естественно, нужно все теги русифицировать и перевести само определение формата.

Рендерить всё это в обычный плоский текст с гиперссылками.

Отдельную статью хранить в отдельной записи и отдавать в API по отдельному URI.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Отдельную статью хранить в отдельной записи

Я бы сделал отношение многие ко многим. Тогда можно было бы сделать двунаправленный словарь + список синонимов на исходном языке (как это делается в яндекс.словарях).

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

В xdxf предусмотрено наличие нескольких ключей в статье, так что да, получается много ко многим. Хотя пока на мой взгляд на фоне задачи валидации XML и разумного отображения ошибок это мелочь.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Имхо, структура БД — это не мелочь, а самое главное, т. к. от неё зависит логика и сервера, и клиента. Если не продумать, то потом придётся переделывать всё.

aureliano15 ★★
()
Ответ на: комментарий от den73

Браузерные интерфейсы для него, разумеется, есть

А для xdxf?

А он создан как формат обмена. И он же комплектуется утилитой для конвертации в формат того же dict-а и прочих.

Для изначального dictd есть db-плагин Но по умолчанию сервер собирается без него. И последние лет 10 это видимо никого не колышет:( Как переосмысление проблемы написали javadict поверх postgres. И возможно тоже забили.

antares0 ★★★★
()
Ответ на: комментарий от den73

или это будут куски XML - дело десятое.

И в принципе xmlbd и всякие документные придуманы для более-менее оптимального хранения такой информации. Реалициоки для более табличных данных по идее?

antares0 ★★★★
()
Ответ на: комментарий от antares0

Может быть, но я знаю SQL, а по постгресу есть вакансии. Поэтому буду затаскивать сюда постргрес, даже если он неоптимален. Думаю, всё будет ок, если я осилю добить вуй.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Может быть, но я знаю SQL, а по постгресу есть вакансии. Поэтому буду затаскивать сюда постргрес,

Постгрес умеет xml, хотя аналогичный json он ИМХО умеет оптимальнее. Для MySQL/MariaDB это тоже заявлено.

antares0 ★★★★
()
Последнее исправление: antares0 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.