:: urbansheep (urbansheep) wrote,
:: urbansheep
urbansheep

  • Music:

[ utx ] Маркеры как узлы и маркеры как вектора

Последнюю неделю меня занимает очень многословная и (в нехорошем смысле) гуманитарная статья о прототипе машины Юма-Кондильяка. Машина эта представляет собой примитивный анализатор ассоциативных сетей, единственной задачей которого является разбор связей элементов в сети для того, чтобы автоматически выявлять закономерности и решать связанные с этим задачи, в число которых входит и автоматическая „bottom-up“ категоризация/предметизациция, и семантический поиск умолчаний и белых пятен вместе со вскрытием неявных связей. Всё это без анализаторов смысла, без словарей, правил и прочих „top-down“ средств, только за счёт ресурсов в самой сети.

Несмотря на недостатки, текст мне очень нравится, так как блоги и журналы — это и есть уверенно набирающая в объёме сеть объектов, использование которых пока затруднено, ибо средств подходящих для поиска и выбора нужных элементов, почти нет. Пока что у меня есть лишь тахо и LJS. При этом тахо не даёт ничего, кроме простых списков записей по категориям, или более сложных списков, если я вдруг догадываюсь, как построить запрос к БД, а LJS даёт поиск только по словам, что требует нескольких тестовых заходов с испытанием нескольких разных ключевых слов, которые могут быть в интересующих меня записях. Если же никакие слова тебе в голову не приходят, или это не те слова — ты в пролёте, дорогой.

Соответственно, впервые планируя тахо, я хотел создать связанную кросс-журнальную базу записей, которая как раз и смогла бы показать мне кластеры/скопления записей по определённым темам у разных пользователей, чтобы превратить процесс изучения чего бы то ни было (события, темы, предмета) в просмотр объективного набора (объективен он из-за сосуществования разных точек зрения) записей-отзывов. Если же такие раскопки ведутся в режиме самоархеологии, то можно увидеть события, которые с тобой происходили в разных разрезах, и меня больше всего интересовали как раз упущенные мной при маркировании/категоризации события, которые, тем не менее, принадлежат к некому множеству.

Основная идея текста о машине Юма-Кондильяка (дальше — „юмико“) заключается в том, каждое предложение заменяется сетью слов, в нём содержащихся, после чего общая сеть слов формируется из сетей-предложений.

Это хорошо выглядит в английском языке и, наверное, в французском, но на русском без стемминга точно не обойтись.

Дальше начинается, собственно, занимающий меня вопрос.

Сейчас практически все, кто использует систему, делают это по заданному мной примеру — у тебя есть смысловой узел, ты в него ставишь маркер, после чего на твоей карте появляется новая точка в нужной смысловой области. Если у тебя в записи несколько маркеров, соответственно, точка появляется в нескольких смысловых областях, и ты, теоретически, можешь через эту точку, как ниткой, „стянуть“ смысловые области вместе, создавая контекст. Это интереснее, так как мы стремимся передавать и фиксировать именно контексты.

Отличие прототипа тахо от прототипа юмико в том, что мы не оперируем словами. У нас каждая запись-сеть сворачивается в один маркер-тематику, и мы анализируем уже не сеть слов, а сеть записей-предложений. Это, с одной стороны, намного более простой, с другой — отвратительно редукционистский подход к тексту. Потому что как быть, и что делать, если запись промаркирована лишь одним маркером? Ведь если в нашем тексте написано что-то ещё, то без маркера мы никогда об этом не узнаем. Вот тут-то всё и закручивается.

В обычной записи может быть несколько независимых тем и обсуждений. У меня случаются лирические отступления, что-то я лишь упоминаю — тогда „это может быть полезно для статистики, но запись не об этом“, поэтому напрямую брать и анализировать связи маркеров не стоит — много шума появится.

Самое очевидное решение — повысить количество и детализацию маркеров в записях до того уровня, что они будут охватывать текст целиком, не упуская ни грамма смысла. И оно совершенно нереально — на придумывание маркера и так часто уходит масса времени, а если придётся увеличить эту нагрузку, то даже при активной системе анализа синонимии маркеров возни станет на порядок больше.

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

Вариант третий: выделять логические блоки, к которым относится маркер, чтобы несколько маркеров в одной записи могли быть или связаны между собой, или не связаны. По сути, мы возвращаемся к идее скопов (scope), которые реализованы в одной печально радостно известной системе управления контентом. И, соответственно, анализ должен будет работать не на уровне отдельных записей, а на уровне логических блоков.

Сложность пока одна — каким образом организовать URI-схему, чтобы и подобное логическое разделение в неё встроить, и не поломать существующий механизм. Хотя... Да, наверное, можно сделать так: мы указываем при создании маркера произвольное имя логического блока, который и будет атомом данных в системе, а адресация будет идти по схеме /user/id_записи/id_логического_блока.



Subscribe
  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 3 comments