Извлечение данных из таблицы (MarkLogic)
В настоящее время я пытаюсь извлечь данные из таблицы, чтобы использовать их в качестве списка URI для поиска XQuery CTS. В настоящее время я создал оптический запрос, который возвращает данные в табличном формате.
Например, с помощью следующего запроса Optics
import module namespace op = "http://marklogic.com/optic" at "/MarkLogic/optic.xqy";
import module namespace ofn = "http://marklogic.com/optic/expression/fn" at "/MarkLogic/optic/optic-fn.xqy";
let $people := op:from-sparql('SELECT * WHERE {?person </id> "000". ?person </path> ?animal}', "sparql")
=> op:select(( op:as('personStr',ofn:string(op:col('person'))), op:as('animalStr',ofn:string(op:col('animal'))) ))
return(
$people => op:result()
)
Я получу таблицу, которая выглядит как
personStr | animalStr
-------------------------------
/people/000 /animal/001
/people/000 /animal/002
В этой таблице будет содержаться URI, указывающий на различные документы, которые я надеюсь извлечь (например, animalStr) и выполнить некоторую фильтрацию с помощью cts:search(fn:doc(uri_list), ....)
===Обновление с текущим подходом===
let $people := op:from-sparql('SELECT * WHERE {?person </id> "000". ?person </path> ?animal}', "sparql")
=> op:select(( op:as('personStr',ofn:string(op:col('person'))), op:as('animalStr',ofn:string(op:col('animal'))) ))
let $animal := op:from-lexicons(
map:entry("animal",cts:uri-reference()),
"lexicon")
=>op:where(
cts:path-geospatial-query("animal_data/location",
cts:circle(5500, cts:point(-55.854526273011, -151.93342455372309)),
"type=long-lat-point")
)
return(
$animal => op:join-inner(
$people,
op:on(
"animal","animalStr"
)
)
=> op:select(("personStr", "animalStr"))
=> op:result()
)
Основываясь на этом подходе, можно увидеть, что мне всегда требуется извлекать всех животных в определенном месте, прежде чем выполнять внутреннее соединение, чтобы получить мои результаты. Однако в идеале я хотел бы применить геопространственный запрос непосредственно к результатам, полученным из запроса SPARQL.
Я готов принять другие альтернативные подходы к этому, если они есть. Я обновил свой вопрос, пытаясь объяснить, чего я на самом деле пытаюсь достичь. Но в целом я хотел бы отфильтровать оптический запрос sparql напрямую, используя геопространственные запросы, чтобы получить всех животных в определенном геопространственном пространстве, используя cts:circle напрямую. @Вагнер Майкл
Ответы 1
Optic может ограничить запрос SPARQL тройками, спроецированными из документов, которые соответствуют динамическому запросу, включая те документы, которые соответствуют запросам геопространственных cts.
Общая схема такова:
op.fromSparql(...SPARQL query...)
.where(...cts query...)
Хотя построитель указывает cts.query после запроса SPARQL, механизм не выполняет эти шаги последовательно. Вместо этого механизм игнорирует все триплеты из документов, которые не соответствуют cts.query.
Ограничивающий cts.query работает так же для строк и значений словаря.
На самом деле, предоставление ограничивающего cts.query с предложением where() является лучшей практикой для повышения эффективности поиска. Это особенно верно для троек, потому что тройки по определению требуют интенсивного соединения.
Возможно ли, что этот шаблон может удовлетворить требование?
Надеясь, что это поможет,
Спасибо вроде работает. Но я хотел бы спросить, относится ли это ко всем другим вариантам, таким как op:from-view? Кроме того, как это будет работать, если я свяжу cts query с op:where после выполнения операции op:join-inner с другими таблицами/результатами? @ehennum
Да, ограничивающий cts:query работает со всеми методами доступа, включая op:from-view(), op:from-lexicons() и op:from-triples(). Если операция where() указывает ограничивающий cts:query после соединения, запрос применяется к обеим сторонам соединения. То есть только значения из документов, соответствующих запросу, вносят вклад в обе стороны соединения.
Я вижу, я хотел бы уточнить, чтобы использовать op:from-view(), нам нужно будет проецировать документы в view с SQL-подобными таблицами, позволяющими запрашивать данные с помощью SQL, поэтому, когда мы запускаем cts queries с op:where, мы отфильтровываем documents, а не сам view . Следовательно, документы, не соответствующие требованиям cts query, не будут отображаться в представлении. Это также относится к op:from-sparql, поскольку он будет фильтровать как тройные документы, так и документы, которые проецируют тройки, используя извлечение на основе шаблона. @ehennum
Да, @WhiteSolstice, верно. TDE проецирует строки или тройки из документа в индексы, когда документ вставляется или переиндексируется. Ограничивающий cts:query сопоставляет документы так же, как и cts:search(). Где cts:search() извлекает совпадающие документы из леса или кэша, а методы доступа Optic from-view(), from-triples(), from-lexicons(), from-sparql() и from-sql() извлекают значения для соответствующих документов из индексов.
Каков ваш актуальный вопрос? Вы хотите знать, является ли ваш текущий подход правильным?