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

Для ответа включите в броузере поддержку JavaScript (средний уровень безопасности по умолчанию)

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

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

jupy Дим, извини, что я пропал, но я был вне зоны доступа. Так вот, возвращаясь к нашим баранам, можешь более подробно описать, что ты подразумеваешь под семантической шиной? И более конкретно, чем она по-твоему должна отличаться от простого RDF хранилища? Далее, я так и не понял, ты допускаешь обмен семантическими данными между пользователями или нет? Если нет, то это сильно ограничит и сферу применения подукта, и количество источников метеданных. Если да, тогда возникает ряд вопросов связанных с обеспечением релевантности передаваемых данных. Мне кажется, что это можно более менее надежно решить только используя криптографические средства. Тоесть в системе должна присутствовать достоверная информация об источнике метаданных. Кроме того, если допускается передача метаданных между пользователями, то необходимо управлять доступом к данным. Так как среди метаданных будет информация как открытая, так и приватная. Вряд ли пользователь обрадуется если его e-mail будет рассылаться всем на право и на лево. В случае, когда в системе появляются взаимоисключающие данные, как ты полагаешь преодолевать неоднозначности? Я хотел использовать для этого статистический подход. Тоесть, например, если некоторые источники указывают, что определенный документ относится к категории AI, а другие утверждают что это SW, то система должна определять некие веса для каждого такого утверждения основываясь на данных о количестве голосов за то или иное утверждение и на степени достоверности самих источников данных. В таком случае получается, что семантическая шина должна обеспечивать следующее: 1) хранение RDF и обеспечение доступа к метаданным 2) трансляцию запросов к внешним источникам метаданных 3) управление доступом к хранящимся данным 4) отслеживание авторства метаданных 5) возможно, некоторый механизм разрешения неоднозначностей 6) API для создания плагинов: источников метаданных (например, для извлечения тегов из mp3 файлов) диалогов для ввода метаописаний пользователем (для разных ресурсов) потребителей семантической информации (например средств для визуализации данных) (впрочем может быть это лишнее, так как шина должна обеспечивать SPARQL доступ)

jupy Если говорить о Use Case-ах, я бы предложил говорить не о добавлении книги, публикации и т. д., а о добавлении ресурса в самом широком смысле этого слова. Мне кажется, что система не должна закладываться на использование конкретных онтологий. Тоесть на уровне семантической шины все виды ресурсов должны быть равнозначными. Другое дело, что на уровне GUI для каждого конкретного ресурса может использоваться свой диалог, но эти диалоги, как мне кажется, должны быть сделаны в виде очень простых Plug-in-ов. Тогда спектр возможных применений semap-а будет максимально широким.

jupy По поводу OSGi, я, к сожалению, не большой знаток Java технологий, поэтому могу ошибаться. Однако, если я правильно тебя понял, то использование OSGi означает, что пользователям придется инсталлировать eclipse. Не противоречит ли это требованию создать систему максимально удобную для конечного пользователя?

dulanov Очень аргументированные вопросы, спасибо. Сразу замечу, что моя заметка не является чем то уже окончательно оформленным и предназначалась скорее для инициализации «мозгового штурма». Со многим сказанным согласен. И насчет криптографической защиты и по поводу релевантности данных, но на первом этапе я решил опустить эти проблемы, потому что они ещё толком не решены в самой технологии семантического веба и предполагают достаточно много не связанной с базовой идеей работы. Мне кажется их надо иметь в виду, на будущее. Суть же заметки в архитектуре решения, в семантической шине. Как я себе её представляю? Это некая шина семантических данных, над которой можно создавать всевозможные семантически-ориентированные сервисы. Идея похожа на подход, активно используемый для интеграции корпоративных приложений Enterprise Service Bus (http://en.wikipedia.org/wiki/Enterprise_service_bus). Семантическая шина позволит развязать данные и приложения. Легко можно будет создавать данные в одном приложении и сразу же использовать их в другом. К примеру, заводить библиографии в одной утилите, а вставлять ссылки в Open Office уже из другой. Третья же утилита будет отследивать изменения определенных данных и публиковать их в формате RSS. Четвертая будет обновлять на блоге страничку — что я недавно прочитал и т.д. и т.п. Детали реализации пока ни до конца ясны, но эта шина должна позволять как минимум следующее: 1. Через точки расширения регистрировать источники RDF данных (как внешние, так и внутренние) и их слушателей; 2. Предоставлять полноценную SPARQL точку доступа к RDF данным. Все это будет работать над какой-то реализацией семантического хранилища, но наверняка понадобятся доработки. Над этой шиной можно создавать кучу утилит, в частности, я планирую создать инструмент для управления библиографиями, что и описал в пользовательских историях. И архитектурно так предусмотрено, что нет такого понятия как позволить обмениваться данными. Для этого достаточно над точкой расширения SPARQL написать сервис, который будет ими обмениваться через P2P, через FTP, через WebDAV или как-то ещё. Это как бы детали. Но надо с чего то начать, чтобы понять что нам действительно надо от семантической шины, чтобы она позволила реализовать эти сценарии. Пока не предусмотрено ограничения доступа к данным или чего-то другого, надо хотя бы прототип написать ;) Технологию OSGi я выбрал, потому что она позволит реализовать расширяемую динамическую архитектуру для семантической шины. Реализация же OSGi eclipse equinox сейчас самая зрелая, поэтому и планировал её использовать. Это ни в коем случае не eclipse RCP, а лишь его крошечное основополагающее ядро. Сама по себе семантическая шина не будет обладать никаким интерфейсов, кроме как через сокет или Веб-сервис (надо уточнить как это сделано в Google Desktop). Использование OSGi означает, что пользователям придется инсталировать Java машину. P.S. Во всем этом меня смушает, что придется держать семантическую базу данных. Я не уверен что это оправдано. Возможно лучше использовать её только для кеширования и построения индекса RDF данных. А сами источники делать более распределенными.

dulanov Именно для обкатки этих идей я и решил написать пока надор утилит для работы с библиографими и реализовать указанные в заметки пользовательские истории. И при этом постараться выделить семантическую шину. Сценарий работы примерно таков. За основу будется туча pdf, chm и пр. документации, которой у меня гигами. Начинаются реализовываться друг за другом пользовательские истории. В самом начале ничего особенного не происходит. Мы создаем утилиту, которая ведет набор rdf-данных для библиографий. Затем мы создаем семантическую шину для централизованного доступа к ним. Для этого мы разрабатываем источник данных над созданными rdf-данными. После этого пишем другие утилиты, которые будут регистрироваться как расширения или использовать точку доступа SPARQL семантической шины, например обмен файлами через WebDAV.

dulanov Да, мне кажется сама семантическая шина должна быть средством для сбора семантических данных локального происхождения и из Интернета. При чем они не должны в ней заводится и изменяться напрямую. Шина должна позволять их только индексировать, кешировать, искать, служить посредников в обмене. При необходимость её можно будет удалять не затрагивая сами данные, которые будут лежать в базах данных, в виде rdf-файлов и вообще как угодно. ИМХО, это мне нравится! Моя душа немного успокоилась ;)

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

jupy dulanov пишет: Во всем этом меня смушает, что придется держать семантическую базу данных. Я не уверен что это оправдано. Возможно лучше использовать её только для кеширования и построения индекса RDF данных. А сами источники делать более распределенными. Мне кажется наоборот, централизованная семантическая база — это ключевой компонент. Потому что такая база будет содержать информацию пользователя. В отличае от других источников, которые будут хранить данные приложений. У меня была мысль, что пользователь вообще сможет держать такую базу на флешке. Соотвественно он будет иметь свою среду на любом компьютере. Как говорится все свое ношу с собой. Это, конечно накладывает дополнительные требования, но мне кажется, что такой функционал был бы очень полезен. А если пытаться реализовать его как подключаемый модуль, то это будет сложнее сделать. Кроме того, если, например, предположить, что каждый документ имеет свое RDF описание в виде отдельного файла, то, конечно резко упадет производительность всей шины. А долгие запросы похоронят всю идею. Что касается криптографии, управления доступом и т.д. Я соглашусь, что не стоит делать это в прототипе системы, но нужно все время иметь это ввиду так как эти вещи могут оказать серьезное влияние как на интерфейсы системы, так и на общую производительность. Таким образом получается, что весь проект у нас представляет собой набор очень простых (и практически независимых) модулей, активно взаимодействующих друг с другом. Черт возьми, может получиться хорошая штука.

jupy Кстати, я тут понял как можно примерить наши взгляды на OpenSource. Действительно семантическая шина распространяемая по такой лицензией имеет существенные преймущества, а соответственно и шансы на то, чтобы завоевать популярность. С другой стороны сервисы, которые ее используют легко могут быть и коммерческими. Важно только чтобы шина имела простое, тщательно проработанное API для подключения плагинов. И, желательно, обеспечить доступ к этому API из разных сред: java, c++, COM.

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

jupy Резюме: На сегодняшний день речь идет о разработке прототипа системы с минимальными возможностями, который позволит с одной стороны продемонстрировать состоятельность идеи, а с другой выявит проблемы, которые необходимо решить для создания полноценного продукта. К сожалению, я не смогу уделять этому проекту много времени, но, примерно 10 часов в неделю я готов ему посвятить. Теперь несколько вопросов по поводу организации процесса разработки. 1) Предполагаешь ли ты установку каких-либо сроков? (Мне кажется, что это было бы полезно для того, чтобы в команде был правильный настрой). 2) Очевидно, что разработка будет вестись на java (я последний раз на ней писал, страшно сказать, лет девять назад). Предполагаешь ли ты использование каких-то соглашений по оформлению кода (Style Guide)? 3) Как будем тестировать? (для начала я бы предложил активно использовать методологию Test Driven Development). 4) Я думаю, что имеет смысл более активно заниматься пропагандой semap-а. С одной стороны для того, чтобы вовлечь в разработку еще людей, а с другой, для того, чтобы понять дополнительные требования потенциальных пользователей.

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

dulanov jupy пишет: Конечно, я имел ввиду, что на флешке будет вся система целиком: и данные, и шина. Что же касается взаимодействия шин между собой, то на мой взгляд это должно быть реализовано обязательно. Именно, и сразу легко представить такую ситуацию. Вставляем флешку в компьютер и теперь работаем уже с семантическому ифнормацией как самого компьютера, так и флешки прозрачным образом.

dulanov 1) Предполагаешь ли ты установку каких-либо сроков? (Мне кажется, что это было бы полезно для того, чтобы в команде был правильный настрой). Вопрос сложный, потому что не ясно с какими техническими трудностями мы столкнёмся. Кроме того, как я описал в последней заметке, мы имеем несколько направлений работы. Пэтому надо также решить кто чем будет заниматься. Для прототипа ставить сроки сложно, на мой взгляд. другое дело когда мы проверим наши идеи и начнем планомерно их воплощать. 2) Очевидно, что разработка будет вестись на java (я последний раз на ней писал, страшно сказать, лет девять назад). Предполагаешь ли ты использование каких-то соглашений по оформлению кода (Style Guide)? Соглашения стандартные от Sun — http://java.sun.com/docs/codeconv/ 3) Как будем тестировать? (для начала я бы предложил активно использовать методологию Test Driven Development). Использование TDD — это даже не пожелание, это требование. Как минимум для разработки семантической шины и расширений для неё. Кроме модульных тестов надо будет написать и функциональные и нагрузочные. Чтобы тестировать производительность. 4) Я думаю, что имеет смысл более активно заниматься пропагандой semap-а. С одной стороны для того, чтобы вовлечь в разработку еще людей, а с другой, для того, чтобы понять дополнительные требования потенциальных пользователей. Именно поэтому заметка будет переведена на английский, где есть очень большое коммунити и мне кажется будет большой feedback. Разработку я также предлагаю везти полностью на английском языке. Я даже удивлен, если честно, что заметка повлекла такое количество откликов в ру зоне. Не ожидал! Резюме: На сегодняшний день речь идет о разработке прототипа системы с минимальными возможностями, который позволит с одной стороны продемонстрировать состоятельность идеи, а с другой выявит проблемы, которые необходимо решить для создания полноценного продукта. К сожалению, я не смогу уделять этому проекту много времени, но, примерно 10 часов в неделю я готов ему посвятить. Если не возражаешь вставлю первой предложение в свою заметку, согласен на 100%. Лично я готов посвящать проекту 3 часа в день и где-то ещё час на переписку.

dulanov У меня план на ближайшее вермя таков. Мы ещё некоторое время собираем идеи и мнения. Я пишу финальную версию заметки и перевожу её на английский язык. Примерно в это же время мы пишем ТЗ на разработку семантической шины и библиографического сервиса. Нужны люди, кто будет писать остальные сервисы — это может быть дипломом кстати ;) Также надо определится с используемыми в разработке инструментами. Никто не возражает против постинга Google — http://code.google.com/p/semap/ ? Также нужно будет установить Wiki, создать новостную группу и пр.

jupy Последнее время интерес к этой теме безусловно растет, так что люди, я думаю найдутся. С твоими планами я вообщем согласен. Что касается сроков, я бы сказал так: до лета мы ничего путного сделать не успеем, лето — не лучшее время для собирания команды, поэтому нужно получить какой-то минимальный прототип к осени, чтобы начиная с осени уже приступить к основной части проекта (работоспобному приложению). Соответственно исходя из этого и наших возможностей нужно прикидывать, что мы включим в функционал прототипа.

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

mihazimin Почитал оригинальную статью. Комментарии не все пока смотрел. Возможно то, что я предлагаю уже кто-то реализовал, незнаю. Предлагаю помимо прочих рассмотреть следующие сценарии пользования semap (вместе со с ценариями, сразу же идут и предложения о реализации): 1. У меня есть много-много разных файлов с расширениями mp3, doc, rdf, ppt. Я нажимаю на иконку semap, он коннектится к сети, шибуршит сполчасик. и алеоп все готово: за большинством mp3, doc, rdf, ppt закрепляются качественные rdf данные (о том, что это за данные здесь внимание заострять не будем). Первая мысль которая приходит в голову, — это фантастика. (Т.е. просто не реально). Вот например с тем же iPodом (спасибо брату за то, что подарил): Загрузил я туда свои любымые песни, но очень многие из них не содержат в метаинформации ничего, кроме названия: ни автора, ни исполнителя, ни альбома. А мой iPod не знает откуда взять всю эту метаинформацию. Предлагаю в случае с semap и mp3 файлами делать так: Для тела каждого mp3 файла высчитывать хеш. Под телом файла я подразумеваю именно бинарные данные (те данные, которуе потом передаются на динамик). Несколькими битами в хеше кодировать длительность произведения. Таким образом тело каждого моего mp3 будет сассоциировано с несколькими байтами, например: Morning Star.mp3 «43hWQbERTGt24yiuRTG72834ee3err435t2tf» Avalon.mp3 «gtf23rfSFweR3rERtm34nkwerRT32597feREt» Теперь (если я разрешу), то semap передаст в сеть (что это за точка, сейчас говорить не будем) следующее: «43hWQbERTGt24yiuRTG72834ee3err435t2tf» метаданные, которые записаны в MP3 заголовке файла Morning Star.mp3 «gtf23rfSFweR3rERtm34nkwerRT32597feREt» метаданные, которые записаны в MP3 заголовке файла Avalon.mp3 Эти метаданные могли изначально быть в файлах, я мог их написать сам через функцию winampа fileinfo или через аналогичную функцию semap. Также сделает милион пользователей Semap по всему миру. Там на каком-нибудь сервере со всей этой информацией что-нибудь сделают, так что всё будет хорошо и сервер SEMAP сможет отвечать на подобные запросы: SELECT ?x WHERE { _:a онт:хеш «35eER4534serd2345ERWgssf435rRTf533WT4»; онт:мета ?x . } А почему, собственно мой semap клиент пошлет этот sparql запрос серверу. А потому что у меня есть файл: Kryptonite.mp3 «35eER4534serd2345ERWgssf435rRTf533WT4» который в своем заголовке совершенно не содержит никаких метаданных. А запрос мой очень быстро выполнится и мне придет ответ от сервера (скорей всего, — метаданные большинства пользователей, или метаданные выбранные по другому критерию, всё это клиент может настроить в запросе): Название: Kryptonite, Исполнитель: 3 Doors Down, Жанр: Рок, и т.д. Всё, я очень доволен. Я просто два раза нажал на иконку semap, он приконектился к сети, шибуршал чё-то там, и теперь у меня у большинства песен исполнитель, альбом, год, ну всё, в общем, указано. А теперь мой semap клиент и iPod-подобную навигацию может строить. Т.к. вся информация у него для этого есть. При желании, если понравится, эту технику можно распространить и на видеофайлы (фильмы), изображения и любую другую бинарную информацию. На самом деле, в мире продуктов уже давно используются хеш функции для того, чтобы однозначно идентифицировать объект, — это разнообразные ISBN, штрих коды и т.д. Сейчас походил, подумал, и ещё болше понял почему нам надо будет использовать хеши, когда мы описываем какой-то бинарик. По задумке Семантик веб мы должны описывать ресурсы (множество которых должно однозначно отображаться на множество всевозможных uri), но в нашем случае намного более удобно использовать хеши как своего рода уникальный идентификатор бинарных ресурсов. 2. Здесь ссылка на пункты «3.1 Добавление новой книги» «3.2 Добавление новой научной статьи» Конечно, функция добавления необходима, но очевидна, что я не должен (в хорошем случае, кончно). Добавлять каждую книгу, которая у меня и так есть на диске в разных форматах (.doc, .pdf, какайто никому неведомый формат) ручками, вписывать автора, если он не указан. Неееет. Я хочу щелкнуть два раза по semap и всё готово. «Текст это не бинарик», — крутилось у меня в голове предыдущие 5 минут. Нет, конечно, для текста можно применить огромное количество других подходов, которые не применимы для бинарных форматов. Но почему бы не применить для текста тоже самое, что предложено применить для bin. Вот о чем я. Скачал я книгу «Экстремальное программирование — разработка через тестирование (Кент Бек).pdf» Это отсканиная пиратская версия книги издательства «Питер». Ну пусть у кого-то эта книга тоже есть и он прикрепил к немножко semap-меты, будь то описание, заметки или что-нибудь ещё. Так вот теперь внимание вопрос? Какова вероятность того, что файл, в котором находится эта книга, отличается от моего. (Разная вероятность может быть, но для pdf-ов, пиратских книг и т.п. очень она маленькая, если кто-то уже отсканил или незаконно выложил книгу, то скорее всего она у всех и будет в таком формате). Это я к тому, что для файлов с текстами тоже вполне возможно вычислять хеши для легкого (и очень бысрого) обмена метаданными. Ну рассмотрим, даже такой случай, пусть сначало появился отсканиный вариант книги, а потом издательство решило выпустить нормальную качественную pdf-ку. в этом случае будем иметь 2 разных хеша: «e34Ert2rty6rtryh234777ty3434ERWe344rY» и «ewr324er45t6retgRrey4334fgd5Etw343ewe» Но когда semap сервер заметит, что у этих 2 хешей очень-очень похожую информацию дают пользователи, то он между ними просто установит связь и всё. Конечно, конечно, здесь найдутся исключения из правил. Но я и не предлагаю этим подходом покрыть абсолютно всё. Просто предлагаю, что когда пользователь будет добавлять semap мету к объекту, который представлен у него в виде файла на диске, считать хеш этого файла и ассоциировать мету и с этим хешем в том числе.

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

dulanov Я сам активно придумываю различные истории использования semap на практики как посредника. Есть вот такой пример. В заметке представлен библиографический сервис, который будет подкачивать метаинформацию с серверов DBLP, Amazon и пр. Также пользователи смогут для публикаций заводить цитаты, закладки, мысли и пр. Возможно даже обмениваться ими через другие сервисы. Лекго представить следующую ситацию. Мы скачали научную статью в pdf, пожкачали по названию метаданные с сервера DBLP и вставили цитату. Сразу же в MS Word при написании статьи мы сможем через макрос нажать кнопку вставить цитату и вставить её в документ. Ощущаете изменение принипа работы? А фича в том, что макрос смог получить доступ ко всем цитатам, заведенным на компьютере кем-то.

Для ответа включите в броузере поддержку JavaScript (средний уровень безопасности по умолчанию)