Связанные данные
Тема в разделе "Общая дискуссия", создана пользователем Парфентьев Михаил Владимирович, 01.04.2014
01.04.2014

В данной ветке форума обсуждаются вопросы, связанные с Linked data (связанные данные).

В дальнейшем представляется рациональным составление общего списка рекомендаций при создании rdf-файлов и процесса связывания данных.

В качестве иллюстрационного материала рассмотрим следующий набор открытых данных - http://www.economy.gov.ru/wps/wcm/connect/economylib4/designelements/ope...

Задача состоит в переводе исходного csv-файла в rdf с целью последующей визуализации, попытке связать набор с внешними источниками информации (в том числе другими наборами открытых данных).

 

 

 

___________________________________________________________________________________

Информация, размещаемая далее, не является истиной в последней инстанции, предоставлена в качестве отправных точек для развития последующей дискуссии

{необходимо сказать несколько слов о системе обращения к последней вресии файла}

каким образом лучше реализовать доступ к актуальной версии файла набора ОД?

Пример

1 марта:
http://test.ru/opendata/data-20140301-structure-20140301.xml
1 апреля:
http://test.ru/opendata/data-20140401-structure-20140301.xml
последняя версия:
http://test.ru/opendata/data
последняя версия с определенной структурой
http://test.ru/opendata/data-structure-20140301

Таким образом, http://test.ru/opendata/data = http://test.ru/opendata/data-20140401-structure-20140301.xml = http://test.ru/opendata/data-structure-20140301

{каким образом происходит обращение к элементу rdf-файла}

Пример

File url: http://test.ru/opendata/data123.xml
Object url: http://test.ru/opendata/data123.xml#id-1 - обращение к первому объекту (у каждого объекта должен быть уникальный идентификационный номер, в противном случае - обращение к первому элементу с запрашиваемым идентификационным номером) с идентификационным номером id-1

Практика

http://dublincore.org/documents/dcmi-terms/#terms-audience - обращение к элементу с id="terms-audience"

<tbody id="terms-audience" class="term" resource="http://purl.org/dc/terms/audience"> - строка в rdf файле

 

{Визуализаторы rdf графов - отдельная подтема}

Kuznetsov Denis Kuznetsov Denis's picture
Registered:27.03.2014
02.04.2014

Проблемы обнаруженные в ходе исследования RDF формата и конвертирования набора "Торговые представительства Российской Федерации за рубежом" (http://www.economy.gov.ru/wps/wcm/connect/economylib4/designelements/opendata/tplist) министерства экономики

1) Отсутствие реальных IRI торговых представительств министерства экономики РФ.
Тэг rdf:Description по логическому смыслу не является определяющем объект тегом, и всего лишь добавляет свойства к уже существующему объекту. Объект может быть объявлен только конкретной существующей страницей (для примера пусть будет страница - http://example.com/foo) или же тегом с атрибутом "id" (для примера пусть будет следующее значение атрибута - "bar") на уже существующей страницей. И в том и в другом случае объект имеет свой собственный IRI, в первом случае - http://example.com/foo, во втором случае - http://example.com/foo#bar. При конвертировании набора министерства экономики из CSV в RDF выявилась проблема, IRI торговых представительств министерства экономики РФ не существуют. Их просто нет, нигде. Они нигде не указаны компетентными организациями, а значит неизвестно какие IRI указывать при описании объектов RDF. Конечно можно использовать относительные IRI или не использовать IRI вообще. Об этом подробнее в возможных решениях проблемы.

Возможные решения этой проблемы в первую очередь основаны на том какой тип IRI торгового представительства будет использоваться. Возможные варианты:
1. Создание и использование абсолютных IRI (более привлекательный вариант). Необходимо создать официальные персональные веб-страницы под каждое торговое представительство на сайте министерства экономики или создать страницу с перечнем торговых представительств, где будет определен объект под каждое торговое представительство. И в дальнейшем использовать эти IRI в качестве официальных от министерства экономики РФ.
2 Создание и использование относительных IRI (менее привлекательный вариант). Необходимо определить объекты торговых представительств через атрибут "id" внутри этого же набора. Этот метод предполагает, что кроме описывающих объект тегов rdf:Description в наборе должны быть использованы определяющие объект теги (вопрос о том какие теги правильнее всего использовать при определении объекта пока не изучен). Данный метод несет за собой следующие проблемы:
- остается непонятным вопрос идентификации объектов, так как в изначальном CSV наборе не указан ни один параметр, который мог бы послужить идентификатором, то остается только порядковая идентификация, которая влечет дополнительные трудности при добавлении и удалении элементов набора.
- вся идентификация объектов является относительной от файла набора, поэтому изменение URL хранения файла набора, автоматически изменяет IRI объектов, и поэтому старые связи из других наборов становятся недействительными.
- дублирование объектов при создании следующей версии набора, так как и старый, и новый файл будут содержать в себе объекты, то получается один и тот же объект будет представлен в разных версиях набора разными IRI, и тогда не понятно на какой ссылаться. Если ссылаться на новую версию, то через некоторое время она станет устаревшей версией и связи станут не актуальными. И чтобы актуализировать связи нужно будет изменить все внешние наборы, которые ссылается на этот набор.
3. Отказ от IRI вообще. (малополезный вариант). Можно обойтись использованием абстрактными объектами через атрибут rdf:nodeID, который позволяет опустить использование атрибута rdf:about. Но тогда по сути это будут "бесхозные" объекты на которые нельзя ссылаться из внешних наборов, а значит они не могут быть использованы в системе Linked Data, что делает подобный набор в формате RDF не полезнее набора в формате CSV.

Вывод: использование относительных IRI крайне нежелательно, так как это влечет за собой очень много проблем, которые не могут быть решены в текущих условиях, и может быть только временным/переходным решением, а неиспользование IRI вообще не перспективно. Министерство экономики должно предоставить официальные IRI торговых представительств, которые потом можно будет использовать как в самих наборах министерства экономики, так и во внешних наборах, которые будут ссылаться на наборы министерства экономики для создания Linked Data.

2) Неподготовленные данные в наборе министерства экономики.
При конвертировании использовались данные в формате CSV и эти данные были скомбинированы нежелательным образом, не так как это принято делать согласно онтологии в RDF. Например: имя, фамилия и отчество занесены в одну колонку, а для RDF их правильнее разбить по разным полям; почтовый адрес должен быть точно также разделен на страну, регион, город, адрес и почтовый индекс.

Возможные решение этой проблемы:
1. изменение формата выгрузки исходных данных в формате CSV для последующей правильной конвертации в RDF.
2. ручная обработка текущего CSV файла (а также всех последующих версий CSV).

...) Перечислены не все проблемы.

16.04.2014

UnifiedViews: An ETL Framework for Sustainable RDF Data Processing
Подробнее: http://www.comsode.eu/index.php/2014/04/unifiedviews-an-etl-framework-for-sustainable-rdf-data-processing/

06.05.2014

http://habrahabr.ru/company/yandex/blog/221881/ статья, посвященная стандартам и синтаксису микроразметки. Интересным является (особенно в рамках темы связанных данных) - JSON-LD

27.03.2015

В АИС "Мониторинг Госсайтов" рассчитывается, в том числе, экспертный рейтинг открытых данных.
В данной заметке хочется поговорить об одном из параметров, а именно "Наличие уникальных идентификаторов полей (для связывания данных)".
Данный параметр оценивается экспертами по таким критериям как наличие, полнота и актуальность.

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

О каких уникальных идентификаторах записей идет речь?
Уникальный идентификатор, прежде всего, зависит от информации, содержащейся в наборе открытых данных. Так, например, когда в наборе содержится информация по тематике, предполагающей наличие единого (международного или всероссийского) классификатора или справочника его указание является очень ценным для реализации дальнейшего связывания данных.

В качестве небольшого примера можно вспомнить об уникальных обозначениях названий аэропортов. Таким образом, представим у нас есть набор открытых данных с информацией об аэропортах России. В данном случае уникальным идентификатором Внуково будет атрибут VKO (в классификации IATA) или UUWW (в классификации ICAO). Какой из классификаторов следует указывать в наборе? При ответе на данный вопрос следует руководствоваться правилом "чем больше, тем лучше".

А какие государственные справочники и классификаторы знаете-используете вы?

a mariak katosvich a mariak katosvich's picture
Registered:25.07.2016
25.07.2016

Министерство экономики должно обеспечить офисы официальных продаж IRI, которые затем могут быть использованы как в наборах Министерства экономики и внешних множеств для создания Linked Data..The использование относительных IRI крайне нежелательно, так как это влечет за собой много проблем, которые не могут быть решены в текущей среде, и может быть только временным / переходное решение, и неприменение IRI не перспективны.

Thanks,
Maria.K

 

19.01.2017

Коллеги, добрый день!

На каком портале (муниципальном, региональном,федеральном) открытых данных РФ реализованы связанные данные? 

22.06.2018

Проблемы обнаруженные в ходе исследования RDF формата и конвертирования набора "Торговые представительства Российской Федерации за рубежом" (http://www.economy.gov.ru/wps/wcm/connect/economylib4/designelements/ope...) министерства экономики

1) Отсутствие реальных IRI торговых представительств министерства экономики РФ.
Тэг rdf:Description по логическому смыслу не является определяющем объект тегом, и всего лишь добавляет свойства к уже существующему объекту. Объект может быть объявлен только конкретной существующей страницей (для примера пусть будет страница - http://example.com/foo) или же тегом с атрибутом "id" (для примера пусть будет следующее значение атрибута - "bar") на уже существующей страницей. И в том и в другом случае объект имеет свой собственный IRI, в первом случае - http://dhd.by, во втором случае - http://gotovim.by. При конвертировании набора министерства экономики из CSV в RDF выявилась проблема, IRI торговых представительств министерства экономики РФ не существуют. Их просто нет, нигде. Они нигде не указаны компетентными организациями, а значит неизвестно какие IRI указывать при описании объектов RDF. Конечно можно использовать относительные IRI или не использовать IRI вообще. Об этом подробнее в возможных решениях проблемы.

Возможные решения этой проблемы в первую очередь основаны на том какой тип IRI торгового представительства будет использоваться. Возможные варианты:
1. Создание и использование абсолютных IRI (более привлекательный вариант). Необходимо создать официальные персональные веб-страницы под каждое торговое представительство на сайте министерства экономики или создать страницу с перечнем торговых представительств, где будет определен объект под каждое торговое представительство. И в дальнейшем использовать эти IRI в качестве официальных от министерства экономики РФ.
2 Создание и использование относительных IRI (менее привлекательный вариант). Необходимо определить объекты торговых представительств через атрибут "id" внутри этого же набора. Этот метод предполагает, что кроме описывающих объект тегов rdf:Description в наборе должны быть использованы определяющие объект теги (вопрос о том какие теги правильнее всего использовать при определении объекта пока не изучен). Данный метод несет за собой следующие проблемы:
- остается непонятным вопрос идентификации объектов, так как в изначальном CSV наборе не указан ни один параметр, который мог бы послужить идентификатором, то остается только порядковая идентификация, которая влечет дополнительные трудности при добавлении и удалении элементов набора.
- вся идентификация объектов является относительной от файла набора, поэтому изменение URL хранения файла набора, автоматически изменяет IRI объектов, и поэтому старые связи из других наборов становятся недействительными.
- дублирование объектов при создании следующей версии набора, так как и старый, и новый файл будут содержать в себе объекты, то получается один и тот же объект будет представлен в разных версиях набора разными IRI, и тогда не понятно на какой ссылаться. Если ссылаться на новую версию, то через некоторое время она станет устаревшей версией и связи станут не актуальными. И чтобы актуализировать связи нужно будет изменить все внешние наборы, которые ссылается на этот набор.
3. Отказ от IRI вообще. (малополезный вариант). Можно обойтись использованием абстрактными объектами через атрибут rdf:nodeID, который позволяет опустить использование атрибута rdf:about. Но тогда по сути это будут "бесхозные" объекты на которые нельзя ссылаться из внешних наборов, а значит они не могут быть использованы в системе Linked Data, что делает подобный набор в формате RDF не полезнее набора в формате CSV.