After further experimentation, I am finding that <default> doesn't work as I would expect when an exact phrase is involved. For example, I was expecting this query:
xquery version "1.0-ml"; import module namespace search="http://marklogic.com/appservices/search"; at "/MarkLogic/appservices/search/search.xqy"; let $options := <options xmlns="http://marklogic.com/appservices/search";> <constraint name="title"> <word> <element ns="http://digital.library.ptsem.edu/ia"; name="title"/> </word> </constraint> <term> <default ref="title"/> </term> </options> return search:search('"king james" OR authorized', $options) to return the same results as this query: xquery version "1.0-ml"; import module namespace search="http://marklogic.com/appservices/search"; at "/MarkLogic/appservices/search/search.xqy"; let $options := <options xmlns="http://marklogic.com/appservices/search";> <constraint name="title"> <word> <element ns="http://digital.library.ptsem.edu/ia"; name="title"/> </word> </constraint> </options> return search:search('title:"king james" OR title:authorized', $options) Not so! Instead, query #1 returns the same results as taking query #2 and changing title:"king james" to "king james" -- which clearly indicates that the <default> option is NOT applying the "title" constraint to quoted/exact phrases. Could this be a bug? The documentation for search:search, in the description of <term>, says that <default> "determines special handling to all terms". In my mind, an exact phrase *is* a term, and therefore the <default> constraint should be applied to exact phrases -- or am I misunderstanding what a "term" is? Thanks, Greg On Dec 9, 2013, at 11:09 AM, Murray, Gregory wrote: > Hi Colleen, > > Thanks for the suggestion. I wasn't aware of that option. (Having just > upgraded to 6 [yes, we're behind the curve], I haven't really explored new > features yet.) In this particular case, I think <default> in the search > options is the most straightforward solution, but structured query sounds > very useful and I'll keep it in mind for other situations. > > Thanks, > Greg > > > On Dec 6, 2013, at 5:10 PM, Colleen Whitney wrote: > >> The other thing to consider is whether structured query (introduced in 6) >> might be a better fit; you can construct the structure in the front end and >> bypass the need to construct and parse strings (though you can embed strings >> that need parsing in the query structure). >> >> From: [email protected] >> [[email protected]] on behalf of David Ennis >> [[email protected]] >> Sent: Friday, December 06, 2013 2:03 PM >> To: MarkLogic Developer Discussion >> Subject: Re: [MarkLogic Dev General] Easier word searches with constraint? >> >> HI Greg. >> >> Glad it helped a bit. If the app is in ML itself and you are using ML6 or >> above, then you could consider using nested map:maps to help build up the >> query parameters as an option. >> >> Regards, >> David >> >> >> On 6 December 2013 22:44, Murray, Gregory <[email protected]> wrote: >> Hi David, >> >> Thanks for the suggestions. I see what you mean about exploding and >> reconstructing the search terms. That's essentially what I'm doing now. I >> take something like >> >> (encyclopedia OR dictionary) AND (music OR musicology) >> >> tokenize it, and convert it to >> >> (title:encyclopedia OR title:dictionary) AND (title:music OR >> title:musicology) >> >> whenever the search needs to be constrained only to book titles. It just >> seems rather awkward. As for the programming language, the queries are set >> up using XQuery. In fact, it's a web application and all server-side logic >> is done in XQuery. >> >> Thanks, >> Greg >> >> >> On Dec 6, 2013, at 2:02 AM, David Ennis wrote: >> >>> HI. >>> >>> Since there are soo many ways to search, I am sure you'll get back plenty >>> of feedback. However, a few notes: >>> >>> If I understand what you want, then I believe the cts search items are more >>> than robust - combination of and/or queries and field/element queries >>> depending on how your constraints are set up. The important key here is >>> that in most (if not all) instances of the $text parameter for these >>> queries accept one or more terms as input and are treated as "any term >>> matching". SO, you could have your terms in a sequence and pass this on as >>> the values. >>> >>> something like this: >>> >>> let list1:= ("dictionary", "encyclopedia") >>> let list2:= ("music", "musicology") >>> >>> return cts:search(cts:and-query( >>> cts:element-value-query(xs:QName("title"), $list1), >>> cts:element-value-query(xs:QName("title), $list2) >>> )) >>> >>> This above will nto run as-is as you need to look at parameters for the >>> settings and perhaps you are searching on a field, etc- but should give you >>> a good primer on the begining ov building complex queries with CTS >>> >>> ########### >>> Separately, as a programmer, I see the issue as manageable in your current >>> use of the search:search approach. >>> Building up your parameters and then exploding them into strings with the >>> proper glue should give you some ease. What language are you preparing >>> your queries in? >>> >>> Regards, >>> David >>> >>> >>> On 6 December 2013 00:49, Charles Greer <[email protected]> wrote: >>> Hi Greg, >>> >>> If you want all prefixless searches to be scoped to a particular >>> element, use the <term> configuration >>> >>> <term> >>> <default> >>> <word> >>> <element ns="" name="title"/> >>> </word> >>> </default> >>> </term> >>> >>> I don't see a way to do exactly what you're looking for however. >>> >>> Charles >>> >>> >>> On 12/04/2013 11:27 AM, Murray, Gregory wrote: >>>> I'm using the Search API, where it's easy enough to set up a word >>>> constraint for a given element and then use the key:value syntax to search >>>> only the values of that element, like so: >>>> >>>> <constraint name="title"> >>>> <word> >>>> <element ns="http://example.com/ns"; name="title"/> >>>> </word> >>>> </constraint> >>>> >>>> Then you can search for title:whatever to find titles containing the word >>>> "whatever". This works great, but it's cumbersome for multi-word searches. >>>> For example, if I want titles containing both "sound" and "fury", I have >>>> to search for this: >>>> >>>> title:sound title:fury >>>> >>>> It gets worse with situations like this: >>>> >>>> (title:encyclopedia OR title:dictionary) AND (title:music OR >>>> title:musicology) >>>> >>>> Before I dig into trying to customize the search grammar or some such -- >>>> is there an easier way to perform a word search while applying the >>>> *entire* search expression only to a given element? >>>> >>>> Thanks, >>>> Greg >>>> >>>> _______________________________________________ >>>> General mailing list >>>> [email protected] >>>> http://developer.marklogic.com/mailman/listinfo/general >>> >>> -- >>> Charles Greer >>> Senior Engineer >>> MarkLogic Corporation >>> [email protected] >>> Phone: +1 707 408 3277 >>> www.marklogic.com >>> >>> _______________________________________________ >>> General mailing list >>> [email protected] >>> http://developer.marklogic.com/mailman/listinfo/general >>> >>> _______________________________________________ >>> General mailing list >>> [email protected] >>> http://developer.marklogic.com/mailman/listinfo/general >> >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
