MarkLogic SPARQL, использующий путь свойства, не возвращает данные, как ожидалось

Используя следующие образцы троек:

@prefix : <http://www.me.org/me_schema#> .
@prefix dc: <http://purl.org/dc#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.me.org/content/me_schema>
  rdf:type owl:Ontology ;
  owl:imports <http://www.w3.org/2004/02/skos/core> ;
.
:a
  rdf:type owl:ObjectProperty ;
  rdfs:label "A" ;
  rdfs:subPropertyOf :b ;
.
:b
  rdf:type owl:ObjectProperty ;
  rdfs:label "B" ;
  rdfs:subPropertyOf :c ;
.
:c
  rdfs:label "C"^^xsd:string ;
.

Этот запрос возвращает две строки, как и ожидалось (обе b и c в столбце ?o):

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

select * 
from <test>
where
{
  ?s rdfs:label 'A' .
  ?s rdfs:subPropertyOf+ ?o
}

Однако я ожидаю, что следующее вернет 1 строку, но вернет пустой результат. Протестировано в консоли запросов:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

select * 
from <test>
where
{
  ?s rdfs:label 'A' .
  ?s rdfs:subPropertyOf+ <http://www.me.org/me_schema#c>
}

Я ожидаю, что он вернет одну строку для «а». Это ошибка или я упускаю что-то очевидное?

Я попробовал аналогичный запрос с DBPedia, и он возвращает данные, как я и ожидал. Например, следующий запрос возвращает две строки для «звезды», хотя ни одна из них не является прямым subClassOf owl:Thing.

select *
where 
{
 ?s rdfs:label  "star"@en .
 ?s rdfs:subClassOf+ owl:Thing
} LIMIT 100

Я придумал следующую работу на случай, если у кого-то возникнет такая же проблема:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

select * 
from <test>
where
{
  ?s rdfs:label 'A' .
  ?s rdfs:subPropertyOf ?s2 .
  ?s2 rdfs:subPropertyOf* <http://www.me.org/me_schema#c>
}

person Alex W    schedule 15.12.2015    source источник
comment
Я уверен, что это полезный отзыв для команды Marklogic, но в чем именно заключается вопрос?   -  person Jeen Broekstra    schedule 16.12.2015
comment
Я относительно новичок в SPARQL, поэтому просто хочу подтвердить, что я не пропустил что-то глупое.   -  person Alex W    schedule 16.12.2015
comment
Справедливо. Чтобы подтвердить: насколько я могу судить, вы ничего не упустили, и этот второй запрос действительно должен был вернуть 1 результат. Я дословно прогнал ваш пример через другой движок SPARQL (Sesame) и получил ожидаемый результат. Так что похоже на глюк в MarkLogic. Пути к свойствам FWIW — одна из самых сложных функций в спецификации SPARQL.   -  person Jeen Broekstra    schedule 16.12.2015


Ответы (1)


(Я бы поместил это в комментарий, но у меня нет репутации, необходимой для этого.)

Я только что попробовал ваш пример с нулевым результатом на MarkLogic 8.0-3 и действительно получил [{"s":"<http://www.me.org/me_schema#a>"}], как вы и ожидали. Вы используете более раннюю версию MarkLogic (вы можете увидеть версию в верхнем левом углу localhost:8001)?

Чтобы убедиться в этом, я зашел в консоль запросов MarkLogic в localhost:8000/qconsole/, установил "Источник контента ' в мою базу данных (с включенным тройным индексом) изменил тип запроса на "Обновление SPARQL" и ввел этот код вставки SPARQL:

PREFIX : <http://www.me.org/me_schema#>
prefix dc: <http://purl.org/dc#>
prefix owl: <http://www.w3.org/2002/07/owl#>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix skos: <http://www.w3.org/2004/02/skos/core#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT DATA { GRAPH <test> {
  <http://www.me.org/content/me_schema>  rdf:type owl:Ontology .
  <http://www.me.org/content/me_schema> owl:imports <http://www.w3.org/2004/02/skos/core> .

 :a rdf:type owl:ObjectProperty .
 :a rdfs:label "A" .
 :a rdfs:subPropertyOf :b .

 :b rdf:type owl:ObjectProperty .
 :b rdfs:label "B" .
 :b rdfs:subPropertyOf :c .

 :c rdfs:label "C"^^xsd:string .

  }}

Затем я открыл новую вкладку в консоли запросов, установил тип запроса «Запрос SPARQL» и выполнил ваш точный запрос:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

select * 
from <test>
where
{
  ?s rdfs:label 'A' .
  ?s rdfs:subPropertyOf+ <http://www.me.org/me_schema#c>
}

Если вы используете более раннюю версию MarkLogic, попробуйте обновить ее до последней на странице загрузки MarkLogic.

person Patrick McElwee    schedule 17.12.2015
comment
В более поздних версиях MarkLogic 8 были исправлены пути к свойствам — я согласен, что вам следует попробовать обновиться до последней версии. - person John Snelson; 17.12.2015
comment
Я проверил, что мы на MarkLogic 8.0-3. И я все еще получаю нулевой результат, следуя тем же шагам, которые вы описали выше (за исключением того, что первая часть — это обновление SPARQL). - person Alex W; 21.12.2015
comment
Это работает, если вы используете rdfs:subPropertyOf* вместо rdfs:subPropertyOf+? Я не могу понять, почему для вас это было бы иначе, чем для меня, на той же версии MarkLogic. Может попробовать 8.0-4 (последнюю)? - person Patrick McElwee; 04.01.2016
comment
Да. Проблема в обоих случаях использования. Странная часть наших реальных данных заключается в том, что запрос работает для некоторых данных, но не для других, казалось бы, идентичных данных. Я мог бы упростить данные до минимума и воссоздать проблему. Все больше убеждаюсь, что проблема в MarkLogic. - person Alex W; 06.01.2016
comment
Было несколько небольших релизов на 8.0-3 балла. При ближайшем рассмотрении вижу, что у меня стоит 8.0-3.2. Это могло быть исправлением ошибки в одном из них. - person Patrick McElwee; 07.01.2016
comment
Пробовал на другом сервере MarkLogic с версией 8.0-3.3 и все равно наблюдал тот же результат. Я подозреваю, что настройка тройного магазина влияет на результат, но на самом деле это не так. При неправильной настройке можно ожидать плохой производительности, но результат всегда должен быть правильным. - person Alex W; 19.01.2016
comment
Алекс согласился, что конфигурация не должна иметь значения для этого запроса. Я не могу воспроизвести результат, изменив настройки тройного индекса. Я мог бы взглянуть на ваши другие настройки, если вы пришлете мне вывод localhost:8002/manage/v2/databases/your-database-name-here/ ... Кроме того: это пустая база данных или у вас есть другие документы? Вы установили набор правил по умолчанию? - person Patrick McElwee; 20.01.2016