У меня были проблемы с двумя подходами - и код выше содержит смесь обоих.Кроме того, SPARQLWrapper здесь не проблема.
Первый подход, использующий службу метки wikibase, должен выглядеть следующим образом:
SELECT ?a ?aLabel ?propLabel ?b ?bLabel
WHERE
{
?item rdfs:label "weather"@en.
?item ?a ?b.
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
?prop wikibase:directClaim ?a .
}
Этот код также включает поиск по метке ('weather') к объекту запроса (?item
).
СЕРВИС работал, но если нет определения rdfs:label
, он просто возвращает объект.Графический интерфейс и SPARQLWrapper (в конечную точку SPARQL) просто возвращали результаты в другом порядке - поэтому выглядело так, как будто я вижу много «неудачных» выходных данных (т. Е. Объекты и метки с ошибками отображаются одинаково).
Это стало ясно, когда я начал добавлять ОПЦИОНАЛЬНОЕ предложение к подходу ниже.
Строка ?prop wikibase:directClaim ?a .
оказалась довольно простой.Wikibase определяет directClaim
для сопоставления свойств с сущностями.Это позволяет ему определять кортежи о свойствах (т. Е. Метку).Многие другие онтологии просто используют те же идентификаторы.
Мой второй (более общий подход) - это подход, который вы найдете во многих книгах и онлайн-учебниках.Проблема здесь в том, что в свойствах викибазы есть полный URL, и мне нужно было преобразовать их в сущность.Я пытался манипулировать строками, но это приводит к строковому литералу, а не к сущности.Решение состоит в том, чтобы снова использовать directClaim
:
?prop wikibase:directClaim ?a .
?prop rdfs:label ?propLabel. filter(lang(?propLabel) = "en").
Обратите внимание, что это возвращает результат, только если определено rdfs:label
.Добавление OPTIONAL вернет результаты, даже если метка не определена.