SPARQL - что нужно, чтобы найти онтологию? - PullRequest
Новая
       14

SPARQL - что нужно, чтобы найти онтологию?

1 голос
/ 29 июня 2010

Я довольно новичок в SPARQL, OWL и Jena, поэтому прошу прощения, если я задаю совершенно глупые вопросы. У меня проблема, которая сводит меня с ума с пары дней. Я использую следующую строку в качестве запроса для Jena QueryFactory.create(queryString), 

queryString = "PREFIX foaf:  <http://xmlns.com/foaf/0.1/>"+
"PREFIX ho: <http://www.flatlandfarm.de/fhtw/ontologies/2010/5/22/helloOwl.owl#>" +
"SELECT ?name ?person ?test ?group "+
"WHERE { ?person foaf:name ?name ; "+
"         a ho:GoodPerson ; "+
"         ho:isMemberOf ?group ; "+
"}";

До сегодняшнего утра это работало до тех пор, пока я запрашивал свойства только из пространства имен foaf. Как только я просил свойства из моего собственного пространства имен, я всегда получал пустые результаты. Пока я собирался опубликовать этот вопрос здесь и провел несколько финальных тестов, чтобы иметь возможность разместить его как можно точнее, он неожиданно сработал. Так как я не знал, что именно просить больше, я удалил свой вопрос перед публикацией. Пару часов спустя я использовал плагин Protege's Pellet для создания и экспорта предполагаемой модели. Я назвал его helloOwlInferred.owl и загрузил его в каталог на моем сервере, где еще находился helloWl.owl. Я настроил свой метод для загрузки выведенной онтологии и изменил вышеупомянутый запрос так, чтобы префикс ho: также был назначен выводимой онтологии. Сразу ничего не сработало. Если быть точным, то уже ничего не сработало, это были те же симптомы, которые у меня были до сегодняшнего утра с моим первоначальным запросом. Мой префикс больше не работал. Я сделал простой тест: я переименовал все файлы helloWorldInferred.owl (один на моем сервере для префикса и моей локальной копии, которую я загрузил) в helloWorld.owl. Достаточно странно, что все исправили.

Переименовав его обратно в helloWorldInferred.owl снова все сломалось. И так далее. То, что там происходит? Нужно ли подождать пару недель, пока моя онтология не будет «зарегистрирована как действительный префикс»?

Ответы [ 4 ]

2 голосов
/ 02 июля 2010

Может быть, ваш OWL-файл содержит конструкцию rdf:ID="something" (или какую-либо другую форму относительного URL, например rdf:about="#something")?

rdf:ID, а относительные URL-адреса расширены до полных абсолютных URL-адресов, таких какhttp://whatever/file.owl#something, используя базовый URL-адрес файла OWL.Если базовый URL явно не указан в файле (используя что-то вроде xml:base="http://whatever/file.owl"), то местоположение файла на веб-сервере (или в вашей файловой системе, если вы загружаете локальный файл) будет использоваться в качестве базового URI.

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

Включаяявный xml:base или обход относительных URI и rdf:ID должен решить проблему.

1 голос
/ 02 июля 2010

Похоже, это было вызвано ошибкой (или особенностью?) В Protege.Когда я экспортировал выведенную онтологию с новым именем, Протеж изменил определения xmlns(blank) и xml:base на имя нового файла, но не изменил определение фактического пространства имен. 

xmlns="http://xyz.com/helloOwl.owl" =>  xmlns="http://xyz.com/helloOwlInferred.owl"
xml:base="http://xyz.com/helloOwl.owl" =>  xml:base="http://xyz.com/helloOwlInferred.owl"

xmlns:helloOwl="http://xyz.com/helloOwl.owl" =>  xml:base="http://xyz.com/helloOwl.owl"
<!ENTITY helloOwl "http://wxyz.com/helloOwl.owl#" > => <!ENTITY helloOwl "http://wxyz.com/helloOwl.owl#" >

Так как я установил, что это похоже на работу.
Я виноват в том, что не изучил фактический источник с необходимым вниманием.

1 голос
/ 30 июня 2010

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

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

С учетом того, что ваша проблема может быть связана с Дженой, возможно, стоит задать ваш вопрос в Списке рассылки Jena

0 голосов
/ 23 августа 2018

Вы должны определить точный префикс URI для ho:, а затем сообщить его Protegé (есть панель для пространств имен и определить тот же URI, что и префикса онтологии), чтобы при определении GoodPerson в Protegé онпредполагается, что вы имеете в виду http://www.flatlandfarm.de/fhtw/ontologies/2010/5/22/helloOwl.owl#GoodPerson, что совпадает с ho:GoodPerson, только если вы использовали один и тот же префикс URI для этих двух.

Если вы этого не сделаете, Protegé (или какой-либо другой компонент, напримервеб-сервер) будет делать такие глупые вещи, как составление URI онтологии и его префикса URI по умолчанию (который идет перед GoodPerson, когда вы не указываете префикс), используя имя файла (или, что еще хуже, файл, похожий на URI): /// дом / пользователь / ...).

Помните, что URI онтологии технически отличается от префикса URI, который вы используете для сущностей, связанных с самой онтологией (классы, свойства и т. Д.), А ho: - это просто ярлык, имеющий локальное значение, котороезависит от того, что вы определяете в документах, таких как файлы или запросы SPARQL.

URI онтологии также может отличаться от URL-адреса, из которого можно получить файл онтологии, хотя было бы хорошо сделать их одинаковыми.Обычно для этого нужно поиграть с переписыванием URL-адреса в Apache, но иногда этот файл онтологии физически не публикуется, поскольку онтология загружается в конечную точку SPARQL, а ее URI преобразуется в документ RDF с помощью конечной точки.сам по себе, переписав URI онтологии в запрос SPARQL, который выдает инструкцию DESCRIBE.Тот же трюк можно использовать для разрешения любого другого URI (т. Е. Ваших данных, создающих онтологию), если связанные данные доступны с вашей конечной точки SPARQL (т. Е. Находятся в вашем тройном хранилище).

...