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

Есть словари в открытых форматах. Есть ли open-source движок, позволяющий их показывать онлайн

Вот этого не скажу. Из свободных онлайн словарей знаю только wiktionary.org, но он не англо-русский и вообще не для переводов.

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

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

<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>

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

Я сам - вовсе не любитель XML, но эта вещь хотя бы всем понятна.

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

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

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

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

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

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

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

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

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

Угу.

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

А для xdxf?

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

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

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

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

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

Написал я под андроид русско-китайский словарь, примерно с 3.5 млн.слов. sqlite справился на ура, но только с fts4, с хитрой выборкой селект отрабатывает за секунду, при учете что он ищет еще по пиньиню, а там по запросу shi может выдать десятки результатов.

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

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

Спасибо. Да ясно, что SQL справится.

Но я понял, что формат xdxf неправильный. Он не даёт первичного ключа. Т.е. невозможно даже нормально организовать «редактирование отдельной статьи». По сути, можно редактировать только словарь целиком.

Мне кажется на данный момент, что нужен формат, в котором статья раскрывает только один смысл слова или словосочетания. Т.е. первичный ключ в таблице словарных статей - это совокупность из написания слова, части речи/предложения и разъяснённого смысла. Такой ключ требует искусства при поддержании базы. Легко наделать дубликатов из-за того, что смыслы можно объяснить разными словами.

Но это - минимум того, что будет правильным решением. А теперь вопрос тебе, ЛОР, на засыпку. Есть ли такие форматы и такие словари?

Как это вообще называется?

Sqlite не справится, особенно на телефоне, а вот с костылем от гугла fts4, справляется.

Голый sqlite по запосу shi или 马 думает 10 секунд, а с fts около 1 секунды, но это при учете что запрос оптимизирован.

Мне кажется на данный момент, что нужен формат, в котором статья раскрывает только один смысл слова или словосочетания.

Есть буржуйский omg/[url=]https://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_R... который дословно повторяет твои размышнеия о проблеме. Но по области он сильно больше словаря

Как это вообще называется?

Онтологии. Как условно-попсовый пример - owl. Стандарты на подобные словари есть, хотя точных сссылок я с ходу не найду.

Спасибо, будем посмотреть.

И вот это https://en.wikipedia.org/wiki/Wordnet https://nlpub.ru/WordNet

Категория:Тезаурус — NLPub

Пока ещё не смотрел эти ссылки. Но вопрос такой. Смысл слова - это некая фраза на языке оригинала. Я понял, что фразу использовать в качестве ключа плохо. Желательно иметь ещё и сокращённую версию смысла. Т.е., допустим,

{ запись: "statement";
  смысл: "an element of programming language definition, e.g. loop statement";
}

{ запись: "statement";
  смысл: "an element of programming language definition, e.g. loop statement";
  код: "programming.language.statement"
}

Соответственно, вопрос: есть ли уже подобная система кодирования смыслов?

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

Нужен суррогатный ключ.

Это называется «контекстом». :-)

есть ли уже подобная система кодирования смыслов?

В каком смысле «система»? Есть ли форматы и программы для них? Ну, в том же GNU Gettext’е, например: msgid и msgctxt.

ответственно, вопрос: есть ли уже подобная система кодирования смыслов?

За базу кодирования смыслов обычно берут RDF. Это примерно уровень символов и списков лиспа. Выше я говорил об owl - он вот так сказать уже пакет макросов. Данные описаные с помощью RDF можно загрузить Virtuoso(gpl2) и довольно шустро манипулировать ими с помощью sparql и гибридно в одной базе сопрягать с реляционными и прочими xml-ями.
Если кто знаком с prolog-ом - то это вот современное развитие его идей. С уже взрослыми БД и прочим.

Тут вобщем-то вопрос в том что ты хочешь от такой системы кодирования получить. Само по себе вышеописаное обслуживает интересы узкого и страшно далекого от народа подвида спецов. Из точки зрения Postgres/JS знание всего это почти пустой груз

SBVR почти не ссылается на rdf но вводит почти такую же модель на основе «фактов». Они политчески в другом клане стандартизаторов :)

https://en.wikipedia.org/wiki/Knowledge_representation_and_reasoning
https://en.wikipedia.org/wiki/Ontology_language

книжный либез о нужности и причинах появления вышеперечисленой зауми для храбрых и любопытных:) А.ЛЕВЕНЧУК «СИСТЕМНОИНЖЕНЕРНОЕ МЫШЛЕНИЕ»
Business Objects: Re-Engineering for Re-Use

Я всего лишь хочу получить способ надёжно редактировать словари коллективно. Рассмотрим operator. В программировании у него два смысла: оператор (присваивания) и операция (сложения). Я хочу, чтобы любой пользователь моего словаря мог бы ввести свой перевод каждого из этих смыслов по отдельности. Я не строю искусственный интеллект :) Формулировка смысла делается на человеческом языке и не предназначена для чтения компьютером.

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

И это не касается знаний Postgres/JS - это всего лишь вопрос, как правильно формализовать предметную область, чтобы проблемы по мере роста базы данных не росли, как снежный ком.

Когда я попытался представить, как работать с форматом xdxf, я сразу заметил отсутствие первичного ключа. Это нежизнеспособно.

Я всего лишь хочу получить способ надёжно редактировать словари коллективно.

А это видел? ruwiki/Семантическая вики. Оно на концепциях того же rdf.

Я не строю искусственный интеллект :)

Я пока и не предлагал

Формулировка смысла делается на человеческом языке и не предназначена для чтения компьютером.

Текст на веб-страничке тоже не для компьютера, однакож http/html/css/uri ... :( Ссылки которые я кидаю, они все про непротиворечивое связывание данных. Уровень html где-то

И вот, я мечтаю, чтобы где-то была глобальная и стандартизованная БД

Ну для примера

• Linked Data
• DBpedia
• Wikidata

вопрос, как правильно формализовать предметную область, чтобы проблемы по мере роста базы данных не росли, как снежный ком.

Business Objects (см. выше) по идее должен отвечать на такие вопросы, включая еще не осознаные:) Но страниц много, да.

Некий г-н Фейнман уже изобретал свои значки для математических операций, ибо решил, что его нотация удобнее, но позже осознал, что ему необходимо взаимодействовать с людьми и нужен общий набор знаков и определений.

Где про это можно прочитать побольше?

В какой-то из Лейтоновских биографий Фейнмана, кажется, в самой первой и знаменитой: «Вы, конечно, шутите...»

кажется

когда кажется, крестятся. А когда нет - дают точные ссылки.

Ути-пути, какие мы беспомощные.

C-s nota
Failing I-search: nota
C-s sym

    <p>While I was doing all this trigonometry, I didn’t like the symbols for sine, cosine, tangent, and so on. To me, “sin f” looked like s times i times n times f! So I invented another symbol, like a square root sign, that was a sigma with a long arm sticking out of it, and I put the f underneath. For the tangent it was a tau with the top of the tau extended, and for the cosine I made a kind of gamma, but it looked a little bit like the square root sign.</p>
    <p>Now the inverse sine was the same sigma, but left-to-right reflected so that it started with the horizontal line with the value underneath, and then the sigma. <emphasis>That</emphasis> was the inverse sine, NOT sink f—that was crazy! They had that in books! To me, sini meant i/sine, the reciprocal. So my symbols were better.</p>
    <p>I didn’t like f(x)—that looked to me like f times x. I also didn’t like dy/dx—you have a tendency to cancel the d’s—so I made a different sign, something like an & sign. For logarithms it was a big L extended to the right, with the thing you take the log of inside, and so on.</p>
    <p>I thought my symbols were just as good, if not better, than the regular symbols—it doesn’t make any difference <emphasis>what</emphasis> symbols you use—but I discovered later that it <emphasis>does</emphasis> make a difference. Once when I was explaining something to another kid in high school, without thinking I started to make these symbols, and he said, “What the hell are those?” I realized then that if I’m going to talk to anybody else, I’ll have to use the standard symbols, so I eventually gave up my own symbols.</p>

Круто! Фейнман уже в школе заметил, как плоха алгебраическая нотация. Я тоже это заметил, но только при разработке Яра. В школе мне не хватило самостоятельности мышления для этого. Действительно, f(x) и sinx порождают опасные неоднозначности в грамматике. В Си это вообще становится не смешным. Глупые разработчики ЯП нагружают скобки ещё и другими смыслами (например, кортежи из них делают или лямбды).

В итоге в Яре для вызова функции используется f(x), а для группировки выражений - f * (: x + 1 :) . Не факт, что удастся это впарить населению, но шанс есть, если уж баш живёт.

Прямо интересной оказалась тема обработки ЕЯ, и в то же время много каких-то, на вид, глупостей. Но вся эта деятельность сворачивается. Т.е. если есть желание у кого-то сделать такой словарь (а затея, по-моему, интересная и может найти массу применений), то я готов поучаствовать в обсуждении ТЗ. Моя заготовка ТЗ - здесь

https://bitbucket.org/budden/ppr/src/380b861c15cca4bde1e39b0bf7a20dde506eb6b3...

Всем большое спасибо за ликбез!