FCS Specification Scrapbook

Issues with current document

1. Uncomprehensible and not well structures :(
2. Resource enumeration (aka scan on fcs.resource) rather complex and unintuitive
3. Basic KWIC records has no provision for multiple "highlight" hits
4. Clear recommendation for using Resource and ResouceFragment

General ideas / design goals towards better specification

1. Define FCS conformance level independent of what SRU/CQL do. Don't call them "level", but maybe something like profile to avoid confusion.
   1. Do a basic profile first
   2. Do an advanced/extend profile later in a separate specification or specification amendment (which must be, of course, compatible to basic profile)
   3. Add provisions to, e.g. explain output, to allow endpoints to indicate the profile, they support
2. Better structure of document (and don't include aggregation stuff; that's a different specification; implementors of endpoints should not need to worry about aggregator implementation)
3. Keep XML sanity always in mind (so there are no namespace issues as in CMDI)
4. Honor and use extension hooks provided by SRU/CQL

Proposal for new specification

The following is a proposal for a revisited federated content search specification. When done, cut and paste to the appropriate section of the Wiki and publish on the CLARIN web page.

CLARIN Federated Content Search (CLARIN-FCS)

Introduction

Yada yada yada ...

Glossary

Yada yada yada ...

Profiles

Yada yada yada ...

SRU/CQL

Yada yada yada ...

Explain

Yada yada yada ...

Scan

Yada yada yada ...

SearchRetrieve

Yada yada yada ...