| 47 | | Following description is a bit outdated. The interfaces are actually meanwhile [CmdiRepositoryImpl implemented by MDRepository]. MDService naturally provides semantically equivalent interfaces, which are better (more uptodate) described in [source:MDService2/trunk/MDService2/docs/MDService2.wadl WADL] [source:MDService2/trunk/MDService2/docs/MDService2.wadl.html WADL - html version]. |
| 48 | | |
| 49 | | {{{ |
| 50 | | .getCollections() |
| 51 | | /* lists the hierarchical structure of MD-collections the MD-records are grouped in */ |
| 52 | | .queryModel() |
| 53 | | /* could replace all previously proposed interfaces regarding the meta-model: |
| 54 | | .elements(), values(), components(), query_builder(), |
| 55 | | .listSchemas(), .listDimensions(), .listVocabularies(), .stats(), .countMetadataEntries() |
| 56 | | */ |
| 57 | | .searchRetrieve(query, result_options) |
| 58 | | /* would replace .query() - conforming to SRU-protocol */ |
| 59 | | }}} |
| | 47 | There was a longer development of the interface specification for MDRepository/MDService. There was: |
| | 48 | * the '''initial''' proposal by Daan (2009-10)[[BR]] |
| | 49 | with the operations `.elements(), .values(),` |
| | 50 | * 1st version ('''extension''') by Matej [[BR]] |
| | 51 | with `.listSchemas(), .listDimensions(), .listVocabularies(), .stats(), .countMetadataEntries() ...` |
| | 52 | * "'''consolidated'''" version by Matej:[[BR]]`.getCollections(), .queryModel(), .searchRetrieve(query, result_options)` [[BR]] |
| | 53 | this is set of operation is currently implemented by MDRepository |
| | 54 | * based on the consolidated version a "'''convenience'''" interface of MDService evolved with:[[BR]] |
| | 55 | `.collections(), .model(), .terms(), .recordset(), .record()` |
| | 56 | |
| | 57 | Following table tries to give an overview of correspondence between these and especially also the relation to the actual standard '''SRU/CQL''', we want to conform to: |
| | 58 | || ''Daan'' || ''consolidated (MDRepo)'' || ''convenience (MDService)'' || ''SRU/CQL'' || |
| | 59 | || || `getCollections` || `collections` || (`explain`, Zeerex)? || |
| | 60 | || `elements`|| `queryModel` || `model`, `terms` || `explain` || |
| | 61 | || `values` || `queryModel` || `model`, `terms` || `scan` || |
| | 62 | || || `searchRetrieve` || `recordset`, `record` || `searchRetrieve` || |
| | 63 | |
| | 64 | |
| | 65 | With current state of implementation, the ''"consolidated"'' interface-version implemented by the MDRepository presents the factual core. MDService builds upon this providing semantically equivalent but richer interface (mainly wrt formatting), which is described in [source:MDService2/trunk/MDService2/docs/MDService2.wadl WADL] |
| | 66 | [http://trac.clarin.eu/export/1033/MDService2/trunk/MDService2/docs/MDService2.wadl.html WADL-html] |
| | 67 | |
| | 68 | The following subchapters concentrate on the description of the three operations of the ''"consolidated"''-interface, preceded by a chapter about situation and plans regarding SRU/CQL-compliance. |
| | 69 | |
| | 70 | `getCollections()`:: |
| | 71 | provides information the hierarchical structure the md-records are grouped in. |
| | 72 | `queryModel()`:: |
| | 73 | provides information about the metadata (meta-model?), ie which components/elements/values are used in the repository. As query-parameter it only needs to accept/understand `cmdIndex`. |
| | 74 | `searchRetrieve()` :: |
| | 75 | is the core operation to retrieve the actual MDRecords. In the `query`-parameter it has to accept any query on metadata. |
| | 76 | |
| | 77 | === Notes on MDService’s SRU/CQL-standard compliance === |
| | 78 | Although the interface specification was inspired by the SRU/CQL protocol, during the prototyping phase unfortunately an idiosyncratic interface evolved (see ''"consolidated"'' and ''"convenience"'' mentions above), MDRepository and MDService currently exposing their own set of operations. Thus at the moment MDService can’t claim conformance with SRU/CQL standard. |
| | 79 | However we are still committed to this goal and we have substantial partial solutions: MDService accepts the query in CQL-format (even parsing it, ensuring the syntactic validity) and returns a `<searchRetrieveResponse>` result as defined by the protocol. |
| | 80 | |
| | 81 | An example: `title contains system` in [http://clarin.aac.ac.at/MDService2/recordset/xml?q=%20%28%20%20%28%20title%20contains%20system%29%20%20%29%20&startRecord=1&maximumRecords=10&repository=1 MDService] |
| | 82 | |
| | 83 | The result comes in the standard-compliant format already from MDRepository, which however expects the query in XPath and there is also no plan for the MDRepository to accept SRU/CQL-queries, thus MDRepository is not to be expected SRU-conformant. |
| | 84 | |
| | 85 | The main missing part is the appropriate REST-interface accepting the defined parameters. As MDservice exposes this own set of operation optimized mainly for the use by the web-application (MDBrowser), the plan is to provide an additional separate interface exposing the SRU-operations, mapping these operations internally to appropriate processing. |
