Просмотр кода страницы Выработка механизмов присвоения постоянных идентификаторов (URI) для ОСД

== Определение ресурса и присвоение URI ==

'''Вводные сведения'''

Рекомендаций по присвоению URI в LOGD было издано достаточно много.

Вот этот документ Еврокомиссии [http://philarcher.org/diary/2013/uripersistence/] даже содержит обзор ряда других. Однако далеко не всех: в частности, потому что многие были изданы позже, или не выражали согласия с отдельными положениями документа, или и то, и другое.

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

'''Принцип первый'''

Не следует перегружать URI семантикой.

Довольно часто любят перегружать URI следующим:

- сведениями о провенансе — в частности, о некоем «датасете», к которому URI «принадлежит»;
- подробными сведениями таксономического характера.

Возможно, эти антипаттерны пришли из мира REST API, или, может быть, они действительно имеют смысл при определенных способах доступа к данным. Однако при доступе посредством SPARQL подробные таксономические сведения точно не нужны. Для выражения провенанса есть свои средства.

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

'''Принцип второй'''

Следует избегать использования «/» в качестве условно-разделительного знака.

Использование «/» приведет к необходимости либо потом без конца экранировать этот «/» в сокращенных префиксных формах (например, писать ''fssp:agency\/03000''), либо заводить массу префиксов и в них путаться (''fssp_agency:'', ''fssp_person:'' и пр.).

Вот пример [https://stackoverflow.com/a/35657702/7879193] того, как гражданин UK, разбирающийся в технологиях, запутался в URI, составленных с нарушением этого принципа.

'''Принцип третий'''

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

Да, это до известной степени противоречит принципу «do not state ownership». Однако, к сожалению, домены ФОИВ — самое надежное, что у нас сейчас есть.

- Типовая ситуация смены домена ФОИВ решается использованием нами дополнительной прослойки в виде идентификаторов w3id.org [http://w3id.org/].
- Типовая ситуация расформирования ФОИВ — до известной степени тоже, но кроме того, URI должны быть переносимыми между доменами. В ряде случаев при расформировании ведомства и передаче полномочий действительно правильнее говорить об образовании новых сущностей.

Распространенной практикой является соответствие домена некоему сектору общественной жизни, являющемуся сферой государственного регулирования. К сожалению, здесь есть ряд проблем.

1. Такая секторизация — тоже разновидность владения. Не очень понятно, допустим, куда отнести военные прокуратуры: в jus или в bellum.
2. Головного домена под эти секторные поддомены у нас все равно нет. Если бы и был, это означало бы централизацию, что в отечественных условиях имеет всем известные последствия. Даже если выносить отечественные условия за скобки, децентрализованность и распределенность лежат в основе идеологии Semantic Web.

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

От принципов секторности и «do not state ownership» в силу причин, примерно совпадающих с описанными, отказались, например, США, Канада и отчасти Нидерланды [http://www.pilod.nl/wiki/Bestand:D1-2013-09-19_Towards_a_NL_URI_Strategy.pdf] (документ по ссылке вообще хорош).

'''Схема именования'''

Исходя из сказанного выше, вырисовывается схема именования, поясняемая приводимыми ниже гипотетическими URI. Или IRI, но поддержка IRI популярным программным обеспечением, да даже и стандартами, достаточно ограничена.

- http://нси.фоив.рф/школа_780036 [http://нси.фоив.рф/школа_780036]
- http://ref.foiv.gov.ru/school_780036 [http://ref.foiv.gov.ru/school_780036]
- http://lod.foiv.gov.ru/school_780036 [http://lod.foiv.gov.ru/school_780036]

Таким образом, URI будет состоять из следующих фрагментов:

- http:// — протокол. Здесь мы будем принуждены выбирать схему, принятую владельцами целевых доменов (у кого-то это http, у кого-то https). Для справки: Тим Бернерс-Ли был против [https://www.w3.org/DesignIssues/Security-NotTheS.html] https. Вообще, имеется дискуссия об использовании https в Semantic Web (1 [https://www.w3.org/blog/2016/05/https-and-the-semantic-weblinked-data/], 2 [https://pdfs.semanticscholar.org/7ab8/12ba3d0e8f3ff7dc5170cee37d2ccb441e09.pdf], 3 [http://www.unicse.org/publications/2010/november/Making%20secure%20Semantic%20Web.pdf], 4 [https://lists.w3.org/Archives/Public/semantic-web/2017Jul/thread.html#msg42]).
- нси, ref или lod — поддомен, поддерживать который мы намерены обязать ФОИВы. Первые два варианта названия поддомена хороши при понятном ФОИВ позиционировании LOGD как некоей всероссийской справочной.
- foiv.gov.ru [http://foiv.gov.ru/] или foiv.ru [http://foiv.ru/] — домен ФОИВа.
- school — типа объекта, лучше максимально конкретный. В целях переносимости URI желательно, чтобы в различных доменах не встречалось одинаковых обозначений типа объекта.
_ — условно-разделительный знак.
- 780036 — естественный уникальный ключ, в данном случае образованный конкатенацией условного номера региона и номера школы, дополненного слева нулями.

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

Значит, URI принимает следующий вид:

http://lod.foiv.gov.ru/resource/school_780036
Вместо /resource может быть ''class/'', ''property/'' или ''dataset/''.

'''Ограничение предлагаемой схемы'''

Схема может оказаться не вполне применима в следующих случаях:

- для URI классов и свойств в данных с развитым TBox;
- для разного рода «показателей» (в статистике, публикуемой с использованием RDF Data Cube, сюда же отношу всевозможные финансовые данные);
- при публикации URI, которые в силу каких-либо причин заведомо не будут «индивидуально дереференсируемыми», здесь лучше использовать «#», а не «/».
- при публикации LOGD регионами.

В последнем случае, мне кажется, вполне возможно ограничиться использованием федеральных URI, никаких собственных реестров чего бы то ни было у регионов нет. У муниципалитетов, быть может, есть, но вряд ли у них есть технические возможности для публикации LOGD. Регион мог бы публиковать муниципальные данные, но тут нужна инвентаризация: а стоит ли оно того?

'''Персистентность'''

В качестве обертки над URI в доменах ФОИВ предлагается использовать URI из w3id.org [http://w3id.org/].

В этом домене будут расположены «абстрактные» «неизменные» URI, в доменах ФОИВ — «изменчивые» «конкретные».

Средствами веб-сервера Apache при обращении к абстрактным URI будет производиться перенаправление на конкретные.

Соответствие конкретных URI абстрактным прописывается в конфигурационных файлах Apache, изменения вносятся через GitHub. Вот заготовка pull request'a: 
[https://github.com/ssskralin/w3id.org/blob/logd.ru/logd/ru/.htaccess]

По правилам из этого файла будет производиться перенаправление, например, с [https://w3id.org/logd/ru/fssp.ru/resource/agency_03000 на http://linkeddata.fssprus.ru/resource/agency_03000].

Чтобы не создавать массу папок с закомментированными правилами, создал одну корневую и все правила прописал в ней. Хочется, чтобы в папке logd потом появились подпапки us, kz и пр. Но если такое желание покажется кому-то слишком амбициозным, можно изменить w3id.org/logd/ru [w3id.org/logd/ru] на w3id.org/logd.ru [w3id.org/logd.ru].

На будущее можно прописать в этом файле «секторные» поддомены, пока что, например, поддоменами linkeddata.ru [http://linkeddata.ru/].

На всякий случай: вот [https://github.com/UKGovLD/URI-patterns-core/blob/master/URI%20Patterns.md#annex-i-datagovuk-active-sector-inventory] список тематических поддоменов в data.gov.uk [http://data.gov.uk/]. Вообще, эта вторая версия их методических рекомендаций разумнее первой.

'''Заключение'''

Для окончательного решения требуется зафиксировать некоторые архитектурные моменты. Например:

- будут ли ФОИВ сами публиковать LOGD;
- будет ли существовать централизованный ресурс.