Иван Бегтин

В сети идёт активное обсуждение нужен ли 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. Удобство хранения

3. Map/Reduce

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

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

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

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

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

—

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

В Cnews вышла статья про ТК22 – http://www.cnews.ru/news/top/index.shtml?2010/05/21/392272

в том числе и с моими комментариями.

Я кстати, склонен согласится тут с Ольгой Усковой – вероятность что стандарты разработанные в ТК22 будут использоваться в требованиях по госзакупкам совсем ненулевая. В этом случае интерес Майкрософт вполне себе понятен – они могут продвигать там OpenXML и OData, да и другие свои стандарты.

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

Далее начинается нормативно-правовое закрепление стандартов в виде требований в конкурсной документации.

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

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

Появился исходный код Gridworks – http://code.google.com/p/freebase-gridworks/ , а также всяческие интересные примеры там же, в Wiki проекта. Этой такой инструмент по очистке и преобразованию данных сделанный внутри Metaweb’а, компании разработчика проекта Freebase.

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

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

Буквально сегодня  Александр Пироженко, руководитель Департамента по развитию конкуренции и анализу конъюнктуры цен у себя в блоге написал про то что вышел доклад по ценам в 2009 году.

Процитирую:

Вчера из типографии доставили свежий и красивый «Доклад по ценам в 2009 году. Стабилизация под воздействием спроса и конкуренции». В количестве 500 экз. Наконец-то мы сделали его! Мне нравится – получилось то, что задумывалось – профессионально, симпатично и доходчиво (надеюсь).

и проиллюстрирую

И всё бы хорошо, и графики красивые, и даже фотография министра есть. Вопрос в другом – а есть ли от этого польза?

Мой комментарий в блоге Александра находится тут: http://alex-pirojenko.livejournal.com/39024.html?thread=268656#t268656

А в этом посте я этот комментарий продублирую:

Александр, во всём мире сейчас идёт движение за раскрытие данных в форме пригодной для повторного использования чтобы любой мог загрузить их в Excel или иной удобный инструмент и самостоятельно проанализировать, сопоставить, отрисовать и так далее. А Вы вместо этого рисуете красивые буклеты с графиками. Да они посимпатичнее чем если их просто отрисовать в Excel’е, но вот только почему меня не покидает уверенность что пользы от этой информации было бы на порядок больше опубликуй Вы её в Excel, XML, CSV или ином пригодном для работы формате.

Я Вам больше скажу – была бы первичная информация доступна, можно было бы хоть конкурс устраивать по аналогии с Design for America и получить графики не худшего качества, а скорее всего из-за _конкуренции_ между инфодизайнерами, то и лучшего качества.

Честно говоря стыдно, Александр, за Ваше ведомство.

—

При том что МЭР это далеко не самое закрытое наше ведомство, но есть огромная разница между тем и в какой форме предоставлять информацию – гражданам, экспертам, специалистам. Есть большая разница в публичной машиночитаемой доступности информации и графиками.

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

Если кто-то со мной несогласен, приглашаю прокомментировать у меня в блоге. Если согласны – предлагаю написать комментарием к посту Александра что хорошо бы эти данные раскрыть публично, в Интернете и в формате пригодном для последующего использования. А те кто отрисуют на основе их красивые графики найдутся.

В Гослюдях много небольших, но заметных обновлений. Целиком приводить не буду, лучше почитать на Полит.Ру тут – http://www.polit.ru/country/2010/03/30/goslyudi.html

Остановлюсь же на главном. Итак что нового:
1. Появились разделы фото www.goslyudi.ru/photos и видеоленты — www.goslyudi.ru/video/ где размещаются последние видео и фотографии из блогов гослюдей. В каждом из разделов есть есть RSS лента для подписки.

2. Появилась страница с перечнем всех RSS лент, экспортируемых из Гослюдей.Ру — www.goslyudi.ru/export/.

3. Появился антирейтинг «лист позора» государственных блоггеров www.goslyudi.ru/shame/. В него входят только «псевдо-блоги», когда гослюди неправильно трактуют само понятие блога и вместо него создают очередной сайт.

Про антирейтинг всё практически наверняка будет понятно из разъяснений на Полит.Ру и на сайте Гослюдей, я же добавлю что в антирейтинге собраны совсем уж вопиющие случаи серьёзного непонимания у государственных служащих что такое блог и с чем его едят.
Это то что называется деятельная критика – критерии которые мы использовали при оценке самоочевидны и если хоть кто-то из попавших в рейтинг их прочитает и изменит свой блог в соответствии
с тем что там написано, то, конечно, мы будем только рады.

И ещё одно дополнение. В антирейтинг включены только те блоги записи которых не попадают в Гослюди.Ру потому как на самом деле блоговости в них одно название.

Вот так.

Игорь Артамонов буквально вот-вот запустил сайт http://www.datasetpublisher.com/ где будут публиковаться torrent’ы открытых данных которыми бы хотелось поделиться и которые хотелось бы скачать.

Пока данных там немного, но уверен что будет больше нашими совместными усилиями.

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

Например, все данные из OpenGovData.ru я планирую публиковать через этот трекер.

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

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

Но, вернёмся к кодам – что это такое и как они есть. Буду приводить примеры:

• 049205770 – пример кода БИК – банковского идентификационного кода
• 02.03.1989 – пример записи даты в формате dd.mm.yyyy, где dd – день, mm – месяц, yyyy – год от рождества Христова
• ru.wikipedia.org – пример кодирования адреса в виде домена
• 09808117 – пример кода ОКПО,  общероссийского классификатора предприятий и организаций
• 5460000016 – пример кода ИНН. Идентификационного номера налогоплательщика
• 65.12, 65.22.5 - примеры кодов ОКВЭД
• 30401810701200001022 – пример кода корреспондентского счета банка в ЦБ РФ
• ALMZRU8Y – пример кода S.W.I.F.T используемого банковскими организациями
• ГОСТ Р 52980-2008 – пример кода в виде документа ГОСТ
• 454091 – российский почтовый индекс
• 359 – код по общероссийскому классификатору единиц измерения (ОКЕИ) означающий «сутки».
• NO93 8601 1117 947 – международный номер банковского счета, в примере номер счета в банке Норвегии
• 13001 – код правительства Российской Федерации по справочнику ОКОГУ
• 1021600000256 – пример общероссийского государственного регистрационного номера, ОГРН, присваеваемого юридическим лицам.
• ГС-1-50-02-26-0-7709342342-013097-1 – пример номера лицензии на проектирование зданий и сооружений
• 08050 – код улицы «Зелёный проспект» по общемосковскому классификатору улиц

плюс сюда же можно добавить такие коды как: номера банковских карт, автомобильные коды VIN, телефонные номера, коды ISBN, MAC адреса сетевых карт, IP адреса, коды EAN-8, EAN-13, GS-128, DUNS номера организаций в США и многие и многие другие.

Суть же всегда одна – кодирование информации об объектах, это способ решения следующих задач:

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

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

Continue reading «Онтология и примеры анализа кодов и идентификаторов»

Недавно обнаружил в блоге у Mencius Moldbug довольно интересное мнение про Wolfram Alpha. Жаль не прочитал его ранее, там есть целый ряд интересных мыслей.

Но, пожалуй, одна из самых интересных в предсказуемости результатов в WA. Фактически он назsвает Wolfram Alpha – «control interface» и сравнивает с Google который таким не является поскольку результат выдачи Google не предопределён.

Это как со школьным и многим другим навязанным образованием – отсутствует в WA разнообразие мнений, несколько точек зрения и, фактически, Wolfram Alpha сейчас это такой особо умный словарь / энциклопедия где вся разница с классическими энциклопедиями в том что в WA гораздо больше источников информации.

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

Кстати, ещё одно интересное наблюдение на сайте Wolfram Alpha нет упоминаний про Semantic Web, онтологии и так далее, хотя, на самом деле, там данные из Semantic Web и Linked Data используются и внутри есть онтология.

Причина проста, RDF, SPARQL, OWL, Semantic Web и прочая – это всё довольно сложные технологии для даже для подготовленного пользователя. Так порог вхождения для изучения SQL и SPARQL довольно существенен и многие проекты используют свои, сильно упрощённые языки запросов чтобы минимизировать заведомую сложность.

Но причина не только в этом. Для построения подавляющего большинства частных коммерческих задач использование RDF или Triple Store – это оверкилл и более простые и дешёвые решения подходят лучше. Иначе говоря для проектов на базе Sematic Web до сих пор нет рынка и тем более его нет в России и большой вопрос будет ли.

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

P.S. Постоянно сталкиваюсь с тем что когда путают «семантические технологии» и «семантический веб». Первое – это, по сути, мат. лингвистика и анализ текстов, к RDF и онтологиям имеет слабое отношение.

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

В результате посмотрел на LangId.net и AlchemyAPI и там и там одна и та же ерунда – до половины всех русскоязычных документов определяются как вьетнамские.

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

Понятное дело что сервисных и утилитарных API для Рунета и русского языка в частности практически нет. Разьве что вот Яндекс стал предоставлять http://api.yandex.ru/speller/, но это капля в море.

А кто знает какие-либо полезные онлайн API, применимые к Рунету, русскому языку и распознаванию текста?

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

1. Уровень тэга (tag level)

Эта метрика определяет вложенность тэга в общем дереве и рассчитать его возможно двумя способами:

– пройдясь по всему дереву тэгов и назначив номер уровня каждому элементу

– рассчитав его обратившись к вышестоящим тэгам от данного.

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

Зачем эта метрика нужна? Для того чтобы определить группы похожих элементов находящихся на одном уровне. Например, это позволяет выявить меню сайта и иные блоки ссылок. Например, практически все блоки SEO ссылок содержат одноуровневые элементы и даже если они разбиты на несколько подблоков по 3-4 ссылки в каждом, тем не менее уровень ссылок всегда тот же.

Другое применение это эта же метрика используется мною в Скиуре при выявлении повторяющихся новостных блоков.

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

2. Сдвиг тэга (tag shift)

Определяет  позицию тэга в списке потомков его родителя.  Фактически – это ответ на вопрос «сколько тэгов от такого-то надо отсчитать чтобы найти нужный».

Эта метрика используется при сравнении отдельных тэгов и их групп и для определения типовых последовательностей. В алгоритме  Скиура с помощью tag shift выявляются новости не выделенные в отдельные блоки, а публикуемые как чередующиеся последовательности тэгов

Continue reading «Немного о глубоком анализе HTML»