Changes between Version 56 and Version 57 of FCS-Specification-ScrapBook

Timestamp:

02/17/14 16:26:56 (10 years ago)

Author:

teckart

Comment:

--

FCS-Specification-ScrapBook

@@ -744 +744 @@
 ----
 = Discussion =
-Thomas Eckart: some questions and remarks
+[[teckart|Thomas (ASV)]]: some questions and remarks
 * 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?)?
  * [[oschonef|Oliver (IDS)]]: Right, the desired action is to issue a diagnostic. We need to add that information to the text. In general, if something goes wrong, Endpoints shallissue appropriate diagnostic.
@@ -753 +753 @@
 * 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.
  * [[oschonef|Oliver (IDS)]]: The question is, what different functionality do we want to differentiate. And, of course, we need to encode these features for Clients. I think, the basic profile is quite clear in what Endpoints need to support. All the "interesting" (query expansion, data cats, etc) bits are nowhere clear enough to have them specified. I want to do this in the yet-to-be defined  "extended" profile, which could also foresee such a matrix. That could be, e .g. an additional list of `<feature>` elements that will be part of the endpoint description. However, I want to keep the distinction between a basic profile, which people can implement right ways, and more advanced stuff. We really need to have a normative spec.
+  * [[teckart|Thomas (ASV)]]: I absolutly agree. Just wanted to point out that maybe we already can think of how these features will be encoded (without a decision of what features will make it into the future extended specification).
 * 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.
  * [[oschonef|Oliver (IDS)]]: My aim was to consider the list of data views as a hint, what data views  are available at an Endpoint. The semantics is not, that ''every'' resource/collections supports all these data views. It's a little influenced by what SRU does in explain with `<zr:schemaInfo>`.  We could keep it this way, remove it of extend it, so this information can be given on resource/collection level 
+  * [[teckart|Thomas (ASV)]]: Right. We should at least think about it as this information could be quite relevant for the user experience in an aggregator.
 * 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.
  * [[oschonef|Oliver (IDS)]]: True, but the old approach is overly complex. If the response is large (> 100MB), so be it. An efficient Endpoint implementation should do an streaming approach when serializing the response and the Client should not assume, that the response to this information will fir in 1MB of memory. If it's is hard for the endpoint to compile this list (e.g. it requires complex database queries), it's IMHO again, a matter of the endpoint to cache this information (in memory or disk) and just stream it into the explain response.