Идея проекта семантического менеджера semap

Идея проекта семантического менеджера semap

Ответов — 32, стр: 1 2 All [только новые]

dulanov Или вот такой пример. Открываем Acrobat Reader и вместо «Открыть файл» используем «Открыть статью» и открываем её не рыская по каталогом, а ища по названию или выбирая по автору. Ведь здорово?

mihazimin Извините за флейм в сторону, но не удержался. dulanov в аське писал: >> Искать метаинфу для mp3 — мне кажется трудно, потому что много вариантов оцифровок и хеш-коды не сойдутся. >> Хеши это круто, только они должна над уникальными данными строятся, чтобы остаться уникальными. Как ты отхешируешь книгу в chm и pdf одновременно? В предлагаемом сервисе к semap (будет ли приспособлен semap для этого сервиса?) и не ставится задача по началу связать одним хешем между собой 2 книги в формате pdf и в формате chm. Нет. Вот есть у меня файл pdf, и у когото совершенно такой же или ну очень-очень похожий .pdf файл. У них одинаковые кеши. Кто-то написал для этого .pdf-ника какую-то мету. Я об этом ничего не подозреваю, нажимаю на одну кнопку, и получаю эту мету (если у меня есть файл с таким же хешем). С mp3 тоже самое. Да, есть огромное количество вариантов оцифровки. Но я и не предлогал для разных оцифровок использовать одинаковые кешы. Нет. Катя дает mp3 Свете, Света Вите, Витя Лене, Лена мне. (Вполне вероятная схема). Это один и тот же mp3 файл (т.е. mp3 заголовки у него могут быть разные, но бинарные данные то одинаковые). И опять ничего не подозревая и не предпринимая можно получить мету для м. произведения, книги и т.п. А потом, какой-нибудь сервер будет сгребать у себя пары («хеш» + «мета») и оценив их приходить к выводу, что хешA описывает туже мету, что и хешB, устанавливая между ними взаимное соответствие, и при хороших обстоятельствах объявляет, что большую часть их меты вообще можно считать единой и одинаковой. Мне кажется, что именно подобные сервисы смогут принести популярности semap, а не просто его раскрутка (как он есть). Просто я хочу понять, можно ли построить что-нибудь подобное на semap. И как в данном случае надо с семапом взаимодействовать. Т.е. даже прочитав оригинальную статью не совсем понял что представляет из себя semap как черный ящик.

dulanov Идею понял, она здравая. Что же касается готовности semap для её реализации. semap — он лишь берет ваши RDF данные. Ему без разницы как и откуда вы их получите. Но вот построить семантический сервис, который запросит у semap информацию о музыкальных файлах и их хеш-мепах возможно, следовательно, возможно над ним написать, к примеру, P2P-сервис для их обмена. Как думаешь? Опять же хочу заострить внимание, что semap планируется сделать предметно независимым, инструментом для сбора RDF данных и их предоставления семантическим сервисам. Что заложете в онтолоии и RDF данные, то и сможете использовать. Михаил — идея строить хеши для бинарников мне очень нравится! При разработке онтологии для файловой структуры это надо будет обязательно учесть и заложить в semap возможность поиска семантических данных по произвольному хеш-коду.

jupy mihazimin пишет: Предлагаю помимо прочих рассмотреть следующие сценарии пользования semap… Да, твоя идея, по-моему очень правильная. Я тоже предполагал сделать подобный сервис в будущем. Причем, если бы у нас уже был semap, то реализацию такого функционала можно было бы сделать буквально за неделю. Ведь, суть идеи сводится к тому, чтобы добавить в файловую онтологию свойство: «хэш». И обеспечить распространение этих метеданных через сеть серверов. После этого, можно будет легко использовать это свойство для формирования SPARQL запросов на извлечение остальных метаданных. В этом и прелесть semap, что он формирует инфраструктуру для разработки самых разных сервисов. Но больше всего в твоем посте мне понравилась вот эта фраза: Также сделает милион пользователей Semap по всему миру.

jupy К вопросу о gnowsis. 1) gnowsis — проект в большей степени исследовательский, semap — прикладной 2) gnowsis — это семантический десктоп и это для него главное. semap — это среда для создания различных сервисов, и для интеграции приложений. В этом смысле semap больше похож на enterprise service bus нежели на semantic desktop. 3) если у проекта не существуют аналоги, то можно быть абсолютно уверенным, что он никому не нужен. Так что gnowsis — это хорошо, но semap — лучше!!!

dulanov jupy пишет: К вопросу о gnowsis. 1) gnowsis — проект в большей степени исследовательский, semap — прикладной 2) gnowsis — это семантический десктоп и это для него главное. semap — это среда для создания различных сервисов, и для интеграции приложений. В этом смысле semap больше похож на enterprise service bus нежели на semantic desktop. 3) если у проекта не существуют аналоги, то можно быть абсолютно уверенным, что он никому не нужен. Так что gnowsis — это хорошо, но semap — лучше!!! 4) gnowsis не ориентирован изначально для работы как сервис по сбору и обмену RDF данными, то что мы назвали семантической шиной. И трудно выкинуть из него ненужные сервисы и использовать только эту шину 5) В gnowsis сделана попутка создания универсального инструмента, мы же пытаемся разработать в первую очередь шину и подстолкнуть других разработчиков использовать её для разработки семантических сервисов. 6) САМОЕ ГЛАВНОЕ! gnowsis позволяет создавать данные непосредственно в хранилище. 7) Сервер gnowsis не поддерживает plugins. И это если не учитывать что его даже запустить непросто, у меня он с фатальной ошибкой стартует.

jupy В первой версии админский консольный интерфейс (Пункт 3.1.1 3 ТЗ) предлагаю убрать, и все параметры администрирования задавать в ini (RDF, N3 или JSON) файле. Далее мне не понятно, как ты предполагаешь управлять кешем. Тоесть, можно ли на уровне подключения источника данных указать, что информация должна быть закеширована? Это может быть полезно, например в случае, когда мы используем портабельную версию на флешке. Кроме того, это способ относительно безопасного (с точки зрения архитектуры) добавления информации в RDF хранилище semap. Когда я говорил о том, что semap должен уметь работать с простыми RDF файлами, как с источниками, я имел ввиду, что эта функциональность реализована не с помощью плагинов, а встроена в semap. Я полагаю, что эта возможность полюбому будет реализована. Тоесть архитектурно, это может быть плагин, но он должен поставляться в составе самого продукта и на нем может быть основана часть функцинала самого semap, например те же файлы конфигурации. Многие сервисы-источники, очевидно, будут иметь GUI. Может имеет смысл сделать единый framework в рамках которого будет запускаться GUI таких сервисов. Тоесть API для плагинов должен предусматривать возможность использования такого framework-а. Таким образом, у пользователя будет ощущение, что он работает с одним целостным приложением.

Иван Михайлов Не толстовата система и её системные требования? IMHO, обычному пользователю понадобится что-то очень маленькое и простое в обслуживании, а в минимальной конфигурации система должна влезать в мобильные устройства ближнего будущего (какими они будут через два года). Один из напрашивающихся вариантов — использовать OpenLink Virtuoso Universal Server для толстой корпорации, Virtuoso Open Source для SOHO или персонального использования. При желании можно обсудить технические подробности за чашкой кофе 4-го мая в Москве или 6-12 мая на WWW2007. Мой мобильный +7-913-924-19-67. Предупреждение. Моё мнение предвзято и необъективно, так как я реализую SPARQL для OpenLink Virtuoso и представляю OpenLink в DAWG W3C.

mihazimin Мы тут очень ожесточенно спорим с jupy. Как ты думаешь, как semap должна функционировать. Кешировать данные пользовательские данные и уже над ними поиск осуществлять. Или SPARQL запрос адресовать источникам, которые будут непосредственно к данным обращаться и уже кешировать такие запросы? Лично мне больше нравится вариант, когда непосредственно в semap лежит кеш. Возможно, создатель сервиса, и не будет подозревать о том, что есть огромный кеш на уровне semap, также, как и программист обращается к ячейке оперативной памяти, не зная (возможно) о том, что её значение берется из кеша. Хотя нет, создатель сервиса должен знать о кеше semap и он должен иметь доступ к его настройкам, которые относятся именно к его источникам. Но использовать кеш semap как единственное хранилище rdf-данных я бы не стал. Все rdf данные можно/(можно было) откуда-то забрать помимо semap. (Вообще, предлагаю для данного случая перейти от термина rdf-данные к термину «ответы на sparql запрос»). Т.е. sparql-запрос будет адресован источникам (с точки зрения создателя сервиса), но semap сам решит адресовывать ли этот запрос настоящим источникам, или, если требуемая информация есть в кеше, доставать её оттуда. До этого, конечно, создатель сервиса настроит свой частный кеш semap. Создателю сервиса необходимо позволить настраивать кеширование как запросов, так и самих данных (триплетов, насколько я понимаю). Должен ли semap напрямую работать с Интернет-источниками? Архитектурно это должны выполнять расширения. Пусть некоторые из них будут всегда входить в стандартную поставку semap, но это однозначно должны быть расширения. По моему мнению при решении подобных задач необходимо руководствоваться тем, что при ответе на sparql-запрос сама semap должна работать совсем чуть более 0 сек. Если для того, чтобы ответить на запрос не хватает 0 сек (например, необходимо лезть в интернет), то это архитектурно уже выполняется не шиной semap, она лишь только перенаправляет запрос расширению. Т.е. шина semap — это интерфейс, который позволяет с 0 скоростью наладить взаимодействие между сервисами и внешними источниками. Тем не менее в стандартную поставку следует включить несколько расширений (для работы с дисками, с интернетом). Может я и перегибаю, но по моему мнению и кеш (который использует шина semap) в данном случае необходимо рассматривать как нечто, — находящееся только в ОП во время работы semap (или только в файле подкачки). Все остальное, в том числе и какое-то кеширование на уровне жесткого диска следует реализовывать в виде тех же расширений, плагинов или чего-то подобного, которым будет перенаправлять запросы шина semap. Ещё пару мыслей: По моему, в sparql-запрос сервиса должен выглядеть примерно так: {источник, запрос} Любое расширение/плагин должен быть привязан к определенному виду источника. Например, есть расширение sesame кеш, он привязан ко множеству источников A, есть расширение интернет-источник, которое тоже привязано ко множеству источников A. Сервис посылает в шину запрос {a, запрос} причем a содержится в A. Тогда sesame действует так: смотрит свой динамический кеш sparql запросов, смотрит свой динамический кеш триплетов, адресовывает запрос первому расширению, которое поддерживает A (sesame расширение), адресовывает запрос второму расширению, которое поддерживает A (расширение интернет-источник). Т.е. сама шина semap получается достаточно просто выполняемой программой. Она не имеет своих собственных ресурсов на жестких дисках и т.п. Всё остальное делается при помощи расширений, пусть являющихся стандартными, но всё таки расширениями. Т.е. сервис посылает в шину запрос {a, запрос} А semap сначало смотрит в своем динамическом кеше, а потом начинает обходить по приоритетам все расширения, которые поддерживают источник a. Пока одно из расширений ему не ответит. Таким образом можно писать расширения, которые будут перенаправлять запросу в интернет, или копаться в жестком диске, или доставать из храгнилища. И писать те, которые мнгновенно отвечают. А то, что 2 разных расширения могут поддерживать одинаковые источники, очень хорошо. Это означает, что можно будет организовать тоже кеширование на жестком диске, например или где-то ещё. вообще система становится очень гибкой. Причем, есть у меня например шина semap без всякого хранилища или чего-нибудь подобного. Чувствую я, что запросы медленно выполняются. Ставлю себе расширение репозиторий sesame, который поддерживает все типы источников и всё теперь у меня хорошо. Вот как я предполагаю будет работать semap: смотрит свой динамический кеш sparql запросов, смотрит свой динамический кеш триплетов (если ничего не находит, то оставляет просьбу об оповещении при нахождении), адресовывает запрос первому расширению, которое поддерживает A (sesame расширение) (если ничего не находит, то оставляет просьбу об оповещении при нахождении), адресовывает запрос второму расширению, которое поддерживает A (расширение интернет-источник). Интернет-источник возвращает результат. Теперь смотрим кто оставил просьбу об оповещении: Его оставил динамический кеш триплетов и sesame расширение. Мы им отправляем найденные результаты, а они уже что хотят с ними то и делают. Таким образом могут работать расширения-кеши/репозитории. Обычные расширения просто не будут оставлять просьбу об оповещении. Как устанавливать какое расширение приоритетней я не знаю.

dulanov Иван Михайлов пишет: Не толстовата система и её системные требования? IMHO, обычному пользователю понадобится что-то очень маленькое и простое в обслуживании, а в минимальной конфигурации система должна влезать в мобильные устройства ближнего будущего (какими они будут через два года). Один из напрашивающихся вариантов — использовать OpenLink Virtuoso Universal Server для толстой корпорации, Virtuoso Open Source для SOHO или персонального использования. Толстовата, я даже специально на этом акцентировал внимание. Но зато по функционалу достаточно прозрачна. К сожалению, мы сейчас не обладаем достаточным ресурсом чтобы его реализовать в более разумных системных требованиях ;( Virtuoso Open Source — отличная система, я много про неё читал, было бы здорово встретиться лично и узнать как она сможет решить указанные в заметки задачи. Надеюсь мы завтра пересечемся ;)

dulanov Первоночальная заметка про шину semap уже претерпела несколько ревизий и сейчас доступна финальная версия, в которой устранены многие спорные моменты. Но, к сожалению, не до конца. Сейчас я дописываю версию заметки 1.1 в которой затрону архитектурные и целевые аспекты. Самая главная мысль, которая сподвигла меня на новую ревизию была в том, что я осознал, что семантическая шина semap — это прообраз файловой системы будущего, ни больше и не меньше. Т.е. сейчас приложения работают в основном либо с файловой системой, либо с базой данных, в то время как семантические сервисы начнут активно взаимодействовать с семантической шиной и на неё перейдёт целый ряд характерных для файловой системы задач. Это и управление правами и обмен информацией и пр. Т.е. думая об функционале семантической шины я ловлю себя на том, что он сильно перекликается с функционалом файловой системы. Я не буду сейчас утверждать, что семантическая шина — это замена файловой системы, пока об этом судить рано, но также не вижу особых проблем чтобы в будущем всю файловую систему переметсить в семантическую шину. Более того, семантические шины намного проще интегрировать друг с другом и обьединять в глобальные базы и не просто в них хранить семантические данные и цифровые фрагменты, но и передавать сервисы «по требованию». А куда это всё ведет? К трансформации традиционных пользовательских компьютеров в информационную сеть и набор небольших персональных устройств. Т.е. я не исключаю возможность появления рядом с электрической розеткой — информационной. После такого футуристического введения я хочу всех успокоить. Это пока просто идеи, в заметке же я просто отмечу сходство функционала между файловой системой и семантической шиной и немного поменяю архитектуру. В частности, я не вижу смысла не позволять семантическим сервисам напрямую заводить и изменять семантическую инфомрацию в шине. Они это и так уже могут, но косвенно, зачем же их ограничивать. Более того, после некоторых раздумий, я пришёл к выводу, что истинные семантические сервисы как раз будут работать с шиной напрямую, а традиционные приложения смогут интегрироваться с шиной «по старинке» через файлы и асинхронные уведомления об их изменении.

jupy dulanov пишет: Я не буду сейчас утверждать, что семантическая шина — это замена файловой системы А я буду. По крайней мере на уровне конечного пользователя «семантическая шина» как раз и должна выглядить как замена файловой системы (черт возьми, я всю последнюю неделю об этом думал). На уровне приложений это может быть и не так, но пользователю блуждание в иерархической системе папок, файлов и ярлыков абсолютно не нужно. И присваивая документу семантические атрибуты пользователь может значительно облегчить себе поиск информации и работу с этим документом в будущем.