Согласен, есть свои минусы.
Но только ведь речь тут не идет о локальной базе, синхронизированной с другими. В основе сети обычная DHT, построенная на протоколе Kademlia. Я просто адаптировал это протокол для расширенного использования.
Конечно DHT в скорости доступа проиграют централизованной базе. Но плюсы тоже есть. Например тот, что центральная БД не нужна. А значит и соответствующие расходы отсутствуют. Сейчас есть множество p2p сетей, которые, не смотря на свою медленность по сравнению с централизованными решениями, по совокупной мощности превосходят все существующие централизованные сервисы, возможно даже вместе взятые.
С другой стороны — у расширения браузера ведь намного больше информации, чем у поисковика.
Куда человек пошел, что какое время читал эту или другую страницу, как много раз ее открывал, и т.п.
Открытая в браузере страница — готовый удобный объект для анализа, для выделения ключевых слов или чего-то подобного.
А объединенные в p2p браузеры это великая сила для того, чтобы информацию эту переваривать.
Так что мне кажется, если найти правильное применение этой информации то может выйти толк.
Ниже меня спрашивали про необходимость делать закладку. Я ответил, что добавлю возможность публиковать в сети без создания закладки в браузере. Это во-первых.
А во-вторых, браузеры, объединенные в p2p сеть… представьте… а? Тут можно предложить массу разных полезных функций. Например поиск торрентов или даже распределенный трэкер для BitTorrent. Возможности такой сети немалые, я так думаю.
Открытие порта — это не обязательное условие.
Вы можете пользоваться сетью и без открытия порта наружу, ограничений в этом случае никаких нет.
А в дальнейшем, если в Firefox появится поддержка UDP протокола, так и в открытии порта необходимость отпадет, т.к. с UDP довольно просто откупоривать дырки в NAT и соединять узлы между собой напрямую.
Согласен, предусмотреть такую проблему необходимо.
Поэтому уже на этапе проектирования протокола были зарезервированы поля для пользовательских оценок, чтобы пользователи одним кликом могли забраковать страницу и таким образом несколько голосов «против» позволят исключить страницу из списка результатов, а также пометить опубликовавший «плохую» информацию узел сети, чтобы от него данные к публикации не принимались.
Пока добавлять страницу в закладки обязательно.
Но я думаю, Вы правы — сделаю возможность добавлять во Всеиск не сохраняя в закладки.
Что касается дизайна… да, дизайнер из меня… сами видите какой…
Но я сначала хотел посмотреть будет ли вообще интерес к этой задумке, а потом уже заняться дизайном вплотную.
Да, это понятно.
Это я к тому написал, что набрать аудиторию мне кажется задачей посложнее чем бороться с мусорными ссылками.
В общем, была бы проблема, а для ее решения в такой сети найдутся методы.
А что такое «ярлык» в этом расширении? Ключевое слово? Так в том то и дело что поиск не по ключевым словам а по конкретному поисковому запросу, именно тому, что Вы написали в поисковике.
Сервис Xmarks использует другую архитектуру — там все хранится на центральном сервере. Это дает свои плюсы, но и архитектура p2p также имеет свои плюсы, как известно — стабильность, расширяемость и т.п.
Там, кажется, регистрироваться надо, а Всеиск это p2p сеть. Разница примерно как если Вы скачиваете файл с какого-то сайта или в Торрентах — согласитесь, что разница есть. Про какую-то связь с поисковыми запросами я там тоже не нашел.
По описанию по вашей ссылке вроде написано что Xmarks это чтобы «синхронизировать ваши сохраненные закладки и пароли (дополнительно)».
Так в чем сходство?
Не всегда страница, на которую чаще переходят, действительно ответит на Ваш поисковый запрос. Иногда приходится искать дальше, переходя на другие сайты по ссылкам и т.д. Такие ситуации поисковик уже не отследит, но такие ситуации и есть самые затратные по времени поиска. Тут такая сеть сможет помочь.
Бала как-то похожая история с интернет- доступом к чужим деньгам:
«Машинист московского метрополитена… зайдя однажды на интернет-страницу своего счета, он обнаружил там ссудный счет банка, с помощью которого он мог пополнять кредит.»
Там правда конец невеселый.
А вообще такие ошибки в интернет-банке штука непростительная как правило.
Думаю кто-то из разработчиков, а возможно и руководящего уровня товарисчи сильно опечалятся в скором времени…
1) прекрасно, если есть разница между этими 20 словами по существу, то в русском эта разница будет передаваться просто уточняющими прилагательными скорее всего (типа «талый снег») вот и на уровне УК достаточно действовать так же, тут я соглашусь с мнением Oknavrin.
2) А зачем УК знать об этих особенностях русского языка? Эти особенности должен знать транслятор универсального кода в русский язык и обратный транслятор русского в универсальный код. Это как раз то о чем я писал — особенности конкретных языков. А УК будет просто знать что объект переместился в какое-то место. А уже при трансляции с/на русский эти особенности «в/на» будут учитываться. Так что имеем более менее четкое распределение обязанностей.
Да невозможного конечно тут ничего нет. Но тут нужна площадка для сотрудничества, по типу WIKI и большая теоретическая работа. Когда-то у меня было время этим вопросом интересовться, я сделал библиотеку для работы с некоторой универсальной, мною придуманой кодировкой, где символами выступали не буквы а цельные значения, как бы иероглифы. Может как нибудь напишу статью об этом, хотя я на Хабре человек новый, еще не понял — могу ли я что-то писать кроме коментариев :)
Насчет 20 разных слов для обозначения снега, я где-то читал что это миф. Но суть не в этом. Что касается снега — заметьте, тут речь не идет о 20 семантических еденицах, а о различных названиях одного и того же предмета. В русском тоже можно найти много названий-синонимов для некоторых сущностей.
Да и если бы эскимосы и вправду обнаружили 20 разных сущностей, скрытых для нас под словом «снег», например типы снега отличались бы химическим составом примесей, я не вижу в этом совсем никакой проблемы — новые сущности добавляются в классификатор и все.
Вы представляете дело так, что универсальный классификатор создать сложнее русского классификатора. Но почему? Нам нужно где-то раздобыть информацию что «чашка — это посуда», верно? Разве есть принципиальная разница, будет эта информация сохранена на русском в виде, например «чашка < — посуда» или в универсальном виде «78968 < — 1095524»?
Зато в универсальном виде это нужно сдалать один раз для всех языков, и парсер уже сможет пользоваться этой информацией. Конечно останутся особенности конкретных языков, но бОльшая часть работы уже будет содержаться в универсальном классификаторе, а парсеру останется позаботиться только об особенностях именно этого языка, не отвлекаясь на общие факты.
Нет, я не хитрю.
Я просто взял Ваш пример где в некоторой грамматике (для меня в данном случае совершенно не важно в какой) описывается отображение одного русского слова (РАЗБИВАТЬ) в английское слово (break). Я взял Ваш пример и вместо отображения в английское слово, отобразил в универсаьлный код 356748, который (предположим) обозначает «разбивать, разломать на части, ударом превратить целое в набор обломков и т.п.» Под кодом 356748 однозначно понимается некое действие, которое в разных языках будет обозначено разными словами, но если Вы или англичанин увидите как разбивают чашку, то оба поймете о чем речь и в следующий раз можете прямо сказать друг другу «356748 78968» [=разбить чашку] при этом вы поймете друг друга однозначно:)
А оценить количество смыслов в слове «разбить» несложно — в толковом словаре они перечислены.
Так в вашем примере слово «разбивать» это же не семантическая (смысловая) единица. Это слово многозначное, т.е. одно слово обозначает несколько разных семантических единиц. А решать проблему неоднозначных слов придется по любому, какой бы метод Вы не выбрали, потому что когда делается перевод RU->EN, нужно:
1. понять смысл(!) слова на языке RU (т.е. отобразить слово в его смысл)
2. подобрать подходящее по смыслу(!) слово в языке EN (т.е. отобразить смысл в обозначающее его слово )
а в обеих шагах 1 и 2 могут встретиться многозначные слова.
Кстати тут видно насколько проще работать с «универсальным классификатором», ведь при отображении RU->UNI, UNI->RU по крайней мере со стороны UNI имеется однозначность. А в случае RU->EN, EN->RU неоднозначность может возникать с обеих сторон и отображение получается «много значений ко многим значениям», что значительно сложнее.
А сущностей в любом языке одинаковое количество. Иначе как бы люди вообще могли общаться :)
>А хуже всего то, что придётся всё равно создавать отдельную систему для данного языка
Ну почему же хуже всего? Отдельную систему для каждого языка придется создавать по-любому. Только в «универсальном» случае правила создавать проще. Т.е у вас в грамматике вместо
RU->EN: РАЗБИВАТЬ(субъект, объект: посуда) to break
будет написано, например:
RU->UNI: РАЗБИВАТЬ(субъект, объект: посуда) 356748 (и тут уже никакая неоднозначность невозможна)
Нуууу… вот смотрите, докажем теорему «существует принципиальная возможность создания универсального классификатора»: обозначим каждое уникальное семантическое значение (смысл) X некоторым уникальным числом x. Поскольку множество семантических значений ограничено, мы справимся с этим делом в ограниченное время :)
В случае интерсемантики цели такие: «Основа идеи — перейти в технических системах от побуквенного кодирования слов текста к единому международному цифровому кодированию семантического значения, которое несёт каждое слово текста»
Я сам про этот проект узнал только из обсуждения вашей первой статьи. Упоминул потому что похоже на один мой старый проект, так что действительно «идеи… витают в воздухе».
Что касается конкретного применения для решения задачи машинного перевода, то тут, насколько я понимаю, на сегодняшний день преобладет использование в прикладных проектах именно подхода «классификация в рамках языкового поля». Т.е строится семантически обоснованные отображения типа RU->EN, EN->RU, RU->DE и т.д. Для каждой пары языков по 2 отображения.
Если отображать не один язык в другой а в некий универсальный семантический классификатор RU->UNI, UNI->RU, т.е. для каждого языка по 2 отображения.
Т.е. принципиальной разницы на этапе «классификация в рамках языкового поля» нету, при обеих подходах не избежать построения соответствующего отображения. Второй подход конечно сложнее в том стысле что универсальный «классификатор» надо еще создать. Но зато и выгод от более общего подхода прболее будет.
Это я к тому, что напрасно Вы так скептически настроены к универсальному подходу. В каждом подходе свои плюсы и минусы.
Но только ведь речь тут не идет о локальной базе, синхронизированной с другими. В основе сети обычная DHT, построенная на протоколе Kademlia. Я просто адаптировал это протокол для расширенного использования.
Конечно DHT в скорости доступа проиграют централизованной базе. Но плюсы тоже есть. Например тот, что центральная БД не нужна. А значит и соответствующие расходы отсутствуют. Сейчас есть множество p2p сетей, которые, не смотря на свою медленность по сравнению с централизованными решениями, по совокупной мощности превосходят все существующие централизованные сервисы, возможно даже вместе взятые.
С другой стороны — у расширения браузера ведь намного больше информации, чем у поисковика.
Куда человек пошел, что какое время читал эту или другую страницу, как много раз ее открывал, и т.п.
Открытая в браузере страница — готовый удобный объект для анализа, для выделения ключевых слов или чего-то подобного.
А объединенные в p2p браузеры это великая сила для того, чтобы информацию эту переваривать.
Так что мне кажется, если найти правильное применение этой информации то может выйти толк.
Что касается Xmarks, я уже писал выше — есть сходства, есть различия.
Здоровая конкурренция не повредит. Я так думаю.
А во-вторых, браузеры, объединенные в p2p сеть… представьте… а? Тут можно предложить массу разных полезных функций. Например поиск торрентов или даже распределенный трэкер для BitTorrent. Возможности такой сети немалые, я так думаю.
Вы можете пользоваться сетью и без открытия порта наружу, ограничений в этом случае никаких нет.
А в дальнейшем, если в Firefox появится поддержка UDP протокола, так и в открытии порта необходимость отпадет, т.к. с UDP довольно просто откупоривать дырки в NAT и соединять узлы между собой напрямую.
Поэтому уже на этапе проектирования протокола были зарезервированы поля для пользовательских оценок, чтобы пользователи одним кликом могли забраковать страницу и таким образом несколько голосов «против» позволят исключить страницу из списка результатов, а также пометить опубликовавший «плохую» информацию узел сети, чтобы от него данные к публикации не принимались.
Но я думаю, Вы правы — сделаю возможность добавлять во Всеиск не сохраняя в закладки.
Что касается дизайна… да, дизайнер из меня… сами видите какой…
Но я сначала хотел посмотреть будет ли вообще интерес к этой задумке, а потом уже заняться дизайном вплотную.
Это я к тому написал, что набрать аудиторию мне кажется задачей посложнее чем бороться с мусорными ссылками.
В общем, была бы проблема, а для ее решения в такой сети найдутся методы.
Сервис Xmarks использует другую архитектуру — там все хранится на центральном сервере. Это дает свои плюсы, но и архитектура p2p также имеет свои плюсы, как известно — стабильность, расширяемость и т.п.
По описанию по вашей ссылке вроде написано что Xmarks это чтобы «синхронизировать ваши сохраненные закладки и пароли (дополнительно)».
Так в чем сходство?
«Машинист московского метрополитена… зайдя однажды на интернет-страницу своего счета, он обнаружил там ссудный счет банка, с помощью которого он мог пополнять кредит.»
Там правда конец невеселый.
А вообще такие ошибки в интернет-банке штука непростительная как правило.
Думаю кто-то из разработчиков, а возможно и руководящего уровня товарисчи сильно опечалятся в скором времени…
2) А зачем УК знать об этих особенностях русского языка? Эти особенности должен знать транслятор универсального кода в русский язык и обратный транслятор русского в универсальный код. Это как раз то о чем я писал — особенности конкретных языков. А УК будет просто знать что объект переместился в какое-то место. А уже при трансляции с/на русский эти особенности «в/на» будут учитываться. Так что имеем более менее четкое распределение обязанностей.
Да невозможного конечно тут ничего нет. Но тут нужна площадка для сотрудничества, по типу WIKI и большая теоретическая работа. Когда-то у меня было время этим вопросом интересовться, я сделал библиотеку для работы с некоторой универсальной, мною придуманой кодировкой, где символами выступали не буквы а цельные значения, как бы иероглифы. Может как нибудь напишу статью об этом, хотя я на Хабре человек новый, еще не понял — могу ли я что-то писать кроме коментариев :)
Да и если бы эскимосы и вправду обнаружили 20 разных сущностей, скрытых для нас под словом «снег», например типы снега отличались бы химическим составом примесей, я не вижу в этом совсем никакой проблемы — новые сущности добавляются в классификатор и все.
Вы представляете дело так, что универсальный классификатор создать сложнее русского классификатора. Но почему? Нам нужно где-то раздобыть информацию что «чашка — это посуда», верно? Разве есть принципиальная разница, будет эта информация сохранена на русском в виде, например «чашка < — посуда» или в универсальном виде «78968 < — 1095524»?
Зато в универсальном виде это нужно сдалать один раз для всех языков, и парсер уже сможет пользоваться этой информацией. Конечно останутся особенности конкретных языков, но бОльшая часть работы уже будет содержаться в универсальном классификаторе, а парсеру останется позаботиться только об особенностях именно этого языка, не отвлекаясь на общие факты.
Я просто взял Ваш пример где в некоторой грамматике (для меня в данном случае совершенно не важно в какой) описывается отображение одного русского слова (РАЗБИВАТЬ) в английское слово (break). Я взял Ваш пример и вместо отображения в английское слово, отобразил в универсаьлный код 356748, который (предположим) обозначает «разбивать, разломать на части, ударом превратить целое в набор обломков и т.п.» Под кодом 356748 однозначно понимается некое действие, которое в разных языках будет обозначено разными словами, но если Вы или англичанин увидите как разбивают чашку, то оба поймете о чем речь и в следующий раз можете прямо сказать друг другу «356748 78968» [=разбить чашку] при этом вы поймете друг друга однозначно:)
А оценить количество смыслов в слове «разбить» несложно — в толковом словаре они перечислены.
Так в вашем примере слово «разбивать» это же не семантическая (смысловая) единица. Это слово многозначное, т.е. одно слово обозначает несколько разных семантических единиц. А решать проблему неоднозначных слов придется по любому, какой бы метод Вы не выбрали, потому что когда делается перевод RU->EN, нужно:
1. понять смысл(!) слова на языке RU (т.е. отобразить слово в его смысл)
2. подобрать подходящее по смыслу(!) слово в языке EN (т.е. отобразить смысл в обозначающее его слово )
а в обеих шагах 1 и 2 могут встретиться многозначные слова.
Кстати тут видно насколько проще работать с «универсальным классификатором», ведь при отображении RU->UNI, UNI->RU по крайней мере со стороны UNI имеется однозначность. А в случае RU->EN, EN->RU неоднозначность может возникать с обеих сторон и отображение получается «много значений ко многим значениям», что значительно сложнее.
А сущностей в любом языке одинаковое количество. Иначе как бы люди вообще могли общаться :)
>А хуже всего то, что придётся всё равно создавать отдельную систему для данного языка
Ну почему же хуже всего? Отдельную систему для каждого языка придется создавать по-любому. Только в «универсальном» случае правила создавать проще. Т.е у вас в грамматике вместо
RU->EN: РАЗБИВАТЬ(субъект, объект: посуда) to break
будет написано, например:
RU->UNI: РАЗБИВАТЬ(субъект, объект: посуда) 356748 (и тут уже никакая неоднозначность невозможна)
Я сам про этот проект узнал только из обсуждения вашей первой статьи. Упоминул потому что похоже на один мой старый проект, так что действительно «идеи… витают в воздухе».
Что касается конкретного применения для решения задачи машинного перевода, то тут, насколько я понимаю, на сегодняшний день преобладет использование в прикладных проектах именно подхода «классификация в рамках языкового поля». Т.е строится семантически обоснованные отображения типа RU->EN, EN->RU, RU->DE и т.д. Для каждой пары языков по 2 отображения.
Если отображать не один язык в другой а в некий универсальный семантический классификатор RU->UNI, UNI->RU, т.е. для каждого языка по 2 отображения.
Т.е. принципиальной разницы на этапе «классификация в рамках языкового поля» нету, при обеих подходах не избежать построения соответствующего отображения. Второй подход конечно сложнее в том стысле что универсальный «классификатор» надо еще создать. Но зато и выгод от более общего подхода прболее будет.
Это я к тому, что напрасно Вы так скептически настроены к универсальному подходу. В каждом подходе свои плюсы и минусы.