How are csw:AnyText rules defined? about ets-cat30 HOT 5 CLOSED

The AnyText "pseudo-property" is beyond the scope of tests for the Basic and OpenSearch conformance classes currently under development. However, it may be that the same constraints should apply to basic KVP text searches using the 'q' query parameter (Table 6: KVP encoding for query constraints).

Requirement-030 stipulates that the domain of AnyText is "all text fields in the catalogue record". Now, OGC 10-032r8 (OGC OpenSearch Geo and Time Extensions) suggests (see Table 4) that searchTerms be matched against the content of the following record elements:

• dc:title, atom:title
• dc:description (dct:abstract), atom:summary
• dc:subject, atom:category

Since this is a normative reference, should this restriction apply to all basic text searches even though the CSW3 spec imposes fewer restrictions on the scope of AnyText for "advanced" queries (i.e. Filter-FES-KVP-Advanced)?

from ets-cat30.

None of the relevant specs appear to have anything to say about:

1. Case sensitivity of matching;
2. Handling of multiple terms (e.g. treat them as a phrase or as separate terms with some implied boolean operator).

I suggest doing the the following for basic text searches:

1. Matching is case-insensitive.
2. Treat multiple terms as a phrase (e.g. "San Francisco")

from ets-cat30.

Then again, consider how search terms are interpreted by the Google search engine. Multiple terms are combined by an implicit AND operator. And Google searches are not case-sensitive.

Perhaps this would be sensible default behavior in keeping with the POLA.

from ets-cat30.

Basic text search using the q parameter is expected to be processed as follows:

• match against all record fields with simple content
• matching is case-insensitive
• multiple terms are combined by an implicit AND

Perhaps "advanced" text search using csw:AnyText will enable more complex queries.

from ets-cat30.

The update to the spec is good (it makes it more explicit). The test needs to be updated as well, since what is returned in the response (brief, summary, …) may not include all of the record fields with simple content. The test can therefore not fail a response if that response did not include one of the terms provided in the request.

from ets-cat30.