element-query | JS Polyfill for element queries | Media library

The StructuredQueryBuilder.containerQuery() method constructs a search:container-query in the Search API. On the enode, the REST API converts the search:container-query to cts:element-query() or cts:json-property-query() or cts:json-property-scope-query() as appropriate.

For more detail, see:

http://docs.marklogic.com/javadoc/client/com/marklogic/client/query/StructuredQueryBuilder.html#containerQuery-com.marklogic.client.query.StructuredQueryBuilder.ContainerIndex-com.marklogic.client.query.StructuredQueryDefinition-

http://docs.marklogic.com/guide/search-dev/structured-query#id_87231

The other way to provide the query in the Java API is to serialize the cts:element-query() as JSON or XML to learn the query structure and then use a DOM to construct the query and pass the query as a RawCtsQueryDefinition payload.

For that approach, see:

http://docs.marklogic.com/guide/java/searches#id_45762

http://docs.marklogic.com/javadoc/client/com/marklogic/client/query/RawCtsQueryDefinition.html

Hoping that helps,

The answer is not entirely straight-forward, meaning that results might vary depending on data, and volume.

A couple of notes though:

• Your queries are not semantically the same. Element-queries check for ancestors, while in a path you can be more strict, and require specific parents, so direct parent-child rather than ancestor-descendant relations
• Range queries are resolved against range indexes with predefined collations, and always against entire ('exact') value. Value queries are resolved against universal index however. More specifically, against the index with unstemmed tokens. If your value consists of multiple tokens, it would require positions to be enabled, or filtered searches for accuracy. The value in your example consists of only one token though.
• Path range indexes come at a cost at ingest time, slightly bigger than element range indexes. Range indexes also take extra memory. Element queries, and element value queries take slightly more work to resolve at search time. Though, you might need a big test set to notice significant differences.
• Last but not least, you can't do inequality queries, or value lookups for facets and such without range indexes.

HTH!

You are on the right track. Use the container option, which works like any other constraint option, then wrap your nested query in parenthesis.

For example:

Yes, there are definitely differences. Whether XQuery or SPARQL is most efficient however fully depends on the problem you are trying to solve. XQuery is best at querying and processing document data, while SPARQL really allows you to reason easily over RDF data.

It is true that RDF data is serialized as XML in MarkLogic, and you can full-text search it, and even put range indexes on it if you like, but RDF data is already indexed in the triple index, which would give you more accurate results than the full-text search of above.

Also note that SPARQL allows you to follow predicate paths, which involves a lot of joining. That will be much more efficient if done via SPARQL than via XQuery, because it is mostly resolved via the triple index. Image a SPARQL query like this one:

When you turn on positions, we store a positions vector for each document in the index for the relevant term, instead of just the document id.

The way to think about this is in terms of the specificity of the leaf queries and the work involved in calculating them and intersecting intermediate results.

When you see a term-query in the query plan, that means it is just looking up document ids, so there is no knowledge of relative positioning -- a less accurate result for a long phrase like this, because the "element word" and "word position" could be occurring in two separate parent elements in the document. If your data only ever has one element with this name in each document, that could not happen, although you could still have false matches where the two-word subphrases occur in, say, the reverse order, or separated by other words.

When you see word-query in the query plan, that means we are going to be looking at positions, and here you see the relative positions for each of the words in the phrase. When this is resolved, we examine the positions vector and toss out the ones that don't mean this positional constraint. So all the matches will have this sequence of words in this order: a more precise match.

The element-query in the plan is also applying positional constraints, of the element instances relative to the matches inside the element. There are optimizations where the element positional constraints are actually pushed down to the leaves of the query tree to avoid excess intermediate calculations.

You also see some technically redundant term queries: the point of these is to do simple term lookups that are probably more constrained than the leaf word queries. Since intersection of term lists from an and-query always proceeds from the shortest matching posting list, this can provide a fail-fast mechanism to avoid the more expensive positions calculations. There is a certain amount of heuristic judgement in that, and given a complex set of index options and query variations, sometimes those additional terms are, in fact, not helpful.

This actually has nothing do with punctuation in resolving your search but rather how MarkLogic tokenizes and indexes the position of individual words. By default, MarkLogic's tokenization breaks hyphenated phrases into separate words. You can use a custom tokenizer to dictate how MarkLogic should index words if you don't like the default behavior. There is a pretty detailed guide on using a custom tokenizer to ignore hyphens in word tokenization available here.

For your case, I'm not sure I would recommend you explore using a custom tokenizer. There can be unintended consequences and it's not as performant as using the default tokenization. Instead, it would probably make more sense to adapt your code to how the default tokenization works.

Let's look at : comparative, interventional, quasi-experimental study

It would be tokenized like :

The fn:matches function does not support group modifiers like (?! and (?. Simplify your pattern, and capture false positives after the match with another match if necessary.

I believe MarkLogic indexes word distances starting with the anchor word at a location of 0, and the subsequent token at a distance of 1 etc. In order query neighboring words you need to use a near-query distance of 1. The queries in your examples are performing correctly.

Unfiltered wildcard queries within specific elements (i.e. not just with a document) may return false positives without positional indexes. I would try enabling either or both of word positions and element word positions. It may also be worth testing whether you see additional performance improvements from enabling fast element phrase searches.