Browse by Tags

Google Knowlege Graph
21 мая 12 08:40

Прошла новость про то что Google запустили Knowledge Graph , базу понятий о людях, местах и многом другом интегрированную с поиском.

Это интересное явление и последствия покупки Гуглом проекта Freebase в котором как раз и появилась база состоящая из данных из многочисленных источников. Как я понимаю с тех пор базу существенно расширили и вычистили.

При том что технологически там те же технологии что и в Freebase, а то есть интегрированные в Semantic Web, но на поверхности ничего об этом не сказано. Вся сложность скрыта от посторонних глаз и пока непонятно повлияет ли это на распространение технологий среди разработчиков.

Postedfrom Иван Бегтин | 0 Comments    
Filed under:
DBPedia 3.7
11 сентября 11 02:38

Для тех кто интересуется не только открытыми данными, но и Linked Data (LOD2) будет интересно что вышла новая версия DBPedia.

В версии 3.7 множество улучшений и изменений о которых Вы можете прочитать подробнее в блоге проекта http://blog.dbpedia.org/2011/09/11/dbpedia-37-released-including-15-localized-editions/

Что немаловажно проект DBPedia в значительной степени спонсируется Европейским союзом через несколько программ поддержки Linked Data.

 

Originally published at Иван Бегтин. You can comment here or there.

Мои презентации с Social Camp’а
12 июля 11 10:28

Originally published at Иван Бегтин. You can comment here or there.

Публичная лекция в Киеве по открытым данным
21 декабря 10 02:35

Завтра в 19:00 я буду в Киеве выступать с лекцией про открытые данные и их важность – подробнее об этом мероприятии можно почитать тут – http://polit.ua/news/2010/12/16/begtin.html

Говорить я буду про то что такое открытые данные, их связь с открытым государством и многие другие связанные с этим явления. Я хочу также затронуть вопросы Semantic Web и Linked Data, но пока не очень представляю себе насколько аудитория будет готова к подобным понятиям.

Если есть какие-то вопросы, можно мне задать их заранее – я постараюсь их осветить в лекции.

Originally published at Иван Бегтин. You can comment here or there.

Онтология центральных органов власти
21 августа 10 11:54

Возвращаясь к моим рассуждениям об онтологиях АТД и онтологиях структуры органов власти рассмотрим, например, онтологию центральных органов власти.

О том как её можно промоделировать, уровнях сложности и так далее.

Для начала необходимо определить какие именно органы власти считать центральными и что в эту онтологию должно входить. Как я вижу главное и необходимое – в онтологию должны быть включены все организационные сущности упоминаемые в Конституции, такие как Президент, Правительство, Федеральное собрание, Счетная Палата, Генеральная прокуратура, Высшие органы судебной власти, Центральная избирательная комиссия. А также ряд органов имеющих федеральное значение – таких как как Совет Федерации. Возможно сюда же необходимо включить уполномоченных по правам человека и по правам детей.

Далее, как именно осуществлять моделирование. Ключевые вопросы здесь – это выстраивание иерархии и детальность описания.

Есть несколько подходов.

1. Подход простой

Моделирование производится по минимуму. Для каждого органа власти есть следующая информация:

- полное наименование

- краткое наименование

- официальный адрес

- официальный сайт

- контактный(-е) телефон(-ы)

- ФИО руководителя

- Полное наименование должности руководителя

- ссылка на вышестоящую структуру

- принадлежность к структуре

При этом такие органы власти как Администрация Президента и Правительство описываются включая организации входящие в их структуру – Министерства, Федеральные агентства и службы.

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

Минусы подхода.  Мы теряем множество связей не характеризующихся подчинённостью или вхождением органа власти в другой. Например, Счетная Палата хотя и образуется Советом Федерации и Государственной думой, нельзя однозначно сказать что подчиняется этим структурам. То же самое нельзя сказать с Генеральной Прокуратурой. Формально, в Конституции у нас прокуратура – это единая структура, а влияние Федерального Собрания распространяется только на избрание генерального прокурора.

Также, при таком подходе нет описания подробностей того чем занимаются отдельные органы власти.

При таком подходе, также, необязательно предварительное моделирование Конституционной онтологии, поскольку ссылки с описания госструктур на понятия закреплённые в конституционной онтологии необязательны.

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

2. Подход детальный

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

Кроме того в зависимости от типа госструктуры эта информация будет разной. А также в модели должны быть учтены совещательные и иные структуры не являющиеся органами власти.

Например, расширенная структура описания органа власти:

- название ведомства на английском языке;

- код ОКОГУ;

- код ГРБС, в случае если ведомство является ГРБС;

- ссылка на понятие в Конституционной онтологии, если там оно упоминается

- дата принятия указа о создании данного органа власти

- документ, определяющий факт создания органа власти – приказ, распоряжение, конституция

- реквизиты документа положения о данном органе власти: дата принятия, номер документа, ссылка на тип документа нормативно-правовой онтологии

- структурное описание положения о ведомстве включая:

– описание ведомства

– подведомственность другому органу власти

– перечень уровней власти и других органов с которыми данное ведомство взаимодействует (ссылками на объекты)

– список задач ведомства

– список функций ведомства

– список полномочий ведомства

- реквизиты юридического лица – ИНН, КПП, ОГРН, юридический адрес, если является юридическим лицом;

В случае Администрации Президента также описываются совещательные органы – Совет Безопасности, Государственный Совет, комиссии при президенте и советы при президенте включая следующую информацию:

- полное наименование совещательного органа;

- краткие сведения

- состав в формате: ФИО, Должность, статус в совете (комиссии)

- реквизиты и текст документа положения о совещательном органе включая: номер НПА, дата принятия НПА, текст НПА (структурный, с разбивкой по пунктам);

- основные задачи совещательного органа – каждая задача описывается отдельно со ссылкой на пункт положения;

- ссылка на сайт совещательного органа, если сайт есть

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

- ФИО вице-премьера;

- полная должность;

- перечень курируемых вопросов;

- перечень курируемых органов власти;

- перечень курируемых нац. проектов, федеральных целевых программ

В случае правительства, также, подробное описание координационных и совещательных органов, в основном это правительственные комиссии, а также Морская коллегия.

Для каждого органа описание включает:

- полное наименование

- реквизиты и текст документа положения о совещательном органе включая: номер НПА, дата принятия НПА, текст НПА (структурный, с разбивкой по пунктам);

- описание задач совещательного органа – текст и структурный перечень со ссылкой на пункты положения;

- состав органа включая: ФИО участника, статус участника в комиссии, должность участника;

- ссылка на сайт совещательного органа, если сайт есть

Примечание: Вообще именно с правительственными комиссиями большая проблема с доступностью информации об их деятельности. Данные на сайте правительства публикуются очень неравномерно, у некоторых комиссий есть свои сайты, например, у Морской Коллегии сайт есть ( http://www.morskayakollegiya.ru/), а у большей части других совещательных органов нет и информация об их деятельности представлена на сайте правительства и на сайте того органа руководит которым председатель этой комиссии.

Плюс структурное описание необходимо для таких органов как:

- Государственная дума – описание персон, комиссий, комитетов, фракций, партий.

- Совет Федерации – описание персон, комиссий, комитетов

- Счетная Палата, Прокуратура, Избирательная комиссия и так далее.

Отдельная большая тема в том как именно моделировать оргструктуру ведомств и как описывать отдельных персон. По хорошему, список персон надо выносить отдельно, делать ли это общим списком или же по разным органам власти отдельными – вот в чём вопрос. То есть, например, отдельно описывать персоны в статусе «депутат» и отдельно в статусе «чиновник».

Но, собственно, самое важное. Получается всего очень много, разьве что чуть меньше чем онтологии АТД, но с гораздо большей сложностью и числом связей.

Чем дальше тем более я думаю что онтологии органов власти также надо дробить на более малые и независимые. Отдельно онтология правительства, онтология АП, онтология Фед. собрания и так далее.

Originally published at Иван Бегтин. You can comment here or there.

Про онтологии АТД и базовые онтологии. Схемки
14 августа 10 01:25

Я тут набросал несколько схемок.

На первой –  онтологии госструктур/госуправления.

На второй – на третьей только геополитические онтологии

На третьей – функциональные онтологии административно-территориального деления.

Как всегда, делаю оговорку что под онтологиями я имею в виду декларативное описание той или иной предметной области в понятиях максимально приближенных к Semantic Web и Linked Data. А то есть это не просто смысловое разъяснение предмета, а его структурированное  описание.

Я эти схемки делал читая всё ту же книгу Кордонского и всей сложности государственного и административного устройства, они не показывают, но некоторое представление дают.

Собственно несколько комментариев:

1. По схемкам можно увидеть что базовая геополитическая онтология, а то есть декларативное описание структуры АТД России до субъектов – это основа основ. Собственно это то чем я ранее занимался и уже есть её OWL описание.

2. Второй ключевой онтологией является базовая нормативно-правовая онтология с описанием видов нормативных документов, их взаимосвязи и базовых правовых норм. Непосредственно на ней основана Конституционная онтология в которой и описываются основные центральные органы власти, их ответственность и функции.

3. В том что касается муниципального уровня я вывел его в отдельные геополитические онтологии субъектов федерации. При том что, да, можно, например, преобразовать справочники ОКАТО и ОКТМО в структурированное описание, однако, на мой взгляд информации в них недостаточно для полноценного описания отдельного муниципального образования. И, по хорошему, их надо сводить, также как и КЛАДР в RDF описании. Региональное деление также позволяет обеспечить итеративное моделирование, поскольку для моделирование органов власти в отдельном субъекте федерации достаточно отдельной только его геополитической онтологии региона.

4. Существует очень много функциональных онтологий основанные на структуре ряда федеральных органов власти и унаследованных от СССР делений. Часть их них охватывают только субъекты федерации, часть, особенно относящиеся к географическим и природным явлениям, завязаны на административное деление до уровня муниципальных образований. В каждом случае такой онтологии, она может содержать более сложную структуру и ссылки и свойства специфичные для данной отрасли.

Ещё одна осталась нераскрытая тема – это конвертация существующих справочников в декларативное описание. Делать ли на их основе, новые, правильные структуры, или же ссылаться на коды в этих справочниках и только.

Originally published at Иван Бегтин. You can comment here or there.

Онтология структуры органов власти – размышления
01 июля 10 12:43

Продолжу тему моделирования онтологий, под которыми я здесь и далее имеют в виду формализованное описание тематической области в форматах RDF/OWL.

Про онтологическое моделирование я где-то с год назад начал моделировать не только регионы, но структуру органов власти. Потом нашёл онтологию OEGov которую TopQuadrant делали по заказу GSA, проникся, промоделировал часть госструктур на ней. В итоге минусы плюсы перевесили и вот почему:

-  В OEGov очень много базовых понятий относящихся, в основном, к американской системе власти. А многие понятия схожие по написанию/звучанию отличаются от российских по ролям, полномочиям и т.д.  Например, агентства в России и в США – это два разных понятия, равно как и комиссии и не только.

- Я так и не разобрался как там можно моделировать нормативно-правовые документы и ссылаться на них. Даже если это предусмотрено, то весьма неудобно

- В принципе есть ощущение что очень много понятий, без достаточного числа объяснений что да как и почему.

Поэтому сейчас я думаю построением своей базовой онтологии. Но, как и OEGov состоящей и множества маленьких кусочков.

Эти кусочки будут следующими:

1. Базовая геополитическая онтология

Онтология с описанием структуры административно-территориального деления страны на субъекты и их группировки. А также классификационные и идентификационные коды

2. Базовая нормативно-правовая онтология

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

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

3. Конституционная онтология (онтология Конституции)

Основана на базовой нормативно-правовой онтологии и включает все статьи Конституции и основные понятия в ней определённые. Все статьи Конституции и понятия необходимые для моделирования других онтологий должны быть в ней определены.

4. Базовая онтология органов государственной власти

Основана на базовой геополитической онтологии и базовой конституционной онтологии. Определяет все классы необходимые для моделирования органов власти всех уровней и ветвей власти, которые также должны быть включены в онтологию. А также связаны с другими онтологиями. Например, в 10 статье Конституции определено разделение властей на законодательную, исполнительную и судебную. А значит что все эти ветви власти в онтологии органов власти, в терминах онтологии, являются конституционными понятиями и наследуются от класса ConstitutionTerm

5. Онтология центральных органов власти

Основана на: базовой геополитической онтологии, базовой нормативно-правовой онтологии, конституционной онтологии и базовой онтологии органов государственной власти.

В ней содержаться описания структуры Президента, правительства, ЦИК, Счетной Палаты, Банка России, Прокуратуры и всех остальных центральных органов власти и их территориальных подразделений.

6. Геополитические онтологии органов субъектов федерации

Основаны на: базовой геополитической онтологии

Для каждого из субъектов федерации моделируется по отдельности и включает описание всех муниципальных образований в рамках данного субъекта федерации.

7. Онтологии органов власти субъектов федерации

Основаны на: базовой геополитической онтологии, базовой нормативно-правовой онтологии, конституционной онтологии и базовой онтологии органов государственной власти, геополитической онтологии данного субъекта федерации.

Включают описание структуры органов власти в рамках одного из субъектов федерации с перечислением всех органов государственной и местной власти.

8. Базовая онтология бюджетных учреждений

Основана на: базовой онтологии органов государственной власти

Содержит все необходимые классы и понятия для описания государственных унитарных предприятий, государственных учреждений и иных госструктур не являющихся органами власти.

9. Онтология бюджетных учреждений федерального подчинения

Основана на: базовой онтологии бюджетных учреждений, онтологии органов государственной власти, базовой геополитической онтологии

Включает описания всех госучреждений федерального подчинения.

10. Онтологии бюджетных учреждений подчинения субъекта федерации

Основана на: базовой онтологии бюджетных учреждений, онтологии органов государственной власти, базовой геополитической онтологии, онтологии органов власти субъекта федерации, геополитической онтологии субъекта федерации

Описание всех госучреждения регионального подчинения.

11. Онтология подборок нормативно-правовых актов

Основаны на: базовой онтологии нормативно-правовых актов, конституционной онтологии, базовой онтологии органов государственной власти и онтологии центральных органов государственной власти.

Это подборка тематических онтологий по таким группам документов как:

- федеральные конституционные законы

- кодексы Российской федерации

- и другие группы документов.

И примерно такая схема

Я тут конечно ещё очень многое не упомянул, но, в общем-то я описывал только самые основные онтологии, фундамент для всех других.

Далее рассуждения вслух по разным вопросам.

Почему не сделать всё в одной системе/одном документе/единой онтологией? В основном по причине простоты локализации изменений. Их особенно много на уровне субъектов федерации и бюджетных учреждений.

Почему не сделать всё в виде Semantic Wiki? Потому как в Semantic Wiki удобно смотреть, но не моделировать. После завершения базовых онтологий их можно будет публиковать в виде Semantic Wiki или в формате DBPedia через OpenLink

Почему не сделать всё попроще? Потому как усложнять из простых структур сложнее чем получать простые выборки с помощью SPARQL. Простое моделирование есть, к примеру, в ГосСети, частично основанное на описанных здесь онтологиях.

Как быть с предметными онтологиями таких как госзакупки или госуслуги? Моделировать параллельно связывая с этими базовыми онтологиями

Как быть с персонами? Выносить их в отдельные онтологии и связывать с госонтологиями через промежуточные онтологии/базы.

Как быть с классификаторами? Предусматривать для них текстовые поля. Возможно, стоит подумать над преобразованием ключевых классификаторов в онтологии,

Честно говоря и с большим сожалением времени на моделирование у меня очень немного. В лучшем случае час в неделю, но, конечно, всё это очень интересно.

Originally published at Иван Бегтин. You can comment here or there.

Обновления российской геополитической онтологии (OWL)
01 июля 10 01:06

Если кто не помнит – ранее я размещал геополитическую онтологию тут http://ivbeg.livejournal.com/252756.html

Её суть – это построение на основе онтологии FAO (тут – http://www.fao.org/countryprofiles/geoinfo.asp) онтологии административно-территориального деления Российской Федерации с учётом всех её особенностей.

Тем кто не интересовался Semantic Web, Linked Data, возможно, разобраться в этом будет сложновато, но тем кто сталкивался – думаю что будет совсем несложно.

Сейчас и далее под «онтологией» – я буду иметь в виду описание предметной области в формате OWL файла.

В частности в эту онтологию входит:

- перечень всех субъектов федерации

- группировки субъектов по военным округам, экономическим районам и федеральным округам

- иерархии регионов и групп

- классификационные коды регионов по КЛАДР, ОКАТО, ОКТМО, ISO3166, ГОСТ7.67-2003

- временные зоны регионов, русские и английские названия и так далее

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

Что есть в новой версии:

- добавлен Северо-Кавказский федеральный округ и в него из Южного перенесены относящиеся к нему субъекты федерации

- новое свойство isMemberOfMunicipal используемое для формирование иерархии муниципальных образований

- теперь классы rural_settlement и urban_settlement переподчинены от municipal_district к municipal_formation. Это сделано поскольку городские и сельские поселения входят в муниципальные районы, а не наследуют от них свойства. А вхождение объектов управляется с помощью isMemberOfMunicipal

- для всех субъектов федерации заполнена информация о том с какими другими субъектами федерации они граничат. Это внесено в поля hasBorderWith

Саму обновлённую онтологию можно скачать в zip архиве тут – ruregions.zip

Плюс ещё один пример того как я предполагаю развивать онтологию далее – это описание структур административно-территориального деления в рамках субъекта федерации. А то есть перечень муниципальных образований. Классы для описания муниципальных образований есть в корневой онтологии regions.owl, а вот объекты в импортирующих её отдельных для каждого региона.

OWL файл архиве тут –  r87.zip.

И о том чего в этих онтологиях нет:

1. Кроме свойств наличия границ между субъектами в них нет никакой географической информации – такой как географические координаты, широты, параллели, территории, статистической информации и так далее. Нет по той причине что это базовые онтологии, а то есть все остальные строятся на их основе на них ссылаясь

2. Нет информации о границах  территорий с другими странами. В принципе, это сравнительно несложно сделать и было сознательно пока отодвинуто поскольку никогда не будет поздно добавить

3. Пока ещё неполное описание внешних территорий таких как Байконур, российские военные базы зарубежом и так далее. Скорее всего их описание также будет вынесено в отдельную ветку/онтологию.

4. Для городских и сельских поселений указываются два атрибута иерархии isMemberOf – отношение к субъекту федерации и isMemberOfMunicipal – вхождение в муниципальный район. Это создаёт некоторую избыточность, но упрощает некоторые выборки.

Собственно, что дальше. Я занимаюсь этими онтологиями, в основном, из личного интереса. У нас в России Semantic Web всё ещё в таком зачаточном состоянии что привлечь гранты или спонсоров для подобной работы – ну очень маловероятно.

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

Originally published at Иван Бегтин. You can comment here or there.

Техническое: Про NoSQL в ГосСети
11 июня 10 01:49

В сети идёт активное обсуждение нужен ли NoSQL или не нужен рекомендую почитать посты тут – http://zabivator.livejournal.com/412053.html и http://rainman-rocks.livejournal.com/120682.html.

Ещё один технический нюанс ГосСети (www.govweb.ru) в том что в проекте частично использует NoSQL, а точнее – базу MongoDB (www.mongodb.org).

К примеру, как устроен проект ГосСетью.

Есть публичный фронтэнд (www.govweb.ru) в котором публикуется информация о сайтах. Сам проект живёт на Django + MySQL. Это позволяет вести разработку предельно быстро и удобно, но и имеет ряд ограничений, например, в том что в подобной схеме неудобно хранить данные не имеющие четкой структуризации.

Поэтому были самые разные идеи – от использования Semantic MediaWiki, до адаптации или разработки движка аналогичного FreeBase (но это оказалось слишком дорогой задачей).  А Semantic MediaWiki хоть и выглядит соблазнительно, но вплане импорта/экспорта информации с ним нужно немало разбираться.

Однако вернёмся к NoSQL. Кроме, фронтэнда, отдельно от проектов и уже давно существует бэк-офисный непубличный движок и сервис который выдаёт для ГосСети следующие API методы:

  • извлечение данных из веб-страниц и сайтов: изображений, ссылок, объектов, метаданных и так далее
  • извлечение признаков из веб-страниц: определение CMS, технологий, счетчиков и так далее
  • получение, парсинг и классификация данных WHOIS
  • валидацию через W3C Validator
  • извлечение метаданных из веб-страниц
  • поиск RSS лент (для случаев когда RSS ленты не указываются в тэгах LINK)

и ещё несколько полезных инструментов.

Это такой SWISS Knife, но построенный на общем хранилище и на общих принципах. И хранилище это работает на том самом MongoDB. Почему именно так?

Причины в самом деле просты:

1. Удобство хранения

Практически все случаи когда из веб-страниц необходимо извлекать много разнородной информации приводят к тому что есть выбор. Либо сильно упрощать структуры, либо создавать множество таблиц по которым эти структуры распихивать.
Пример, из веб-страницы извлекаются: изображения, скрипты, метаданные, ссылки, формы. Для каждого из этих типов данных есть своё описание структур которые могут существенно отличаться. А в случае, например, форм – у них есть ещё и вложенные структуры в виде элементов форм которые, по хорошему, тоже надо хранить.
В случае если разносить все данные по отдельным таблицам, то, во-первых их наберётся не один десяток, а во вторых строить сложные запросы по таким таблицам означает заранее закладываться на планировщик СУБД.
Это как раз решается на уровне документо-ориентированных баз данных вроде MongoDB и CouchDB.
2. Легкость изменений структур
Второй плюс NoSQL в том что структуры данных легко меняются даже в тех случаях когда данных накоплено уже очень большое количество. Приведу конкретный пример. Прежде чем появился описанный мною выше сервис – где-то с полгода назад у меня работал небольшой краулер робот который собирал данные по Рунету и основным используемым в нём технологиям с сайтов. Всего в базе было и есть около сотни тысяч описаний сайтов.  Это миллионы скриптов, ссылок, метаданных и т.д.  и чтобы понять какие носители признаков пригодны для классификации, а какие нет необходимо многократно анализировать и менять структуры. Так вот делать это с использованием NoSQL гораздо проще.

3. Map/Reduce

Собственно, не упомянутое авторами – это Map/Reduce. Это одна из наиболее интересных, полезных и, в некотором смысле, удобных фишек многих NoSQL движков.

Я могу посоветовать почитать про Map/Reduce в Википедии http://en.wikipedia.org/wiki/MapReduce и добавлю что нужно это далеко не всем, а только тем кто работает со сравнительно большим объёмом данных.

Лично я использую Map/Reduce в MongoDB уже давно, просто-напросто мало времени чтобы писать о технологиях.

4.  SQL != фундамент разработки

Это вообще какое-то распространённое заблуждение что _способ работы с данными_ является неотъемлимой частью процесса разработки. Я могу лишь сказать, что у тех кто так действительно думает, по всей видимости, мало опыта в использовании других технологий. Например, такие движки как Metakit, BerkeleyDB, а также объектные и XML базы данных вполне себе давно существуют и активно используются. Я знаю несколько весьма серьёзных продуктов полностью построенных на BerkeleyDB.

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

Originally published at Иван Бегтин. You can comment here or there.

Postedfrom Иван Бегтин | 0 Comments    
OData: Open Data Protocol
29 марта 10 01:55


Оказывается Microsoft сделали и предложили протокол OData – Open Data Protocol используемый для раскрытия данных в машиночитаемой форме.

Подробнее можно почитать здесь http://www.odata.org

А вот его полное описание –
There is a vast amount of data available today and data is now being collected and stored at a rate never seen before. Much, if not most, of this data however is locked into specific applications or formats and difficult to access or to integrate into new uses. Public data is often unfortunately held private or needlessly buried behind random, inefficient, and cumbersome interfaces.

The Open Data Protocol (OData) provides a way to unlock your data and free it from silos that exist in applications today, making it easy for data to be shared in a manner that follows the philosophy of Open Data. OData enables a new level of data integration and interoperability across a broad range of clients, servers, services, and tools.

Это реально радует. Во первых сама спецификация протокола довольно проста и понятна, во вторых она без жёсткой привязки к сервисам MS.

А я тем временем всё больше понимаю что на OpenGovData.ru должны быть инструкции и разъяснения как именно надо публиковать информацию.

Originally published at Иван Бегтин. You can comment here or there.

Semantic Web for Dummies (Семантический Веб для Тупых)
15 мая 09 10:08

На Амазоне вышла книжка Semantic Web for Dummies написанная Jeffry Pollock автором Adaptive Information (Адаптивная информация)  которая меня лично подвигла ко многим размышлениям на тему природы и свойств информации, равно как и её самоценности. Я лично пока полистал то что можно посмотреть в открытом доступе и, хотя книжка для “Dummies”, интересного там должно быть много.

Кстати, Adaptive Information доступна и в книжках Google, хотя и не полностью, но достаточно для ознакомления.

Жаль в России книг по природе информации (не по алгоритмам или управлению знаниями), но именно по информации очень мало.

А эти книжки я лично добавил в свой список заказов на Amazon’е.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Postedfrom Иван Бегтин | 4 Comments    
Filed under: ,
OpenGovData. Спецификации раскрытия данных
09 мая 09 10:16

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

Скажу заранее - подготовка спецификаций и продумывание способов работы с данными проходили по принципу упрощения всего что только возможно и не вредит конечному результату. Определённым источником вдохновения была спецификация sitemaps которую не так давно начали использовать поисковые системы.

 

Спецификации

Итак, спецификация раскрытия данных, состоит из 3-х XSD схем:

И, для каждой из схем, доступна автоматически созданная документация:

 

 

Процесс импорта и экспорта данных

Теперь подробнее о том как с этими спецификациями будет происходить работа.

Фактически, вариантов работы с информацией два:

1. Данные подготовленные и загруженные на сайт opengovdata.ru

2. Общедоступные данные публикуемые на внешних ресурсах.

В первом случае описание источника данных производится внутри системы opengovdata.ru - технически это веб движок в котором можно заполнить все необходимые поля по данному источнику данных/массиву данных и который в итоге сформирует спецификацию источника в файла opendata.xml и присвоит зарегистрированному массиву данных постоянную ссылку permalink. Сами данные предварительно загружаются на сервер через HTTP/FTP/SFTP соответстветственно. 

Во втором случае данные источником данных является некий веб-сайт, например, если государственный орган или коммерческая компания желает сделать какие-либо свои данные общедоступными, то они подготавливают описание источника данных в виде файла opendata.xml с описанием массива и предоставляют его по некой постоянной ссылке на своём ресурсе. После чего регистрируют ссылку на описание источника данных на opengovdata.ru на специальной странице с указанием дублировать информацию или нет.

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

Все данные которые зарегистрированы в opengovdata.ru будут доступны для поиска по их описанию через в веб интерфейс, а в будущем и для поиска по самим данным.

Применение спецификаций

В сценариях работы системы выше у каждой спецификации есть своя роль.

  • opendata.xsd - используется для описания массива данных, включая описание полей, описание источника данных, описание организации ведущей данный источник информации, непосредственно сами данные или же ссылки на них. При этом данные могут предоставляться двумя способами:
    • включенными в описание массива данных - в этом случае данные описаны согласно спецификации в тэге table;
    • внешними источниками - в этом случае данные представлены в форматах: openDataXML, TSV, CSV, YAML, DBF и находятся во внешних файлах которые обнаружаемы по внешним ссылкам. Ссылки обязательно сопровождаются указанием типа данных и хэша рассчитанного по алгоритму SHA-512. Файлы данных могут также быть сжатыми с помощью Gzip - это должно определяться наличием у них расширения .gz (это сделано по аналогии со сжатием файлов sitemaps).
  • opendataxml.xsd - используется для унифицированного описания любых плоских табличных данных. Данный формат сознательно сделан предельно упрощённым и не несёт ничего кроме перечесления рядов таблицы и столбцов по каждому ряду. Фактически - это замена TSV формата, которая может быть удобна для некоторых систем которым из XML импортировать данные проще.  Цель этого формата представления данных не полнота описания, а унификация и простота последующей обработки.
  • opendataindex.xsd - используется для автоматизированной публикации открытых данных в виде индекса ресурсами готовыми их предоставлять. Например, сайт раскрывающий более одной базы данных может создавать сайт opendataindex.xml который, в свою очередь, зарегистрировать на сайте opengovdata.ru и при появлении новых массивов данных, они будут подтягиваться автоматически. В дальнейшем применение индекса открытых данных может быть через robots.txt (по аналогии с sitemaps) или же за счёт фиксированного имени файла в корне сайта, например, такого http://sitename.ru/opendataindex.xml 

Обновление информации в источниках

Данные представленные в описании массива данных (opendata.xml) могут присутствовать в двух формах:

 

  • статические неизменные данные
  • пополняемые данные.

 

Статические данные - это, фактически, данные которые уже собраны, зафиксированы и уже не будут меняться или пополняться. Например, к ним можно отнести какие-либо статистические данные за какой-либо уже прошедший временной период, а также редко изменяемые справочники по которым необходимо получать их последнюю редакцию, а не прошедшии версии.  При описании данных в спецификации opendata для статических данных используется тип full  в тэге tableref.

Пополняемые данные - это данные которые подвержены периодическому обновлению, ежедневному, еженедельному, по иному графику или по событию. К пополняемым данным можно отнести, например, статистические данные в развитии текущего периода или же данные реестров. 

В opendata для пополняемых данные используется указание типа initial в тэге tableref при первоначальной загрузке информации и при последующих обновлениях тип указывается в update, а также в атрибуте updateid  - указывается число возрастающее на единицу с каждым последующим обновлением. 

 

Особенности и ограничения

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

Например, пока отсутствует возможность структурированного описания доступных веб сервисов и не табличных, а иерархических данных которые не укладываются в текущую простую форму описания. Сейчас, единственное что сделано в спецификациях отражающее такие случаи - это возможность указания нестандарных спецификаций во внешних файлах. Для этого предусмотрен специальный тэг specref в котором указывается ссылка на спецификацию которая может быть хоть описанием в виде документа, а в поле format тэга tableref указывается тип документа отличный от TSV, openDataXML и так далее. 

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

Готовые данные

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

Также эти данные перечислены в индексном файле http://export.opengovdata.ru/opendataindex.xml

Разумеется, эти данные только начало, и далее они будут появлятся в структурированной форме в разделе сайта http://opengovdata.ru/opendata/ 

Текущий статус спецификаций и данных

Проект сейчас идёт маленькими шажками и цель спецификаций и первых размещаемых массивов не в том чтобы охватить все возможные случаи и все возможные типы структур данных, а в том чтобы начать эту работу, итеративно усложняя и развивая данные. 

Как можно помочь проекту?

Многие задают вопрос как можно помочь проекту, я перечислю многие возможные способы:

1. Можно подготавливать данные по спецификациям и направлять их на публикацию в OpenGovData. Это можно сделать, например, через сообщество в Google Groups - http://groups.google.com/group/opengovdataru.

2. Можно участвовать в обсуждении спецификаций, выступая с конструктивными критикой и предложениями по развитию стандартов. Со временем я надеюсь что описания будут детализированы и представлены в виде более подробного документа чем то что я описываю сейчас.

3. Для государственных органов и других владельцев общедоступных данных можно начать публиковать данные на государственных сайтах в форматах и, далее, регистрировать массивы данных в реестре данных opengovdata.ru . 

4. На законодательном уровне - проведение в Российское законодательство нормы по обязательному наличию структурированного описания в случае любых требований по публичности размещаемых данных. Я объективно понимаю что это займёт годы, но если этого не делать, то не годы, а десятилетия.

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

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Guardian Open Platform - доступ к базе новостей
12 марта 09 10:56

В Guardian, британской газете, анонсировали открытую онлайновую платформу через которую можно получить доступ к их материалам - http://www.guardian.co.uk/open-platform 

Посредством API они отдают данные и дают доступ в некоторые из своих медиа-массивов, с примерами доступа на Python, Ruby, PHP, Java. 

Фактически, что я лично наблюдаю, Guardian идёт тем же путём что и New York Times которые о своих API пишут уже давно http://open.blogs.nytimes.com/tag/api/

и Thompson Reuters которые поддерживают OpenCalais - http://www.opencalais.com/

Так же стоит отметить BBC API - http://www0.rdthdo.bbc.co.uk/services/api/  не столь интересное как остальные, но имеющееся как факт (появилось оно, кстати, в 2005 году, 3.5 года назад).

А вот наши новостные агенства с такими сервисами совершенно не спешат.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Postedfrom Иван Бегтин | 0 Comments    
Сообщество Semantic Web в Google Groups
11 декабря 08 01:29
Дмитрий Дуланов ( http://dulanov.wordpress.com ) открыл в Google Groups сообщество Webofdata.ru где обсуждаются вопросы Semantic Web, переводы статей по тематике и анонсов русскоязычных проектов. Тем кто активно интересуется данной темой или работает Read More...
Postedfrom Иван Бегтин | 0 Comments    
Filed under: ,
Ссылки на 9.12.2008. Semantic Web
10 декабря 08 11:08
Dog Food Papers - большая подборка материалов, статей и презентаций по Semantic Web How To Tell Stuff To A Computer - разъяснения принципов Semantic Web для чайников и детей Публикация данных для Semantic Web посредством PHP с примерами Headup - расширение Read More...
Postedfrom Иван Бегтин | 0 Comments    
Filed under: , ,

This Blog

Tags

Archives

Syndication