Tight and loose queries Property references

10.8.4.11.3 Precedence

The XML notation does not provide parentheses to indicate operator precedence as specified in the BNF. The Filter Specification uses the nested structure of the XML notation to indicate this relationship. In this example, a more complex scalar predicate is encoded using the logical operators AND and OR. The example is equivalent to the expression FIELD1=10 OR FIELD1=20 AND STATUS=VALID: Filter xmlns=http:http:www.opengis.netogc xmlns:foo=“http:www.someverser.comfoo” And Or PropertyIsEqualTo PropertyNamefoo:FIELD1PropertyName Literal10Literal PropertyIsEqualTo PropertyIsEqualTo PropertyNamefoo:FIELD1PropertyName Literal20Literal PropertyIsEqualTo Or PropertyIsEqualTo PropertyNamefoo:STATUSPropertyName LiteralVALIDLiteral PropertyIsEqualTo And Filter

10.8.4.11.4 Tight and loose queries

The following examples show the implementation of tight and loose queries using the Filter Grammer. 8 In both cases the query is directed to a federation of image catalogs that are compliant to an application profile where an optional searchable attribute “cloudcover” is defined as the percentage of the target obscured by clouds. In Case 1 the investigator wants to get only images he is sure he can use so he requests only images where the cloud cover is less than 5 percent. This is the normal case for querying known schema. ogc:Filter xmlns:ogc=http:http:www.opengis.netogc ogc:PropertyIsLessThan ogc:PropertyNamecloudcoverogc:PropertyName ogc:Literal5ogc:Literal ogc:PropertyIsLessThan ogc:Filter 8 This capability is included in future version 1.2 of the OGC Filter Encoding Specification. Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 153 In Case 2 the investigator is aware that 5 cloud cover is very rare over the target area but he requires only images with less than 5 cloud cover. In this case he wants any images he might be able to use so he requests images which meets his criteria and images where cloud cover in unknown because the catalogue has chosen not to include cloudcover in its searchable attribute set. ogc:Filter xmlns:ogc=http:http:www.opengis.netogc ogc:Or ogc:PropertyIsLessThan ogc:PropertyNamecloudcoverogc:PropertyName ogc:Literal5ogc:Literal ogc:PropertyIsLessThan ogc:PropertyValueDoesNotExist ogc:PropertyNamecloudcoverogc:PropertyName ogc:PropertValueDoesNotExist ogc:Or ogc:Filter

10.8.4.11.5 Property references

The ogc:PropertyName element is used in Filter expressions to reference properties from the information model of a catalogue. If the catalogues information model is being realized as an XML document with an accompanying XML Schema, then XPath expressions shall be used to reference the various metadata properties. This is the case when the core metadata properties that are realized as an XML document, using XML Schema, as described in Subclause 10.2.5. This implies the XPath expressions shall be used to reference the various core metadata properties in Filter expressions. This is also the case for predicates encoded using CQL text if the predicates reference the XML realization of the core metadata properties. EXAMPLE 1 The following examples shows an XPath expression being used in a Filter to reference one of the core queryable properties described in Subclause 10.2.5. … csw:Query typeNames=csw:Record csw:Constraint ogc:Filter ogc:PropertyIsBetween ogc:PropertyNamecsw:Recorddct:modifiedogc:PropertyName ogc:LowerBoundary ogc:Literal2006-01-01ogc:Literal ogc:LowerBoundary ogc:UpperBoundary ogc:Literal2006-05-30ogc:Literal ogc:UpperBoundary ogc:PropertyIsBetween ogc:Filter csw:Constraint csw:Query … This following is the same expression represented using CQL text but referencing the XML realization of the core metadata properties. 154 Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. … csw:Query typeNames=csw:Record csw:Constraint CqlTextcsw:Recorddct:modified BETWEEN 2006-01-01 AND 2006-05- 30CqlText csw:Constraint csw:Query … In certain cases, such as when the typeNames attribute on the Query element only contains the name of a single entity, the root path step may be omitted since the catalogue is able to infer what the first step in the path would be. EXAMPLE 2 This is same example as above but using an inferred initial path step. … csw:Query typeNames=csw:Record csw:Constraint ogc:Filter ogc:PropertyIsBetween ogc:PropertyNamedct:modifiedogc:PropertyName ogc:LowerBoundary ogc:Literal2006-01-01ogc:Literal ogc:LowerBoundary ogc:UpperBoundary ogc:Literal2006-05-30ogc:Literal ogc:UpperBoundary ogc:PropertyIsBetween ogc:Filter csw:Constraint csw:Query … The CQL text encoding of the same query would be: …csw:Query typeNames=csw:Record csw:Constraint CqlTextdct:modified BETWEEN 2006-01-01 AND 2006-05-30CqlText csw:Constraint csw:Query … Annex F describes the minimum subset of XPath that catalogues implementing the HTTP protocol binding shall support. 10.8.4.12 SortBy parameter The result set may be sorted by specifying one or more metadata record elements upon which to sort. In KVP encoding, the SORTBY parameter is used to specify the list of sort elements. The value for the SORTBY parameter is a comma-separated list of metadata record element names upon which to sort the result set. The format for each element in the list shall be either element name:A indicating that the element values should be sorted in ascending order or element name:D indicating that the element values should be sorted in descending order. Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 155 For XML encoded requests, the ogc:SortBy element is used to specify a list of sort metadata record elements. The attribute sortOrder is used to specify the sort order for each element. Valid values for the sortOrder attribute are ASC indicating an ascending sort and DESC indicating a descending sort.

10.8.4.13 DistributedSearch parameter