| 746 | | Add discussion here. |
| | 746 | Thomas Eckart: some questions and remarks |
| | 747 | * In the 'Basic profile' section it is stated that 'Endpoint must not silently accept queries that include CLQ features besides term-only and terms combined...'. What would be the desired action then (issuing a diagnositic?)? |
| | 748 | * Do we really want to force every endpoint to support the Generic Hits dataview? For some resources there may be no 'literal text' (like audio, video, highly specific annotation formats) which could lead to some ugly string serialization instead of using custom extensions and which would leave the client with the interpretation of the output. |
| | 749 | * Do we want to specify additional payloads for resource types like audio and video (referenced, attributes: mimetype + optional offset information)? |
| | 750 | * Is it a good idea to specify the capabilities of an endpoint by using profile names (where only one is allowed in the explain response)? In the past it was planed to use some 'feature matrix' to reflect the differences in supported functionality for the endpoints. This would allow to explicitly state which subset of possible functionalities (besides the basic stuff) is supported by an endpoint. |
| | 751 | * The endpoint specification contains information about supported profile and dataviews. This is no problem for an endpoint with only one resource or homogenous resources. When we extend the profile by adding information about annotation tiers this may not be applicable for all provided resources (like an endpoint that provides two corpora, where only one is annotated with POS tags). So maybe some of this information is not specific for the endpoint but for the resource. |
| | 752 | * The current (old) solution for exposing granularity and structure of supported collections is a multiple-staged mechanism: the client queries for the first-level structure (=collections) and can explicitly ask the endpoint to give additional information about the internal structure of these collections (and so on...). This is very helpful for endpoints which support queries on detailled subcollections. The proposed solution above would force the endpoint to expose the complete structure of all provided resources in the explain response, which would lead (for example for the endpoint in Leipzig) to very large responses. |
| | 753 | * For endpoints that support many collections it can be a problem to force them to allow unrestricted queries regarding resource selection. In these cases every query would lead to a high load on the local search engine. Instead I would prefer to at least allow using a default collection if no restrictions are provided by the client. |
