| 24 | | 9. Do we to keep Geolocation (KML) as defined Data View in "basic" profile? |
| 25 | | 10. '''TODO''': Add to description/change wording of Generic Hits Data View, that it is intended as the ''lowest common denominator'' to serialize search results |
| | 24 | 9. Do we want to keep Images (IMG) and Geolocation (KML) as defined Data View in "basic" profile? |
| | 25 | |
| | 26 | == TODOs for the current draft / Preliminary items identified by discussion == |
| | 27 | 1. '''Generic Hits as lowest common denominator''': Add to description/change wording of Generic Hits Data View, that it is deliberately intended as the ''lowest common denominator'' to serialize search results (and therefore often is only be an approximation). |
| | 28 | 2. '''Restrict query scope''': By default, Endpoint should query all resources, if no `x-clarin-fcs-context` parameter is supplied by the Client (as described already in the draft). If that is for some reason ''not feasible/possible'' for an Endpoint, it MAY restrict the search to whatever scope it thinks it can handle ''and'' MUST issue a non-fatal diagnostics (URI tbd), like "collection set too large. query context automatically adjusted" (and include the PIDs of the collections comma separated in the details field. Furthermore, we should introduce a fatal diagnostic "collection set too large. cannot perform query" (URI tdb) to be issued by the Endpoint, if it feels the Client requested too many collections with `x-clarin-fcs-context`. \\ In FCS, we MUST avoid a situation, where an Endpoint needs special treatment (e.g. by unconditionally requiring `x-clarin-fcs-context`) to return any results. With the solution above, we could get at least some results and the Endpoint can indicate, that users need to "do more" to search broader. |
| | 29 | 3. '''Explicitly list supported Data Views by collection''': Amend the Endpoint Description to explicitly encode which Data Views are supported by a given collection. The semantics between parent-child is, that children `MUST` "inherit" the Data Views of the parent, i.e. a child collection must support all Data Views supported by the parent collection. Something along the lines of: |
| | 30 | {{{#!xml |
| | 31 | <ed:EndpointDescription xmlns:ed="http://clarin.eu/fcs/1.0/endpoint-description"> |
| | 32 | <ed:Profile>basic</ed:Profile> |
| | 33 | <ed:SupportedDataViews> |
| | 34 | <ed:SupportedDataView id="dv1">application/x-clarin-fcs-hits+xml</ed:SupportedDataView> |
| | 35 | <ed:SupportedDataView id="dv2">application/x-cmdi+xml</ed:SupportedDataView> |
| | 36 | <ed:SupportedDataView id="dv3">image/png</ed:SupportedDataView> |
| | 37 | </ed:SupportedDataViews> |
| | 38 | <ed:Collections> |
| | 39 | <ed:Collection pid="http://hdl.handle.net/4711/0815"> |
| | 40 | <!-- NB: regular stuff skipped --> |
| | 41 | <ed:SupportedDataViews ref="dv1" /> |
| | 42 | </ed:Collection> |
| | 43 | <ed:Collection pid="http://hdl.handle.net/4711/0816"> |
| | 44 | <!-- NB: regular stuff skipped --> |
| | 45 | <ed:SupportedDataViews ref="dv1 dv2" /> |
| | 46 | </ed:Collection> |
| | 47 | <ed:Collection pid="http://hdl.handle.net/1"> |
| | 48 | <!-- NB: regular stuff skipped --> |
| | 49 | <ed:SupportedDataViews ref="dv1 dv2 dv3" /> |
| | 50 | <ed:Collections> |
| | 51 | <ed:Collection pid="http://hdl.handle.net/1/1"> |
| | 52 | <!-- NB: regular stuff skipped --> |
| | 53 | <ed:SupportedDataViews ref="dv1 dv2" /> |
| | 54 | </ed:Collection> |
| | 55 | <ed:Collection pid="http://hdl.handle.net/1/2"> |
| | 56 | <!-- NB: regular stuff skipped --> |
| | 57 | <ed:SupportedDataViews ref="dv1 dv3" /> |
| | 58 | </ed:Collection> |
| | 59 | </ed:Collections> |
| | 60 | </ed:Collection> |
| | 61 | </ed:Collections> |
| | 62 | </ed:EndpointDescription> |
| | 63 | }}} |
| | 64 | 4. '''Endpoint Capabilities''': `<Capability>` elements in the Endpoint Description verbosely describe capabilities of an Endpoint in a more fine grained fashion than a Profile. A Profile is a collection of capabilities. Endpoint Description could look like the following: |
| | 65 | {{{#!xml |
| | 66 | <ed:EndpointDescription xmlns:ed="http://clarin.eu/fcs/1.0/endpoint-description"> |
| | 67 | <ed:Profile>basic</ed:Profile> |
| | 68 | <ed:Capabilities> |
| | 69 | <!-- capabilities should be identified by closed vocabulary; maybe encoded by URIs? --> |
| | 70 | <ed:Capability>http://clarin.eu/fcs/1.0/feature/basic-search</ed:Capability> |
| | 71 | <!-- actually the next would already be an extended capability beyond the basic profile --> |
| | 72 | <ed:Capability>http://clarin.eu/fcs/1.0/feature/query-expansion</ed:Capability> |
| | 73 | </ed:Capabilities> |
| | 74 | <!-- other EndpointDescription stuff ... --> |
| | 75 | </ed:EndpointDescription> |
| | 76 | }}} |
| | 77 | This is nor yet very useful for the ''basic'' Profile, but will be useful for ''extended'' Profile(s). |
| | 78 | 5. '''Need-to-Request Data Views''': Data Views will be classified into a "send-by-default" and a "need-to-request" class (which need to be documented in the spec analogous to the payload disposition). The first would indicate, that the Endpoint will include this data view unconditionally, e.g. the Generic Hits view. For the second class, a Client explicitly needs to request the Data View by using another custom query parameter (`x-clarin-fsc-request-dataviews`?) and supplying a (list of) data view(s). The Endpoint Description should also indicate to which class a data views to. This way, Endpoints could also indicate, that they e.g. always include some data view, that has been marked as "need-to-request" by the spec. This change would enable FCS to add/define Data Views that are too "expensive" (e.g. in terms of computational power or bandwidth) to generate for every request. |
| | 79 | |
