Разрешена ли «строка запроса» в URI, используемом в RDF?
Документ «Структура описания ресурсов (RDF): концепции и абстрактный синтаксис» Раздел 6.4 утверждает, что «Ссылка URI в графе RDF (ссылка RDF URI) ... создаст допустимую последовательность символов URI (согласно RFC2396, разделы 2.1) , представляющую абсолютный URI с необязательным идентификатором фрагмента ... «
RFC 2396 , раздел 2.1 говорит только о кодировке отдельных символов. Он не говорит о том, какие разделы стандартного URI разрешены в RDF.
В некоторых документах RDF, которые я видел, термин «абсолютный URI», кажется, относится только к форме URI domain.tld / path / name # optionalFragment, но без упоминания о том, является ли строка запроса (? Key1 = value1 & key2 = значение2) (иногда называемые данными CGI) разрешены или запрещены. В другой документации RDF используется только термин «абсолютный URI» в отличие от относительного URI (/ just / a / path).
Поиск «строки запроса RDF URI» изобилует ложными попаданиями в такие вещи, как SPARQL.
Итак, мой вопрос: разрешена ли стандартная строка запроса HTML в URI, используемом в RDF или RDFa?
Если нет, то почему? Я понимаю, что URI не является URL-адресом и не обязательно будет использоваться для получения веб-страницы с сервера. Однако процессоры RDF читают эти URI, и я думаю, что они могли бы получить некоторую помощь в виде дополнительных метаданных, которые можно было бы передать через эти строки «запроса».
[Обновление от 09.02.2012] Вот суть моего вопроса: я ищу способ указать «силу» соединения. Например, не все foaf: всех знают одинаково хорошо. Возможно, мы просто встретились на несколько минут на конференции. Или, возможно, я жил с кем-то годами. Для ФАОФ все равно. Однако, если бы я мог написать foaf: know? Strong = + 50, то процессоры, которые не знают, что делать с ключом прочности, могли бы его игнорировать, в то время как те, которые «осведомлены о силе», имели бы ценные дополнительные метаданные. Я мог бы создать словарь, включающий термин «соглашается с», а затем позволить значению «сила = ключ» варьироваться от 0 до 100 (с указанием процента согласия).Затем я охватил весь диапазон согласия одним термином из словарного запаса. {Примечание: я думал о том, чтобы разрешить диапазон от -100 до +100, чтобы покрыть диапазон разногласий. Однако для обратной совместимости нам понадобится термин «disagreeWith», чтобы процессоры, которые не «осознают силу», все равно знали разницу между «соглашатьсяWith» и disagreeWith ».}
В настоящее время кажется, что существует у автора RDF нет возможности узнать разницу между «почти не встречал» и «знает его лучше, чем он знает себя». Решение рассматривать каждый разный URI предиката с различным значением в паре «ключ-значение» как совершенно отдельный и совершенно несвязанный предикат, похоже, отбрасывает почти всю наиболее ценную информацию о соединении, и все ради упрощения написания кода и быстрой обработки.
Могут быть другие полезные применения пар ключ-значение в строке запроса кроме создания полностью отдельного субъекта, предиката или объекта: они могут использоваться для указания того, кто добавил конкретную сущность в совместно редактируемый файл .RDF. В его нынешнем виде все, что знает исследователь RDF, - это то, что существует тройка, где-то там, где-нибудь? не имеет дополнительной информации для обоснования своих рассуждений. Зашифрованные парольные фразы могут использоваться для проверки надежности источника, а не просто для принятия решения доверять или не доверять всему домену.