OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (ODATA-1100) Add mechanism for specifying match type for $search

     [ https://issues.oasis-open.org/browse/ODATA-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-1100:

Add “search modifiers” which consist of a letter sequence immediately followed by a colon and immediately followed by anything except space, parentheses, and an ampersand

searchTerm   = searchModifier / [ 'NOT' RWS ] ( searchPhrase / searchWord )
searchPhrase = quotation-mark 1*qchar-no-AMP-DQUOTE quotation-mark

searchModifier = searchOperator COLON searchOperand
searchOperator = 1*ALPHA
; A searchOperand is a sequence of anything except ampersand, space, and parentheses, in clear-text or percent-encoded
; Expressing this in ABNF is somewhat clumsy, so the following rule is overly generous.
searchOperand  = 1*qchar-no-AMP-parens

This would allow expressing e.g. a fuzziness factor or a matching algorithm

$search=hello fuzzy:0.8 match:synonym

Alternative: restrict search operands to search phrases (enclosed in double quotes) and search words:

searchOperand = searchPhrase / searchWord

> Add mechanism for specifying match type for $search
> ---------------------------------------------------
>                 Key: ODATA-1100
>                 URL: https://issues.oasis-open.org/browse/ODATA-1100
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: Protocol
>    Affects Versions: V4.01_CSD02
>            Reporter: Mark Biamonte
>            Assignee: Mark Biamonte
>             Fix For: V4.01_CS01
> When doing text searches, many of the common algorithms we use have a number of different ways to define a match (Exact match, begins with, synonym, base word or inflection, etc).  The spec currently says it is up to the implementation as to what constitutes a match, this is fine, but in the case where the search algorithm provides different matching types it would be nice if the query writer could specify the type of match they want in the $search expression.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]