[Recent Entries][Archive][Friends][User Info]
| March 2nd, 2006 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 08:05 pm [Link] |     Вот тут вот, ![[info]](http://lj.rossia.org/img/userinfo-lj.gif) apophates@lj поставил небезынтересную проблему. Френдов, полагающих себя компетентными, приглашаю присоединиться, а то я, признаться, изрядно плаваю в вопросе.
| |||||||||
| Comments | ||||||||||
Боюсь, что я с ходу вряд-ли что-нибудь умное Вам отвечу. Посоветую разве что сформулировать свои представления в виде списка претензий к существующим интернет-протоколам. Ну вот получается, что Вы сами жи и сформулировали претензии к тому самому протоколу, который подсказали как решение проблемы. На самом деле мои претензии - это претензии Semantic Web к тому, что было до нее. Хотелось бы получить ее возможности в массовом решении, не дожидаясь, пока корпорации навяжут всем что-то свое в удобном им виде - примерно как осел с битторрентом заняли ту нишу, на которую только облизывается Мелкософт. В случае Semantic Web - надо сделать, чтобы массы стали не только потребителями интерпретации (=структур контента, или метаинфорормации о нем), но ее производителями. Каждый узел проектируемой сети станет самодостаточным источником интерпретации, не только не зависящим от дяди - составителей словарей и т. п., но и способным к усилению своего влияния в своей социальной сети через свободную самоорганизацию ее узлов. Существующие интернет-протоколы неудовлетворительны именно в силу своей асимметрии. Серверов мало, их можно передавить поодиночке или захватить над ними контроль. Зато битторрент мне представляется близким к идеалу как своим протоколом (с учетом распределенного трекинга), так и юзабельными реализациями. (Reply to this) (Parent) Иными словами, создание и тиражирование интерпретаций должно стать массовым занятием, и не требовать ни высокой технической квалификации, ни дополнительных к существующей инфраструктуре финансовых затрат. Я хочу получать структурированные указатели на контент из тех источников, которые выбираю сам, и сам служить источником для тех, кто сочтет меня заслуживающим внимания-доверия. Работа по информационному обмену должна стать содержательной, а технические вопросы можно и нужно отдать автоматике. Массовая инфраструктура - достаточные вычислительные ресурсы, storage, каналы подключения - налицо. Добавьте к этому средство абстрагирования от массовой виндовзной платформы (если для ПО узла потребуется юникс или что угодно): вмваре и т.п. Даешь knowledge working на себя и свою социальную сеть, а не на корпорации и госструктуры! (Reply to this) (Parent) Вот еще один сценарий. У тысячи человек есть приблизительно один и тот же набор книг в электронном виде - мало того, у каждой книги есть уникальный идентификатор (ISBN), который в 90% случаев может быть вытащен автоматически, и в 98% - почти автоматически. Химически чистая проблема обмена каталогами. Пускай несколько сотен человек с удовольствием готово поделиться с остальными своими файлами - но не готово тратить время на выяснение, что именно кому нужно, и на пересылку. Логично, чтобы тот, кто ищет что-то, сам и искал в чужих каталогах. Корпоративный стиль решения этой проблемы налицо - это "Digital Marketplace". Вот свободный обменник в том же клиент-серверном стиле: http://www.flazx.com/ Ограничения очевидны. P2P сети помогают искать файлы в опубликованных списках, принудительно плоских. К p2p транспорту следует добавить возможность обмена произвольными каталогами и юзабельную морду, приспособленную именно для этого. (Reply to this) (Thread) Вот "договориться о регулярном именовании" - условие запретительное. "За что?" Во-первых, против любого консенсуса вскоре начнутся священные войны. Во-вторых, даже при желании следовать каким-то правилам мало у кого есть такая возможность. Какие бы то ни было предварительные условия сделают решение немассовым. "Версема" книги - это набор (ISBN, формат, CRC или размер в байтах). Книги - это пример вырожденный, именно потому, что ISBN реально вытаскивается из таких форматов, как PDF и CHM. Под .NET, например, есть такая утилита (под вопросом остается Djvu). (Reply to this) (Parent) Сервисы гугля можно использовать с умом и очень осторожно в качестве готового индексирующего движка на этапе обкатки проектируемого решения. Но как только решение станет действительно массовым, полагаться на гугль станет нельзя. Тем более если оно будет использоваться для наглого попрания "копирайта". DirectConnect - это такая пиринговая сеть. Очень простая. А google - в том смысле, что мне лень искать точную ссылку. А-а, то-то я вчера обломался с гуглем. Знаю, хорошая штука. Уязвимое ее место - опять-таки клиент-серверность. Хабов сравнительно мало, и их можно передавить. Кроме того, сразу возникает конкуренция между этими немногочисленными серверами, своя аура, правила и т. д. и поглощает ту энергию, которую следовало бы потратить на кооперацию пиров. А вот talkback не знаю. Пойду читать. Прошу прощение, я хотел сказать Trackback http://en.wikipedia.org/wiki/Trackback На этом механизме в technorati.com выстроен механизм, как раз, оценки сравнительного "веса" блогов. А вообще это технологическая реализация известного в академическом сообществе понятия "индекса цитирования". 1) Trackback ping - подразумевает, что оба блога находятся в онлайне? Плохо. Я бы предпочел async messaging. 2) Ping spam уже и там. Необходимость идентификации узлов и подписки только на доверенные источники пингов. ... (Reply to this) (Parent) На этом механизме в technorati.com выстроен механизм, как раз, оценки сравнительного "веса" блогов. Вот такой бы сервак к каждому на десктоп. С динамически конфигурируемыми алгоритмами рейтинга, со средствами фильтрации онлайн-контента и подписки на контент второочередной важности (опять-таки, приоритизируемой в зависимости от предпочтений пиров). А вообще это технологическая реализация известного в академическом сообществе понятия "индекса цитирования". Только я хочу сам формировать свое "академическое сообщество", исходя из собственных соображений. И хочу, чтобы такая возможность была у всех. (Reply to this) (Parent) Теперь насчет DC сети. Второй ее недостаток - файл-ориентированность. Настоящий интерес представляет метаинформация в наиболее общем виде, а не только имена файлов и пути к ним. Понятно почему разработчики DC пошли на этот компромисс, но сейчас пора копать дальше. Третий недостаток DC - это невозможность содержательной оценки клиентов. Хабы устанавливают свои правила членства по формальным критериям: количеству расшаренных на клиенте гигабайт, принадлежности к подсети и т. п. Следствия третьего и первого (т.е. клиент-серверности) - невозможность именно взаимной оценки пиров. Оценка (точнее черно-белый "допуск в клуб") передоверяется клиентом хабу. То есть если исходить из DC как отправной точки, ПО узла проектируемой сети это не меньше чем (хаб + клиент + вебморда) внутри виртуалки. Виртуалки, настроенной так, чтобы контент и конфиги лежали снаружи (т.е. в хост-системе или во внешней субд). (Reply to this) (Parent) Хочу подобное вот этому http://www.beelaxy.com/about - только чтобы не у доброго Большого Брата на считаных серверах, а на рабочих местах у чайников. Чтоб восстановление после сбоя занимало 15-20 минут. То есть чтоб было ВЕЗДЕ. (Reply to this) (Thread) Брожу там по ссылкам оставленным sergeydmitriev@lj, набрел вот на что, http://www.hanselman.com/blog/PermaТ.е. проблема занимает многих, и будет очень хреново, если ее решат корпорации в своих интересах - "acquiring licence to print money", как выразились по ссылке. (Reply to this) (Parent) Если я правильно понимаю что это такое, это и будут блоги в классическом их понимании. Также google talkback Ну, http://www.beelaxy.com/about - это пример частичный. Там многого нет из того, что хотелось бы, зато он хорошо иллюстрирует value взаимной оценки и "взвешеннной синдикации" каталогов. К тому же, классические блоги сервер-басед, их можно "передушить поодиночке". Вот такой бы сервис как beelaxy - к каждому клиенту на декстоп. И скрыть сложность - в этом главная головная боль, это необходимо для того, чтобы решение вышло массовым. Пример удачно (хотя все же и недостаточно для настоящей задачи) скрытой сложности - Azureus. (Reply to this) (Parent) вот такие штуки нынче в моде, стремительно входят http://www.vmware.com/vmtn/appliances/c Читаю книжку строго по теме. Очень рекомендую: http://www.flazx.com/ebook4480.php Повторяю свой point: необходимо сделать на этом поприще что-то столь же удачное как осел и битторрент, но еще более массовое. Наихудший и наиболее вероятный сейчас результат развития этих технологий - централизованно определяемая (госструктурами и )корпорациями семантика сетевых ресурсов. Если мы хотим выжить в этой ситуации - необходимо не просто создать распределенный "сервис Вербицкого", но довести технологию до масс: любой пользователь (нынешний клиент p2p сетей и еще более низкой квалификации) должен с помощью искомого инструмента получить статус семантической authority для тех, кто его избирает в этом качестве. (Reply to this) (Thread) With the enormous growth of the Web and its content since its inception, it is clear that new implementations must build on existing content to gain widespread usage, or at least allow a relatively simple and transparent retrofit. This development can be more or less easy, depending on the intentions and at what level the change comes. So far, we have seen such changes mainly at the application level. Long sought is a change at a more profound level, such as a major extension to the underlying Web protocol, HTTP. Such a change could harmonize many functionality extensions back into a common and uniform framework on which future applications can build. Current HTTP does in fact combine the basic transport protocol with formats for limited varieties of metadata – information about the payload of information. However, because it is descended from the world of e-mail transport (and an old protocol), HTTP metadata support as currently implemented remains a crude architectural feature that should be replaced with something better. The Web needs a clearer distinction between basic HTTP functionality and the richer world of metadata functionality A more formalized extension of HTTP, more rigorous in its definitions, can provide such a needed distinction and thus bring the Semantic Web closer to reality. ... (Reply to this) (Parent) Instead of tackling the perhaps insurmountable artificial-intelligence problem of training machines to behave like people (‘greater AI’), the Semantic Web approach is to develop languages and protocols for expressing information in a form that can be processed by machines. Another content issue is the proliferation of different content formats on the Web, which usually require explicit negotiation by the user. This barrier not only complicates and hides the essential nature of the information on the Web, but also makes the content more difficult to handle by software agents. (Reply to this) (Parent) At this point, we are not concerned about the ‘how’ of implementation, only the user experience for some fairly simple and straightforward enhancements. Some of these features are hard to describe adequately in the absence of the ‘back-end’ data and automation, and they will depend greatly on commercial, political, and social decisions along the way as to what is desired or allowed. Context awareness, which would allow ‘intelligent’ client behavior. Ideally perhaps, semantic parsing of document context could reduce the need for user decision and simply present ‘most-probable’ options as distinctive link elements at the rendered location. Alternatively, the client might provide an on-the-fly generated sidebar of ‘related links’, including information about the site owner. Several proprietary variations of the theme are found in adware-related generation of ‘spurious’ hyperlinks in displayed content, which however is more intrusive and annoying implementation in the absence of other cues. A simple example of context feature for content is found in newer browser clients, where the user can highlight text and right-click to access Web search or other useful actions, as illustrated in Figure 1.2. Persistent and shareable annotations, where users can record private or public comments about Web content automatically attached to given document (URI) and ideally internal location, in context. Public comments would then be shareable among an entire community of users perhaps most usefully in goal-oriented groups. Persistent and shareable ratings, which is complement to annotations, providing some compiled rating based on individual user votes. mouse-over of link might then pop up tooltip box showing, for example, that 67% of the voting users found the target document worthwhile. Of course, not everyone finds such ratings useful, yet such ratings (and their quality) might be improved by consistent infrastructure to support them. More realtime data, which would result from the ability of Web clients and services to compile Web pages of data, or embed extended information, culled from variety of sources according to the preferences of the user. Persistent and shareable categorizations, which would be collaborative way to sort Web documents into searchable categories. The common theme in most wish lists and methods of addressing the deficiencies of the current Web model is that the issues are based on adding information about the content. Then the user client can access, process, and display (or use it) in ways transparent but useful to the user – ideally with some measure of user control. (Reply to this) (Parent) Figure 1.1 Conceptual view of hyperlink functionality as it is currently implemented to form the World Wide Web. The interlinking hyperlinks in Web content provide a navigational framework for users browsing it  The further information about the content that the previous shortcomings and wish list highlight include the metadata and relational aspects, some of which might be implemented as distributed services on the Web. One idealized extension of the originally unidirectional information flow could look as in Figure 1.3.  Figure 1.3 Conceptual view of hyperlink metadata functionality as it might be implemented to form an enhanced Web. Metadata and relational data are gathered and presented to the user for each embedded link. Обратите внимание на правый нижний угол. Необходимо добиться, чтобы метаданные апдейтились и хранились у каждого пользователя, в интересах его собственных и ЕГО социальной сети. А не интересах какой-то незваной внешней authority и той социальной сети, в которую она желает нас встроить. Отсюда требование: хранилище метаданных должно располагаться на клиентской стороне. Серверов или вообще нет, или каждая нода сервер. Данные же могут храниться вообще вне системы, например в существующем вебе. Настоящий интерес представляют их структуры, то есть мета-данные. Сейчас только прочёл. И если честно - запутался в семантиках, авторитетах и сетях :( Если Вы хотите скрыть сложность реализации, не могли бы Вы сначала скрыть сложность теории? Проще говоря, описать, как обычный человек (не знающий слов "семантическая сеть") пользовался бы данной системой, если бы она была идеально реализована. Как он давал бы свою информацию, как помогал бы организовывать чужую... А то я подозреваю, что дискуссия зашла в тупик именно потому, что задача не сформулирована достаточно чётко. "Стать публикатором" - это блоги. Тут Вы скажете, что блоги зависят от серверов. Сделать распределённую систему публикации можно. Более того - она уже существует и называется news. Нынешние юниксоиды не всегда это помнят, но "ньюсы" рассчитывались на Сеть двадцатилетней давности с медленными каналами и совсем не всегда работающими серверами. А уж фильтрация по источнику информации (причём только личная) там продумана очень неплохо. Да, подобрать лёгкие инструменты для подъёма серверов, причём с использованием старинных (и додумыванием новых, возможно) механизмов децентрализации - отдельная задача. Но не столь уж и сложная. Если заинтересовать этим некоторых специалистов (я даже примерно знаю кого), то они бы, думаю, за недельку собрали. Но чтобы их заинтересовать, надо им доказать, что это будет использоваться. А тут есть несколько моментов, которые ставят сие под сомнение: - 90% интересных авторов блогов просто не захотят менять используемый инструмент. Даже на столь же лёгкий, но непривычный. Они-то не считают, что зависимость от сервера им чем-то грозит. Или Вас интересуют только мнения тех, кто согласится с Вашим подходом? Это ведь фильтр не хуже любой "линуксоидности". - Блоги очень редко сознательно строят как "метаинформацию". Как максимум пару ссылок положат. А так может получиться обыкновенная переписка с флеймом, которой в Сети и так хватает. - В децентрализованной системе возможна "подделка подписи", т.е. выпуск информации от чужого имени. И вот как с этим справиться, у меня не придумывается. Подписывать ключами - так понадобится ещё самими ключами как-то обмениваться. - 90% интересных авторов блогов просто не захотят менять используемый инструмент. Даже на столь же лёгкий, но непривычный. Они-то не считают, что зависимость от сервера им чем-то грозит. Или Вас интересуют только мнения тех, кто согласится с Вашим подходом? Это ведь фильтр не хуже любой "линуксоидности". Блоги - это паллиатив. Типа "P2P от Билла Гейтса" которому, когда он будет выпущен, в любом случае не грозит судьба напстера, потому как препятствия "противозаконному" использованию в нем заложены by design. И семантик-веб тоже обязательно будет выпущен от мелкомягких - но того же свойства. А мне очень хочется, чтобы фришная семантик-веб их опередила - примерно так, как eMule и битторренты прочно заняли нишу P2P. - Блоги очень редко сознательно строят как "метаинформацию". метаинформация - это, например, древовидная структура комментариев, или чей-то дайджест типа "записи моих френдов за такой-то период". Если эту подборку кто-то специально опубликовал - я хочу иметь возможность легко на нее подписаться, каким бы чайником не был публикатор. (А сейчас 99% людей лишены возможности публиковать свои подборки: для них заградительно высока стоимость овладевания сопутствующими премудростями). Как максимум пару ссылок положат. А так может получиться обыкновенная переписка с флеймом, которой в Сети и так хватает. "...правда, не факт, что на него кто-нибудь подпишется". Против этого жесткий фейс-контроль: что читать и что передавать дальше, определяет сам читатель, и только он. В децентрализованной системе возможна "подделка подписи", т.е. выпуск информации от чужого имени. Подписывать ключами - так понадобится ещё самими ключами как-то обмениваться. Self-signed certificates? Напомню принцип: если кто-то доверился врагу, и его сигнал стал сильно зашумлен - это только его проблема. В _его собственных_ интересах снести скомпрометированный узел и создать новый с тем же контентом. Действительно заинтересованные именно в этом источнике подписчики сами, _ручками_ настроят свои приемники на сертификат нового экземпляра узла. Узел сносится, контент остается. Ну а если кто-то так лоханулся, что и контент испортили - сам же и виноват: надо было бэкапиться. Сеть гарантирует только дешевизну инстанцирования нового узла. (Reply to this) (Parent) http://ru.wikipedia.org/wiki/%D0%A4%D оттуда http://pixel-apes.com/in/read-only/by/m (Reply to this) (Parent) Внутри ячеек сети могут сосуществовать самые разные способы управления, естественно, что большой узел сам делится на многие узлы, но внутри них способы управления могут быть иерархическими (как в армии или церкви), демократическими, аморфными (как в семье где все знают свои обязанности и добровольно их выполняют), комбинированными и так далее. Один из наиболее характерных способов сетевого самоуправления – «экспертный», при этом решения от всей ячейки по конкретному вопросу принимает человек, который признан ячейкой как наиболее компетентный в данном вопросе, он же несет всю ответственность за последствия. Ещё один способ управления – «семейный», когда лидер ячейки обладает настолько большим духовным авторитетом, что может отменить практически любое решение, принятое демократическим самоуправлением ячейки или настоять на решении, против которого исходно хоть все ее члены, по сути — это духовный отец. Последними двумя способами обычно управлялись даосские ячейки, возможно, самые древние и опытные из сетевых организаций. (Что такое сетевые организации?) От себя добавлю, что это те вариации внутреннего устройства "ноды", вероятность которых следует следует осознать заблаговременно, еще при планировании сети. Радикальное упрощение дизайна узла сети я уже предлагал: аналогично ФИДО, ноды должны состоять из бесправных пойнтов (не из подчиненных нод), и нести полную ответственность за своих "пойнтов". Первоначально ноды - это сервера, к которым обращаются клиенты-пойнты и которые как-то общаются друг с другом (возможно, по протоколу news). Вышеперечисленные варианты - это варианты внутреннего устройства "ноды с пойнтами", которые, вероятно, потребуются в будущем. ======= "Обычно в сетевых организациях подчинение лидеру добровольно. Если лидер теряет свой авторитет, его организация становится безлюдной. Если он сможет вернуть уважение, то вернутся и сторонники. Все очень просто – люди принадлежат ячейке, пока верят ее лидерам. Зачастую убивать лидера совершенно бессмысленно – это никак не влияет на боеспособность ячеек, ими руководят другие люди, которые кроме того, будут мстить. " ===== "Обычным для сетей является образование временных сообществ, создаваемых для решения конкретной задачи и самоликвидирующихся после ее выполнения. " (Из все той же замечательной статьи?) "В результате отношения в организации пронизываются множеством сложных связей. Участник организации может в одном случае быть руководителем своих руководителей в каком-то другом деле или равноправным с ними в третьем вопросе. Небольшие первичные ячейки нередко специализируются на какой-то задаче, например, добывании информации, анализе, обеспечении безопасности, связи и так далее..." Предлагаю несколько иной подход: вместо отслеживания изменяющихся связей (как показано в статье, крайне неудобного), ПО нашей проектируемой сети должно являться ретранслятором опубликованного нодами контента ("сигнала"). Каждая "нода" сама решает, на что подписываться и что передавать дальше (какие фильтры накладывать на ретранслируемый сигнал, в зависимости от источника и уже наложенных фильтров) До того как решать подробности ретрансляции контента, я хотел бы понять, что это будет за контент. Сводится ли он к простому тексту, или "семантичность" предполагает какую-то специфику? Контент - это ни в коем случае не простой текст, а (в идеале) вообще каталог (directory) (то есть информация вместе с метаинформацией). Для начала я бы хотел подписываться на чужие - в т.ч. чайничьи - каталоги (применяя к ним свои критерии выборки) и делиться с друзьями своими 1) каталогами 2) и фильтрами. Фильтр - тоже объект каталога: любой артефакт должен представлять интерес для ретранслятора. Если я сочинял статью сколько-то дней и часов, то весьма вероятно, что моим друзьям захочется иметь ее, а текже делиться своими комментариями к ней... Если я потрудился над фильтрацией контента - точно так же, вероятно, что мой продукт заинтересует моих друзей... Вот здесь было о модели контента. Советую прочесть всю ветку (только комментарии) до низа. Постараюсь прочесть и разобраться. Я бы предложил сначала иметь представление о контенте, включая способы работы с ним, взаимосвязь разных "кусков" контента (самодостаточность? какие-то ссылки?..). А уж потом придумывать систему децентрализованного распространения. Второе куда легче, когда есть первое. (Reply to this) (Parent) ...просто я пока что, если честно, напрочь запутался в фильтрах, каталогах и ретрансляторах. Для меня расшифровка этих терминов оказывается аналогом линуксной командной строки для Вас ;) Моя терминология постепенно сдрейфовала в сторону нижепредложенной системной метафоры Что остается непонятным? (Reply to this) (Parent) Прочёл по ссылке. Но уж с "версемами" - это точно для секты гуманитариев :( Каким-то образом разбивать чужие тексты на куски, непонятно для чего... нет, я не смог бы по этому описанию изложить свои идеи в системе и даже понять, для чего она мне нужна. Необходимо радикально упростить модель контента. Или не саму модель, а её изложение - тут я не уверен, потому что я её не понимаю. Иначе не будет ни разработчиков, ни, что интереснее, пользователей (за пределами узкогуманитарных кругов). Прикол в том, что я Вам говорю почти то же самое, что Вы раньше говорили vchk. Только про содержательную, а не техническую сторону дела. Потребность в "версемах" объясняется просто: любой кусок текста (и в идеале даже подборка кусков текста) должна получать уникальное системное имя. Если A хочет процитировать текст Б, он 1) для начала спрашивает у системы, не имеет ли именно нужная цитата уникального системного имени, иначе сам выделяет цитату и запрашивает у системы вновь созданное для нее имя. Результат вставляет в свой текст в виде ссылки. Вот я пока абсолютно не могу понять, как можно при такой зверски навороченной структуре сделать простое - и при этом полезное - её представление. Это _куда_ сложнее, чем сделать простое представление технической стороны. И более того - это уже не к технарям вопрос... Если кто-то технически реализует движок, первое представление напрашивается - это клиент для блогов вообще и ЖЖ в частности. Добавленная цнность imho выйдет достаточно велика (сравнительно с семаджиком). Не понимаю. Ведь структура там совсем другая - с распадением на "версемы" и т.п. И как это наложится на блог, да ежё так, чтобы быть лучше Семаджика? К сожалению, я явно что-то не осознаю... Ну, вот "версемы" будут обрабатываться умным клиентом дополнительно к возможностям семаджика. Эти и прочие дополнительные (т.е. сверх модели блога) вкусности будут доступны только из нашего клиента. Но данные про эти самые "версемы" и т.п. тоже где-то хранить надо. В блоге для них места нет. Кроме того, надо объяснить юзеру, зачем ему все эти версемности нужны. Я вот не понимаю. Я предпочитаю поиск по ключевым словам, а не по сложным деревьям, кем-то когда-то нарисованным (даже если этого кого-то я очень уважаю). (Reply to this) (Parent) Ну, вот "версемы" будут обрабатываться умным клиентом дополнительно к возможностям семаджика. Эти и прочие дополнительные (т.е. сверх модели блога) вкусности будут доступны только из нашего клиента. Народ постепенно войдет во вкус этих вкусностей. Исходники записей и комментариев должны храниться в клиенте (усовершенствованном семаджике). То есть по сути этот клиент ("семаджик-плюс") будет лишь фасадом к новой системе. А всё же, какие именно "вкусности" там доступны НЕ ГУМАНИТАРИЮ? Лично мне очень не хочется возиться с именованием кусков чужого текста. Если я кому-то хочу показать ссылку, я хочу просто сослаться на сам текст (в идеале на какое-то _место_ в нём, но никак не на вырезанный и поименованный зачем-то кусок), и навесить на ссылку ключевые слова - не "уникальное имя", как раз наоборот, ключевых слов у емня будет небольшой набор. Где-то так я представлял бы себе "метаинформацию" - что не сочетается с изложенным Вами. Дык именование должно быть автоматическим. Простейший юскейс: выделяю мышкой понравившиеся цитаты, и "семаджик-плюс" показывает мне только их. Как в имеющемся в блогах контексте, так и целыми подборками. Свою подборку можно опубликовать - то есть позволить ею пользоваться другим людям через тот же "семаджик-плюс". Особой вкусности пока не ощущаю... Чем "подборка цитат" лучше обычной подборки ссылок, т.е. механизма "Избранное", вполне присутствующего в ЖЖ? Memories - закладывает только пост целиком, вместе со всеми комментариями прошлыми и будущими (Семантика этих закладок подспудно изменяется неконтролируемым образом. Хотелось заложить пост, а закладывается он только вместе с целиком не нужной дискуссией. Или наоборот: хотелось заложить свои ценные мысли, оставив за собой последнее слово в комментариях - и там же, не спрашивая, закладывается куча постороннего флейма...) Логично было бы дать людям возможность запоминать "снимок" дискуссии на тот или иной момент времени. А также отдельные цитаты из заглавного поста или даже комментариев к нему... В данном разрезе блог является простым хранилищем информации. А настоящий интерес представляет метаинформация, служащая описанием хранимой в блоге информации. ..."Заложить третью и четвертую фразы сообщения и первую фразу второго комментария к нему"... "присоединить заложенное к такой-то подборке закладок" и поделиться этой подборкой со всеми заинтересованными... (Reply to this) (Parent) В данном разрезе блог является простым хранилищем информации. Причем довольно сложным хранилищем, предоставляющим неплохую службу имен (учитывая возможность ссылаться на отдельные комментарии). Только этого мало: "аппетит приходит во время еды". К кому приходит, к кому и нет. Я пока не понял удобства для себя от столь сложного механизма "разрезания" текстов. "Для себя" - читать как "и для тех, кто знает столько же, сколько я". Механизм, который казался бы полезным мне, куда проще. Вместо вырезанных "версем" - указатели на точку (вопрос добавки туда ещё чего-то мне не кажется очень важным, в отличие, правда, от вопроса возможного удаления). Вместо уникальных имён - отметка ключевыми словами (ищу-то я почти всегда по ключевым словам, идти по дереву традиционного каталога куда сложнее). И если чем и имеет смысл обмениваться - то набором указателей на ключевые слова, чтобы иметь возможность поиска по ключевым словам, "приставленным" другими людьми. Но поскольку указатели бессмысленны без самой информации - неясен смысл p2p. Если же выгрызать цитаты из контекста и обмениваться ими по p2p - мне тут будет не только неудобно из-за их количества, но и неприятен факт вырезания из контекста как такового. Почти любую цитату вне контекста можно очень сильно не так понять. Вместо вырезанных "версем" - указатели на точку Версемы возникают из желания ссылаться на аутентичные цитаты (то есть обходиться без дублирования контента). (вопрос добавки туда ещё чего-то мне не кажется очень важным, в отличие, правда, от вопроса возможного удаления В моем вИдении добавить что-то к чужому тексту невозможно в принципе. Можно добавлять свои комментарии; сгенерированные системой ссылки на них будут указывать заодно и на id комментатора. Автор может добавить в систему свою статью, в которой (в идеале!) сразу используется системный сервис цитирования. Но допускаются и недоработки (не дошли руки найти ссылки на все цитаты...) - тогда статья помещается "как есть", но всякий может стать "ассистентом" автора и проделать эту работу. Система обязательно назначит его ответственным за то, к чему он прикоснулся. Умный клиент может выставить такому "ассистенту" высокий уровень недоверия или, наоборот, интересоваться не столько исходным текстом, сколько комментариями такого-то происхождения. Вместо уникальных имён - отметка ключевыми словами (ищу-то я почти всегда по ключевым словам, идти по дереву традиционного каталога куда сложнее). Ну да, мне уже давеча попадалась ссылка на готовые сервисы в этом роде (для браузера). Такая штука, реализованная в некоем "семаджике-плюс", стала бы весьма полезной. Я бы например, точно ушел бы от браузера на такой семаджик. Опять потребность в сверхумном клиенте... неясен смысл p2p. А мне вот неприятно обратное: невозможность управлять контекстом своей и чужой информации и делиться результатами с людьми, заинтересованными в созданных мною "фильтрах". Если же кого-то заинтересует мой результат, только специфически отфильтрованный - мне не жалко, но только в том случае, если всегда можно установить факт фильтрации. (Reply to this) (Parent) Если кто-то приложил свои мозги и внимание к той или иной информации, то результат является непременно (полезной или вредной, нужной или ненужной лично мне и моим друзьям) метаинформацией Мне нужен инструмент для публикации полезной (с моей точки зрения) метаинформации и для подписки на интересующие меня аналогичные "источники вещания". (Reply to this) (Parent) Версемы возникают из желания ссылаться на аутентичные цитаты (то есть обходиться без дублирования контента). Как другая сторона медали: любая цитата будет существовать в системе только в контексте. Невозможно вырвать цитату из ее контекстов: отношение цитирующего автора к цитируемым текстам вскроется одним кликом читательской мышки. А читатель - всегда персонаж активный: с досады он может и понизить рейтинг внимания-доверия недобросовестному автору. А может добавить в систему свой комментарий к паре автор-цитата (по ссылке это неудачно названо "ассистент автора": никакого доверия автора "ассистенту", ни даже интереса к его творчеству не предполагается). "Ассистент" - это тот, кто добавляет метаинформацию к имеющейся в системе информации. С каждой цитатой система связывает id каждого (узла сети), кто добавлял к этой цитате контексты. Но показывать читателю будет только при ненулевом пороговом уровне внимания-доверия, выставленному им каждому конкретному узлу. ---- НИКТО не обязан следить за связностью сети и консистентностью инфы, да это и невозможно. Предполагается, что люди сами заинтересованы читать тех, кого высоко ценят. Может быть запущено одновременно несколько разных узлов с разными идентичностями, допустим, по интересам. Предполагается, что авторы-комментаторы сами заинтересованы в том, чтобы от их имени не шел спам - следовательно, сами бекапят свой контент и в случае аварии сами инициируют процедуру "восстановления доброго имени" (то есть отзыва старой подписи узла и установки новой). Технически регенерация узла с нуля (контент берется из бэкапа) должна занимать 15-20 минут (часть обеденного перерыва офисного работника) и быть автоматической (параметры - несколько, как минимум один, адрес ценнейших френдов). (Reply to this) (Parent) Итак, зачем нужны "версемы"? Это универсальный конструкт, предназначенный для одновременного решения несколько задач, таких как: 1) цитирование. Цитата - не просто набор слов или value object "без собственной сущности", а интересный для системы набор метаинформации о ссылке: где она (в каком контексте) и куда (в какой контекст) ведет. Т.е. это сущность со своей идентичностью. 2) цитирование подборок, в важнейшем частном случае - семантически тождественных фрагментов, таких как переводы и пересказы одного текста. В частности, отсюда может произрасти правильная computer-aided translation, которая окажется приложением поверх этого движка. Правильная - это такая, которая поощряет применение аппарата структурной лингвистики. Теперь зачем p2p? А для масштабируемости: затем, чтобы обеспечить рост ОБЩЕЙ ценности системы за счет частных усилий, в т.ч. и малоквалифицированных. (Reply to this) (Parent) Допустим, нужная цитата содержит нецензурную лексику. Тогда любой может добавить в систему цензурную версему той цитаты. :) (Reply to this) (Parent) С "репликатором каталогов" и "картой социальной сети", вот в таком вот изложении, сможет работать исчезающе малое количество людей. Секта почище тех самых hardcore-линуксоидов. Я в их число, кстати, не вхожу :( Попробуйте объяснить это на уровне... ну, скажем, рядового уличного бойца за свободу Родины (не будем обсуждать, кто имеет право на это название, а кто нет). Он терпеть не может "тель-а-визор" и жаждет нормальных слов, но не сведущ в гуманитарных науках. Вот получил он откуда-то компьютер, подключение к Интернету, и Вы бы предлагали ему поставить эту систему. Скажем, поставить её ну очень просто, проще "аськи". Но что он от этого получит? В _его_ терминологии. (Reply to this) (Parent) Можно предложить такую системную метафору: есть потребность в активном репликаторе каталогов. Как он должен работать? Ответ: в зависимости от текущей карты социальной сети (в числе параметров которой входит уровень внимания-доверия одного узла другому). Насколько этой метафоре удовлетворяет сеть из серверов старой-доброй news? Сильно ли их придется переделывать? news - это репликатор уникальных текстов, в общем случае небольших, в общем случае большого количества, с довольно-таки гибко настраиваемыми способами репликации. Но вот удастся ли свернуть контент в уникальные тексты, и подойдут ли настройки репликации (с доработкой напильником) к желаемой системе - я пока не понял. Сейчас мне, впрочем, куда важнее не подробности репликация, а то, что собственно реплицируем. Ваше понятие "каталог" я расшифровать пока не смог - слово уж больно многозначное. A directory is a database specifically designed for the searching and browsing of information. A directory is like a phone book, and is not like a directory (folder) on your computer. Like a phone book, the directory holds information about a thing, like a doctor: First, you find the phone book, then you find "Doctors," then you look for the type of doctor, then you decide which doctor you want to see. The directory is like that. http://www.openldap.org/faq/data/ca В жтом изложении - XMLизируется и легко. А дальше - XML это такой текст. Вот только как предполагается сколь-либо массовое создание контента такой структуры? http://www.openldap.org/faq/data/ca Это низкоуровневый API с потребной именно семантикой. Его услуги используются высокоуровнемвыми приложениями. Например, Outlook Express в винде это клиент не только почтовый, но и LDAP (в M$ реализации - AD). Да - просто чтобы показать насколько разными могут быть технические подходы. Если выяснится, что речь в конечном итоге идёт о большой куче XMLей и разных апдейтах и версиях - так это будет распределённая система контроля версий. Таких аж три доступно - Bazaar, Monotone, git... И это отнюдь не последний вариант. Так что надо сначала очень чётко, очень просто, без ссылок на неясную гуманитарную теорию, поставить задачу. А потом подбирать наиболее близкое существующее техническое решение - и дорабатывать напильником. (Reply to this) (Parent) Да - просто чтобы показать насколько разными могут быть технические подходы. Если выяснится, что речь в конечном итоге идёт о большой куче XMLей и разных апдейтах и версиях - так это будет распределённая система контроля версий. Таких аж три доступно - Bazaar, Monotone, git... И это отнюдь не последний вариант. Так что надо сначала очень чётко, очень просто, без ссылок на неясную гуманитарную теорию, поставить задачу. А потом подбирать наиболее близкое существующее техническое решение - и дорабатывать напильником. (Reply to this) (Parent) Ну, в том, что картинки пропали - такова селява у fromru. Там как раз были показавшиеся мне иллюстрации по теме. Типичный Use Case я описывал вот тут: http://dmitri-kapustin.livejournal.c Образно, дело обстоит так: 1) Информация имела ценность в доинформационном обществе (типа "карты Генштаба", сравнительно с доступным по умолчанию "атласом юного географа"). Нынче ценность имеет метаинформация - то есть способность на те карты генштаба (обладание которыми подразумевается) накладывать собственные слои, способность _суверенная_. 2) Нужен инструмент для а) подписки на авторов интересных "слоев". б) удешевления публикации своих слоев. Каждый теперешний потребитель с виндовым компом сможет "за обеденный перерыв" стать публикатором, открыть собственное "вещание" (правда, не факт что на него кто-нибудь подпишется). (Reply to this) (Parent) Вот пример угрожающего развития событий: http://www.free-lance.ru/ Если пойдет своим ходом туда же, куда идет сейчас (если не предпринять специальных усилий), вскоре вся жизнь окажется "под колпаком" у нескольких десятков владельцев сайтов со своими социальными сетями. А те будут скуплены корпорациями и-или прищемлены госструктурами. Социальная сеть должна быть У КАЖДОГО СВОЯ. В том числе у непрофессионала. И агрегироваться они должны СНИЗУ ВВЕРХ. http://apophates.livejournal.com/11 On the scale of the World Wide Web, any form of centralization would create immediate bottlenecks, in terms of network throughput and server capacity. This need for a flat, non-server-centered architecture will be even stronger on the Semantic Web. Of course, the same physical load-balancing arguments hold as on the current Web, but the Semantic Web adds a new argument in favor of a P2P-style argument. On the Semantic Web, any server-centered architecture will not only create physical bottlenecks, but as communication relies on the use of ontologies will also create semantic bottlenecks. Since the semantics of information will be explicit (or at least more explicit) on the Semantic Web, any single server will in a way “impose” a particular semantic view on all its clients. This will have undesirable consequences, both in terms of the pluriformity of the available information, as well as in terms of the size of the central ontology that such information-servers would have to maintain. Instead, a P2P-style architecture will be able to avoid both the physical and the semantic bottlenecks. Different semantic views, expressed in terms of different ontologies, will be provided by many peers in a flat network of peers, each employing their own local, small ontology. Of course, this increased flexibility comes at a price: such “different semantic views, in terms of different ontologies” create a significant data-integration problem: how will these peers be able to communicate if they do not share the same view on their data? In the remainder of this paper, we propose an approach where the communication between peers relies on a limited shared vocabulary between them. This replaces the role of the single virtual database schema that is the traditional basis for solving information exchange problems... (Reply to this) (Thread) Да, централизация суксь - это практически уже труизм. Но у Вас задача заключается в том, что Вы собираетесь натягивать децентрализованную сеть на централизованные (авторизованные) по своей природе отношения. По крайне мере я Вас так понял. - Всякая ли авторизованность == централизации? Согласно моей vision, КАЖДЫЙ может стать "авторизованным центром". Но только для тех, кто сам настроил свой "приемник" или даже "ретранслятор" на его сигнал. "Cтанции" и "фильтры сигнала" - это очень хорошая системная метафора. Привожу ниже примеры ее применения в частной переписке: ====== >>>>>А я прочитаю - и забуду. >>>>Естественно. Так и должно быть. Ты думаешь я помню наизусть всю эту ботву? :) Надо будет вспомнить - man чего-то. А мне нужен инструмент, который позволит создать и сохранить подборку наиболее интересных (с той или иной точки зрения) цитат из мана. А потом и поделиться своей подборкой с пирами - и чтобы они сразу знали: вот это такой-то ман, прошедший через такой-то фильтр такого-то пира. А это вот подборка таких-то фильтрованных тем-то пиром манов, сделанная для таких-то нужд. Это вот принципиально. Затеваемая сеть должна предоставлять возможность, НЕ КЛОНИРУЯ man-ы, только через ссылки на существующие документы, делиться фильтрованными подборками. И составлять подборки из таких подборок. И создавать новый объект с использованием ссылок-цитат (без их физической cat). (Reply to this) (Parent) ===== >>>>Мне нужна автоматика, которая самонаводилась бы на нужные источники и фильтровала бы поток из них в зависимости от заданных ими и мною предпочтений. >>Да-да-да. >>"Сеть Skynet обрела разум 19 мая 2007 года." (с) Терминатор. >>Оно тебе насамонаводится и навыбирает. Меньше смотри всяких страшилок. Я сказал что это нужно, и точка. Кого не устроит автоматика - будет или по старинке набирать ручками, или совершенствовать алгоритм. "У людей должен быть выбор". >Т.е. написать автоматику чтобы людям приходилось её выключать? Чтобы людям приходилось ее выключать в случае целенаправленной атаки, построенной со знанием этой автоматики. Такую автоматику, чтобы еще и от угроз такого рода сама уходила, нам не осилить. Лучше полагаться на офлайновое резервное копирование контента. Замусорили или скопрометировали ноду - создаем новую ноду, рассказываем пирам о своей беде и они вручную выставляют ей то же внимание-доверие, которое было у старой. >>>Тот же Sage (который вообще плагин к firefox'у) тебе это сделает легко. Такую фигню даже консольный centericq умеет. Да? И сам пойдет за вчк из гж в нпж? И разберется с дубликатами моих записей в жж и в лжру? И стостраничного басурманского мана для этого не нужно зазубрить? (А ведь у людей еще и разная память - именно для того, чтобы не зубрить нечеловеческую абракадабру и нужны всякие knowledge management) Примеры сложнейшего изнутри - и только изнутри - софта, предоставляющие сервис почти полным чайникам это клиенты существующих p2p сетей... ===== ...Кроме того, высокоценные друг для друга пиры могут обмениваться и прямыми адресами, вплоть до образования ноды с общей ответственностью. (Каждый из пойнтов ноды служит бордером ко всей ноде, они равноценны в этом смысле - то есть если хотя бы один из пойнтов пристутствует в сети, то присутствующей является вся нода .) Система человекочитаемого именования пиров, вероятно, должна быть иерархической: положим, сначала были "ноды" apophates и vchk, а потом они сговорились стать "пойнтами" общей "ноды" maniacs.apophates и maniacs.vchk Но это только человекочитаемые имена, на самом деле у каждой ноды есть guid - чтобы можно было различить между независимо возникшими тезками. Но выживают только добропорядочные тезки, а не наглые самозванцы: те постепенно получают низкую оценку, и сигнал от них теряется. (?Клиентов может быть запущено несколько. Например, один в общей ноде с vchk, другой еще с кем-то, а третий сам по себе. У всех разные guid ?) Клиент - это нечто инкапсулированное, максимально независимое от хоста и совершенно не зависящее от других экземпляров клиента. (?Разный или общий контент у разных нод, сосуществующих на одном компе???) ===== ...Нынешнее мерзостное общество, окружающее нас в реале, построенно через победу над нами в информационной войне. Обратить эту победу в поражение можно только асимметрично, "на другом уровне игры". Хотели, чтобы люди захлебывались информацией - получите, только каждый станет ее источником и будет структурировать окружающее пространство под себя (а не вибрировать вам в такт, как задумывалось). Хотели, чтобы люди покупали винду, все более мощные процессоры, диски и каналы подключения - теперь каждый виндовый компьютер станет центром своей информационной вселенной. "Как-то так". ==== >>Организовывать связь не надо: она повсюду, но она вражеская. Она специально >>так сделана, чтобы у быдла, не знающего "волшебного слова", неотвратимо >>зашкалило соотношение шум/сигнал. >Угу. Только что толку от фильтра, если твоим сигналом невозможно воспользоваться? Полезный сигнал - это способность самому организовывать информационное пространство, для себя и своих друзей. Именно его надо передавать, наперекор отчаянному сопротивлению нынешней организации этого пространства. (Reply to this) (Parent)
Hi, nice very nice page..!
Nice homepage! :)
Good luck ! | ||||||||||
![[info]](http://lj.rossia.org/img/userinfo.gif){kind=small}