search

opengeospatial / ets-cat30

OGC Catalogue 3.0 Conformance Test Suite
Other
0 stars 6 forks source link

How are csw:AnyText rules defined? #3

Closed mhogeweg closed 9 years ago

mhogeweg commented 9 years ago

the scope and semantics of csw:AnyText syntax in CSW 3.0 needs to be defined:

rjmartell commented 9 years ago

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:

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)?

rjmartell commented 9 years ago

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")
rjmartell commented 9 years ago

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.

rjmartell commented 9 years ago

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

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

mhogeweg commented 9 years ago

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.