element word positions - conceptual questions

Multi tool use
Multi tool use












1














I'm trying to understand the impact of the element word positions index setting.
See the following xquery which returns the plan of a simple element-word-query search:



xdmp:plan(cts:search(doc(), 
cts:and-query(
cts:element-word-query(xs:QName("name"), "element word position")
),
("unfiltered")
))


And the final-plan if the index is not activated (reduced form to save space):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:term-query>word("element")</qry:term-query>
<qry:term-query>word("word")</qry:term-query>
<qry:term-query>word("position")</qry:term-query>
</qry:and-query>


Query plan after the index is activated (word-positions and also element word positions):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:element-query>
element(name)
<qry:word-query>
<qry:KP pos="0">word("element")</qry:KP>
<qry:KP pos="1">word("word")</qry:KP>
<qry:KP pos="2">word("position")</qry:KP>
</qry:word-query>
</qry:element-query>
</qry:and-query>


So i assume, because there are a lot less term-query generated, the resulting candidate fragment id count is going to be smaller and thus the intersection at index resolution is faster. Other than that i'd really like to understand how a element-query works under the hood. So i've got a few questions:




  • What kind of additional information is saved in the index if element word positions is activated?

  • How would the index and posting list look like? Is the key only the element or a element+word combination? Are there any graphical resources which visualize it? (not expection you to draw something)

  • Also how does a element-query execute? I see how a simple term-query returns the posting list of the term key, but i am not sure how a element-query with a word-query as a "sub-query" is evalutated.


Edit:
Added a picture to visualize my understanding of how the index might look with element word positions enabled. (See mholstege's answers comments for details)
enter image description here










share|improve this question
























  • Have you taken a look at Inside MarkLogic Server at marklogic.com/resources/inside-marklogic-server ? This resource goes into some conceptual depth about the MarkLogic indexes.
    – ehennum
    Dec 28 '18 at 16:55












  • Yes, while inside marklogic server goes into some detail about word-positions, phrases and such, it does not describe the differences of word positions and element word positions. Still a really valuable resource.
    – Wagner Michael
    Dec 28 '18 at 17:08
















1














I'm trying to understand the impact of the element word positions index setting.
See the following xquery which returns the plan of a simple element-word-query search:



xdmp:plan(cts:search(doc(), 
cts:and-query(
cts:element-word-query(xs:QName("name"), "element word position")
),
("unfiltered")
))


And the final-plan if the index is not activated (reduced form to save space):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:term-query>word("element")</qry:term-query>
<qry:term-query>word("word")</qry:term-query>
<qry:term-query>word("position")</qry:term-query>
</qry:and-query>


Query plan after the index is activated (word-positions and also element word positions):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:element-query>
element(name)
<qry:word-query>
<qry:KP pos="0">word("element")</qry:KP>
<qry:KP pos="1">word("word")</qry:KP>
<qry:KP pos="2">word("position")</qry:KP>
</qry:word-query>
</qry:element-query>
</qry:and-query>


So i assume, because there are a lot less term-query generated, the resulting candidate fragment id count is going to be smaller and thus the intersection at index resolution is faster. Other than that i'd really like to understand how a element-query works under the hood. So i've got a few questions:




  • What kind of additional information is saved in the index if element word positions is activated?

  • How would the index and posting list look like? Is the key only the element or a element+word combination? Are there any graphical resources which visualize it? (not expection you to draw something)

  • Also how does a element-query execute? I see how a simple term-query returns the posting list of the term key, but i am not sure how a element-query with a word-query as a "sub-query" is evalutated.


Edit:
Added a picture to visualize my understanding of how the index might look with element word positions enabled. (See mholstege's answers comments for details)
enter image description here










share|improve this question
























  • Have you taken a look at Inside MarkLogic Server at marklogic.com/resources/inside-marklogic-server ? This resource goes into some conceptual depth about the MarkLogic indexes.
    – ehennum
    Dec 28 '18 at 16:55












  • Yes, while inside marklogic server goes into some detail about word-positions, phrases and such, it does not describe the differences of word positions and element word positions. Still a really valuable resource.
    – Wagner Michael
    Dec 28 '18 at 17:08














1












1








1







I'm trying to understand the impact of the element word positions index setting.
See the following xquery which returns the plan of a simple element-word-query search:



xdmp:plan(cts:search(doc(), 
cts:and-query(
cts:element-word-query(xs:QName("name"), "element word position")
),
("unfiltered")
))


And the final-plan if the index is not activated (reduced form to save space):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:term-query>word("element")</qry:term-query>
<qry:term-query>word("word")</qry:term-query>
<qry:term-query>word("position")</qry:term-query>
</qry:and-query>


Query plan after the index is activated (word-positions and also element word positions):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:element-query>
element(name)
<qry:word-query>
<qry:KP pos="0">word("element")</qry:KP>
<qry:KP pos="1">word("word")</qry:KP>
<qry:KP pos="2">word("position")</qry:KP>
</qry:word-query>
</qry:element-query>
</qry:and-query>


So i assume, because there are a lot less term-query generated, the resulting candidate fragment id count is going to be smaller and thus the intersection at index resolution is faster. Other than that i'd really like to understand how a element-query works under the hood. So i've got a few questions:




  • What kind of additional information is saved in the index if element word positions is activated?

  • How would the index and posting list look like? Is the key only the element or a element+word combination? Are there any graphical resources which visualize it? (not expection you to draw something)

  • Also how does a element-query execute? I see how a simple term-query returns the posting list of the term key, but i am not sure how a element-query with a word-query as a "sub-query" is evalutated.


Edit:
Added a picture to visualize my understanding of how the index might look with element word positions enabled. (See mholstege's answers comments for details)
enter image description here










share|improve this question















I'm trying to understand the impact of the element word positions index setting.
See the following xquery which returns the plan of a simple element-word-query search:



xdmp:plan(cts:search(doc(), 
cts:and-query(
cts:element-word-query(xs:QName("name"), "element word position")
),
("unfiltered")
))


And the final-plan if the index is not activated (reduced form to save space):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:term-query>word("element")</qry:term-query>
<qry:term-query>word("word")</qry:term-query>
<qry:term-query>word("position")</qry:term-query>
</qry:and-query>


Query plan after the index is activated (word-positions and also element word positions):



<qry:and-query>
<qry:term-query>element(name),pair(word("element"),word("word"))</qry:term-query>
<qry:term-query>element(name),pair(word("word"),word("position"))</qry:term-query>
<qry:element-query>
element(name)
<qry:word-query>
<qry:KP pos="0">word("element")</qry:KP>
<qry:KP pos="1">word("word")</qry:KP>
<qry:KP pos="2">word("position")</qry:KP>
</qry:word-query>
</qry:element-query>
</qry:and-query>


So i assume, because there are a lot less term-query generated, the resulting candidate fragment id count is going to be smaller and thus the intersection at index resolution is faster. Other than that i'd really like to understand how a element-query works under the hood. So i've got a few questions:




  • What kind of additional information is saved in the index if element word positions is activated?

  • How would the index and posting list look like? Is the key only the element or a element+word combination? Are there any graphical resources which visualize it? (not expection you to draw something)

  • Also how does a element-query execute? I see how a simple term-query returns the posting list of the term key, but i am not sure how a element-query with a word-query as a "sub-query" is evalutated.


Edit:
Added a picture to visualize my understanding of how the index might look with element word positions enabled. (See mholstege's answers comments for details)
enter image description here







marklogic






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 28 '18 at 16:42

























asked Dec 27 '18 at 16:49









Wagner Michael

1,188722




1,188722












  • Have you taken a look at Inside MarkLogic Server at marklogic.com/resources/inside-marklogic-server ? This resource goes into some conceptual depth about the MarkLogic indexes.
    – ehennum
    Dec 28 '18 at 16:55












  • Yes, while inside marklogic server goes into some detail about word-positions, phrases and such, it does not describe the differences of word positions and element word positions. Still a really valuable resource.
    – Wagner Michael
    Dec 28 '18 at 17:08


















  • Have you taken a look at Inside MarkLogic Server at marklogic.com/resources/inside-marklogic-server ? This resource goes into some conceptual depth about the MarkLogic indexes.
    – ehennum
    Dec 28 '18 at 16:55












  • Yes, while inside marklogic server goes into some detail about word-positions, phrases and such, it does not describe the differences of word positions and element word positions. Still a really valuable resource.
    – Wagner Michael
    Dec 28 '18 at 17:08
















Have you taken a look at Inside MarkLogic Server at marklogic.com/resources/inside-marklogic-server ? This resource goes into some conceptual depth about the MarkLogic indexes.
– ehennum
Dec 28 '18 at 16:55






Have you taken a look at Inside MarkLogic Server at marklogic.com/resources/inside-marklogic-server ? This resource goes into some conceptual depth about the MarkLogic indexes.
– ehennum
Dec 28 '18 at 16:55














Yes, while inside marklogic server goes into some detail about word-positions, phrases and such, it does not describe the differences of word positions and element word positions. Still a really valuable resource.
– Wagner Michael
Dec 28 '18 at 17:08




Yes, while inside marklogic server goes into some detail about word-positions, phrases and such, it does not describe the differences of word positions and element word positions. Still a really valuable resource.
– Wagner Michael
Dec 28 '18 at 17:08












1 Answer
1






active

oldest

votes


















5














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.






share|improve this answer





















  • Thank you for this in-depth answer! Much appreciated! A few more things i am not sure about: How does a element-query know that a word is inside a element? If i understand right, word positions are document-wide. Does the element-query use the index created by word positions? Or is there another index created by element word positions which save the positions of a word inside a element? I attached a image to my original question to visualize my idea of how the index looks.
    – Wagner Michael
    Dec 28 '18 at 16:40










  • This is getting very deep into the weeds, but the short answer is we store positions for specific kinds of terms. So if there is an word-in-element term with positions, it is the positions of instances of that fact. The word-positions setting acts as something of a master switch for recording positions of many kinds of terms ("word" terms as opposed to "value" terms or "character" terms).
    – mholstege
    Dec 28 '18 at 17:01










  • Alright i won't dig any deeper ;) This already clarifies alot. Thanks alot :)!
    – Wagner Michael
    Dec 28 '18 at 17:10











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53948303%2felement-word-positions-conceptual-questions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









5














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.






share|improve this answer





















  • Thank you for this in-depth answer! Much appreciated! A few more things i am not sure about: How does a element-query know that a word is inside a element? If i understand right, word positions are document-wide. Does the element-query use the index created by word positions? Or is there another index created by element word positions which save the positions of a word inside a element? I attached a image to my original question to visualize my idea of how the index looks.
    – Wagner Michael
    Dec 28 '18 at 16:40










  • This is getting very deep into the weeds, but the short answer is we store positions for specific kinds of terms. So if there is an word-in-element term with positions, it is the positions of instances of that fact. The word-positions setting acts as something of a master switch for recording positions of many kinds of terms ("word" terms as opposed to "value" terms or "character" terms).
    – mholstege
    Dec 28 '18 at 17:01










  • Alright i won't dig any deeper ;) This already clarifies alot. Thanks alot :)!
    – Wagner Michael
    Dec 28 '18 at 17:10
















5














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.






share|improve this answer





















  • Thank you for this in-depth answer! Much appreciated! A few more things i am not sure about: How does a element-query know that a word is inside a element? If i understand right, word positions are document-wide. Does the element-query use the index created by word positions? Or is there another index created by element word positions which save the positions of a word inside a element? I attached a image to my original question to visualize my idea of how the index looks.
    – Wagner Michael
    Dec 28 '18 at 16:40










  • This is getting very deep into the weeds, but the short answer is we store positions for specific kinds of terms. So if there is an word-in-element term with positions, it is the positions of instances of that fact. The word-positions setting acts as something of a master switch for recording positions of many kinds of terms ("word" terms as opposed to "value" terms or "character" terms).
    – mholstege
    Dec 28 '18 at 17:01










  • Alright i won't dig any deeper ;) This already clarifies alot. Thanks alot :)!
    – Wagner Michael
    Dec 28 '18 at 17:10














5












5








5






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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 28 '18 at 15:31









mholstege

3,51775




3,51775












  • Thank you for this in-depth answer! Much appreciated! A few more things i am not sure about: How does a element-query know that a word is inside a element? If i understand right, word positions are document-wide. Does the element-query use the index created by word positions? Or is there another index created by element word positions which save the positions of a word inside a element? I attached a image to my original question to visualize my idea of how the index looks.
    – Wagner Michael
    Dec 28 '18 at 16:40










  • This is getting very deep into the weeds, but the short answer is we store positions for specific kinds of terms. So if there is an word-in-element term with positions, it is the positions of instances of that fact. The word-positions setting acts as something of a master switch for recording positions of many kinds of terms ("word" terms as opposed to "value" terms or "character" terms).
    – mholstege
    Dec 28 '18 at 17:01










  • Alright i won't dig any deeper ;) This already clarifies alot. Thanks alot :)!
    – Wagner Michael
    Dec 28 '18 at 17:10


















  • Thank you for this in-depth answer! Much appreciated! A few more things i am not sure about: How does a element-query know that a word is inside a element? If i understand right, word positions are document-wide. Does the element-query use the index created by word positions? Or is there another index created by element word positions which save the positions of a word inside a element? I attached a image to my original question to visualize my idea of how the index looks.
    – Wagner Michael
    Dec 28 '18 at 16:40










  • This is getting very deep into the weeds, but the short answer is we store positions for specific kinds of terms. So if there is an word-in-element term with positions, it is the positions of instances of that fact. The word-positions setting acts as something of a master switch for recording positions of many kinds of terms ("word" terms as opposed to "value" terms or "character" terms).
    – mholstege
    Dec 28 '18 at 17:01










  • Alright i won't dig any deeper ;) This already clarifies alot. Thanks alot :)!
    – Wagner Michael
    Dec 28 '18 at 17:10
















Thank you for this in-depth answer! Much appreciated! A few more things i am not sure about: How does a element-query know that a word is inside a element? If i understand right, word positions are document-wide. Does the element-query use the index created by word positions? Or is there another index created by element word positions which save the positions of a word inside a element? I attached a image to my original question to visualize my idea of how the index looks.
– Wagner Michael
Dec 28 '18 at 16:40




Thank you for this in-depth answer! Much appreciated! A few more things i am not sure about: How does a element-query know that a word is inside a element? If i understand right, word positions are document-wide. Does the element-query use the index created by word positions? Or is there another index created by element word positions which save the positions of a word inside a element? I attached a image to my original question to visualize my idea of how the index looks.
– Wagner Michael
Dec 28 '18 at 16:40












This is getting very deep into the weeds, but the short answer is we store positions for specific kinds of terms. So if there is an word-in-element term with positions, it is the positions of instances of that fact. The word-positions setting acts as something of a master switch for recording positions of many kinds of terms ("word" terms as opposed to "value" terms or "character" terms).
– mholstege
Dec 28 '18 at 17:01




This is getting very deep into the weeds, but the short answer is we store positions for specific kinds of terms. So if there is an word-in-element term with positions, it is the positions of instances of that fact. The word-positions setting acts as something of a master switch for recording positions of many kinds of terms ("word" terms as opposed to "value" terms or "character" terms).
– mholstege
Dec 28 '18 at 17:01












Alright i won't dig any deeper ;) This already clarifies alot. Thanks alot :)!
– Wagner Michael
Dec 28 '18 at 17:10




Alright i won't dig any deeper ;) This already clarifies alot. Thanks alot :)!
– Wagner Michael
Dec 28 '18 at 17:10


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53948303%2felement-word-positions-conceptual-questions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







ykZTrG26TXtkXFc,456e9Xr29ylGOH2mDR7
4qv7mh,0cxSiB 8

Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas