Changes between Version 3 and Version 4 of FCS-specification


Ignore:
Timestamp:
04/17/12 12:06:45 (12 years ago)
Author:
dietuyt
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FCS-specification

    v3 v4  
    107107We foresee the scan operation as a way of signaling to the calling program/user/aggregator the available resources available for searching at the endpoint. This in contrast to the definition in SRU, where scan is a way to browse a list of keywords. The value of the scanClause parameter should be '''fcs.resource'''.
    108108
    109 To this the endpoint will return a list of terms, which are searchable collections. Their identifiers can than be used to restrict the search by passing one (or more) as parameters in x-cmd-context in the searchRetrieve operation.
     109To this the endpoint will return a list of terms, which are searchable collections. Their identifiers can than be used to restrict the search by passing one (or more) as parameters in x-context in the searchRetrieve operation.
    110110
    111111Again, we provide a telling example:
    … …  
    136136Note that the values in the sru:value elements should be valid [http://www.clarin.eu/faq/3460 MdSelfLink]. These MdSelfLinks should also be available from within the matching CMDI metadata file (via a reference in the Header section - see also below under "Restricting the search").
    137137
     138'''Note:''' Giving an answer to the scan operation with the query fcs.resource is obligatory. Even if there is only 1 collection available, in that case the endpoint returns only one term.
     139
    138140Additionally it is possible (but not obligatory) to perform extra Scan operations to retrieve subcollections, as in a [http://en.wikipedia.org/wiki/Tree_traversal tree traversal] algorithm.
    139141
    … …  
    169171}}}
    170172
    171 
    172 === SearchRetrieve ===
    173 
    174 The SearchRetrieve operation is the operation that is used for searching in the resources that are provided by the endpoint. The responds provides an XML wrapper to a set of results. Here we follow the SRU standard (verison 1.2) down to the <sru:record> elements. Each <record> represents one hit of the query on the data.
     173So in this scan response the endpoint announces that the CGN-Corpus (identified with the unique MdSelfLink hdl:1839/00-0000-0000-0001-53A5-2) has 3 subcollections:
     174
     175 * Annotation types (containing 300 elements, identified by the MdSelfLink hdl:1839/00-0000-0000-0003-467E-9)
     176 * Components (containing 400 elements, identified by the MdSelfLink hdl:1839/00-0000-0000-0003-4682-F)
     177 * Regions (containing 350 elements, identified by the MdSelfLink hdl:1839/00-0000-0000-0003-4692-D)
     178
     179These results can then later on be used to restrict a content search to one (or more) (sub)collections.
     180
     181=== !SearchRetrieve ===
     182
     183The !SearchRetrieve operation is the operation that is used for searching in the resources that are provided by the endpoint. The responds provides an XML wrapper to a set of results. Here we follow the SRU standard (verison 1.2) down to the <sru:record> elements. Each <record> represents one hit of the query on the data.
    175184
    176185Within each record we use our own XML structure that matches the concept of searchable resources. Each record contains one resource. The resource has a PID. The correct resource to return here is the most precise unit of data that is directly addressable as a “whole”.  This resource might contain a resourceFragment. The resourceFragment has an offset, i.e., a resource fragment is a subset of the resource that is addressable. Using a resourceFragment is optional, but encouraged.