= Search Context =
Allow to restrict the content search on specific !Repositories/Collections/Resources.

We propose an extension parameter in the protocol:
{{{
  ?x-cmd-context={list[PID]}
}}}

This has following aspects:
 extensional ::
  the requesting client provides a list of identifiers as a filter.[[BR]]
  This requires an index of collections/resources exposed by the Content Provider, which could/should be done via publishing the MD-Records.
 intensional ::
  the client restricts the query by some MD filter expressed as part of the combined MD/Content-query. The extension parameter is not used/supported.[[BR]]
  See more in [[CDMDC]].
 on individual Repository :: 
  the default use of the extension parameter: Restrict the search to selected (sub-)collections or resources within the repository, by providing an explicit list of `PID`s.
 on the aggregating component ::
  which additionally needs to know the mapping between collections/resources and the repository they are provided by.
  That means that value of `x-cmd-context` would have to be of the form:
{{{
 list[Repository-endpoints 
         list[Resource-PIDs]
     ]
}}}
  Based on this information the Aggregator-component could formulate the requests for individual endpoints, passing the corresponding `Resource-PID`s in the `x-cmd-context`-parameter.

== Scenarios how to get to a resource ==
 link to resource ::
  the (resolvable) Resource-handle anywhere, send by email etc.
  Content Provider is responsible for suitable displaying.
 {{{ 
   
 }}}
 MDRecord with resolvable Resource-handle ::
  MDRecord for given Resource is published (via harvesting within CMDI-Infrastructure) 
  User can search by metadata and traverse from MD-Record in the MD-result to the Resource.
  The resource could be either reached again by resolving/following the Resource-handle or
  the MD-Search component could handle the resource-link to redirect it to a viewer. The decision which viewer to use for which resources, would be configured within the MD-Search component (user-customizable) and based e.g. on the CMD-Profile of the MDRecord.

 Content query ::
  The user performs a (federated) content search and as a result is provided with a KWIC-list, where each hit is pointing to the originating Resource.
  A sensible option seems to be to group the result by Resource. See more about [[FCS-spec#DataViews|KWIC-DataView]].

 Resource not accessible ::
  The critical question is, how to handle situations, where the Resource is not accessible at all (i.e. irrespectively of access-rights).
  This is often the case for written corpora, where the individual texts of the corpus are not available directly.
  Optimally this situation shouldn't arise at all - if there is Metadata-record it should contain a link to the resource (or any sensible proxy) and if the resource itself is not accessible (like a piece of text in a big text-corpus), it shouldn't be announced by a separate MD-Record to the outer world at all. 
  But if it still occurs, possible solutions are:
   * Link to the MD-Record of the resource
   * Link to the MD-Record of the parent collection
   * Link to a part of the Resource that is available (Sometimes in a text-corpus at least a bit bigger context-snippet around the keyword is available.)

== Corpus as a Resource ==
As mentioned in previous chapter (under ''Resource not accessible'') if individual items of a corpus are not accessible at all, they '''shouldn't''' be exposed via corresponding MD-Records. In such cases it seems more practical to provide '''just one''' MD-Record for the whole corpus, describing the corpus as whole, including coverage across various dimensions (time, space, genre) and linking to an endpoint, where the corpus can be searched in.