Talk:MetadataSearchAPI

= Metadata Search API Discussion page =

Feel free to add general questions, comments, suggestions, etc. to this page. You can also edit the API page for comments about specific portions of the API. Interested parties will be watching these Wiki pages and will get emails of updates.

Suggestion about Sorting

add asceding '+' and desceding '-' syntax to give more choice for user to control search results.

sorted[= [, ,…]]    -->    sorted[=[,,…]]


 * if attributes without + or -, it is as-is defined by current spec.


 * if attributes with + or -, the sorting results will be ascedant or descedant.

Suggestion about location based search capability

Use case:

Mobile Client send object search request with a specific location coodinates (X, Y) to retrieve pictures which are near to (e.g. distance less than D km) that location.

add a new query expression with function name and metadata name or ordered names as function arguments

e.g. distance(attrX, attrY) < delta

OR: distance(attrXY) < delta

Suggestion about HTTP Headers

In current spec, No HTTP Headers are described. So, for strictly, I suggest to describe clearly such as "No Request Headers are required."

And, For providing more useful information to client applications, I suggest to define the spec about HTTP Response Header. Especially, I suggest to define headers about the numbers related to the query, such as SoftLayer API.

Examples of the definition of response headers are as follows:

Suggestion about HTTP Response Code

In current spec, No HTTP Response codes are defined. So I suggest to define the response codes for each API operation status.

Examples of the definition of response codes are as follows:

Suggestion about Data Types

The proposal suggests each attribute has one of 3 types: string, numeric, date. How do we deduce the type for user metadata attributes i.e. object_meta_ attributes ? This is important for range searches since types such as dates are not sorted correctly when represented as strings. This seems to warrant a configuration file which contains schema information. In addition, using attribute naming conventions could help set the default behavior e.g. object-meta-start-date-d could refer to a date by default since it has the suffix -d. Also, additional types which seem important are a floating point type and a type for representing geo-spatial coordinates and/or general spatial information. Ideally the set of types which can be handled should be extensible.

Suggestion regarding System Metadata Regarding system metadata, many attributes are part of this proposal which are not currently part of Swift. There should be a minimal set of attributes - probably those attributes which are part of Swift - which should be available for indexing by all vendor implementations. Other than that, different vendors would have different requirements for generating new system metadata for indexing, and it probably shouldn't be a mandatory part of the API. Also, in general, the user should be able to control which user and system metadata attributes are indexed in order to control the amount of resources invested in metadata indexing/search.