#sparql #rdf4j
#sparql #rdf4j
Вопрос:
Чтобы избежать возможной «проблемы XY», позвольте мне объяснить мою настоящую цель: я пытаюсь изменить заглавные буквы языковых тегов в репозитории rdf4j, используя sparql. Но, хотя rdf4j хранит языковые теги так, как они были записаны, когда они были определены, он знает достаточно, чтобы рассматривать их как нечувствительные к регистру, как того требует стандарт. Таким образом, он рассматривает мою попытку редактирования как недействительную:
Настройка:
INSERT DATA { test:a skos:prefLabel "hello"@EN }
Попытка:
DELETE { test:a skos:prefLabel "hello"@EN }
INSERT { test:a skos:prefLabel "hello"@en }
WHERE
{ test:a skos:prefLabel "hello"@EN }
Результат:
Этот запрос ничего не делает. Языковой тег по-прежнему написан EN . Интересно, что это также не удается, если я выполняю два отдельных запроса:
Запрос 1:
DELETE DATA { test:a skos:prefLabel "hello"@EN }
Запрос 2:
INSERT DATA { test:a skos:prefLabel "hello"@en }
Очевидно, что удаленные строки остаются во внутреннем кэше и восстанавливаются, так что вместо этого мой запрос INSERT воскресает "hello"@EN . Перезапуск очистит кеш, но это не лучший UX…
Теперь, с некоторыми более старыми версиями rdf4j, я мог бы очистить этот внутренний кэш с помощью волшебной команды CLEAR SILENT GRAPH <urn:uri:cache> . Но, похоже, это не работает с rdf4j 2.3.3, с чем мы и застряли на данный момент. Есть ли еще способ очистить строковый кэш без перезапуска или изменить заглавные буквы языковых тегов любым другим способом?
PS Я нашел эту интересную тему об обработке регистра в языковых тегах; но это не приблизило меня к решению.
Комментарии:
1. В какой версии RDF4J вы использовали этот
CLEAR SILENT GRAPH <urn:uri:cache>трюк? Я не могу вспомнить, чтобы это когда-либо было функцией…2. Предполагается, что версия, с которой это работает, должна быть 2.3.3 — та же версия, которая не работает сейчас. Я думаю, что на самом деле это более ранняя версия. Мне нужно будет выяснить, в чем различия.
Ответ №1:
На первый взгляд это выглядит как ошибка для меня, непреднамеренное последствие исправления, которое мы сделали несколько лет назад, чтобы разрешить сохранение регистра в языковых тегах (https://openrdf.atlassian.net/browse/SES-1659 ).
Я не уверен, что для этого есть какие-либо обходные пути только для SPARQL, поэтому, пожалуйста, не стесняйтесь регистрировать отчет об ошибке / запрос функции по адресу https://github.com/eclipse/rdf4j/issues .
Сказав это, RDF4J, конечно, имеет функциональность для нормализации языковых тегов. В частности, анализаторы RDF могут быть настроены для нормализации языковых тегов (см. Документацию по конфигурации Rio), и, кроме того, существует служебный метод Literals.normalizeLanguageTag , который вы можете использовать для преобразования любого языкового тега в стандартную каноническую форму.
Комментарии:
1. Спасибо! Я так и сделаю. Нормализация языковых тегов перед сохранением определенно была бы правильным решением, но, к сожалению, это не поможет с более ранними или текущими версиями программного обеспечения, использующими хранилище rdf4j. Итак, я все еще ищу решение.
2. Дело в том, что очистка кэша работала долгое время после введения сохранения регистра. Что-то еще, должно быть, было критическим изменением… Но можете ли вы определить, нельзя ли больше очистить кэш от sparql, или что-то еще мешает моему подходу?
3. Дело в том, что я не помню, чтобы очистка кэша была функцией. Можете ли вы проверить, в какой версии rdf4j это работает для вас? Надеюсь, таким образом я смогу восстановить, что с ним произошло 😁
4. @alexis я думаю, что здесь мы немного отклоняемся от темы, но вкратце: вы можете настроить поведение каждого анализатора с помощью системных свойств Java (см. rdf4j.org/documentation/programming/rio /… ) — это будет автоматически использоваться по умолчанию для каждого анализатора, используемого в вашем приложении.
5. Я передам это дальше, спасибо. Я заметил текущую версию RDF4J и был соответственно удивлен (я не в команде разработчиков.)