Changes between Version 38 and Version 39 of FCS-Endpoints

Timestamp:

09/10/12 10:36:30 (12 years ago)

Author:

vronk

Comment:

updated to reflect CenterRegistry? and CenterProfile?

FCS-Endpoints

@@ -1 +1 @@
 = Repository Registry =
-We need a service/registry that informs about the available repositories. 
+''Note: better rename page to: '''FCS-Endpoints'''?''
 
-Until we have that formalized, we will collect the information about individual providers here.
+This page was started to preliminary collect information about individual repositories/centers/providers/endpoints wrt [[FederatedSearch]]. Meanwhile there is the CenterRegistry, that collects and provides the information about the available repositories. This information is encoded as a dedicated CMDI-record according to the [[http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/profiles/clarin.eu:cr1:p_1320657629667/xsd|CenterProfile]] [`clarin.eu:cr1:p_1320657629667`]. Note, that these centers' descriptions are not restricted to the FCS-endpoints, but shall describe - besides organizational/administrational information - all services available at given center (including FCS).
 
 == Implementing Endpoints ==
@@ -91 +91 @@
 As already the above list suggests, simple list of endpoints will not be enough. Even if we try to rely as much as possible on the auto-configuration based on the explain record, additional information (''Metadata'') needs to be stored and provided.
 
-So one obvious choice would be to define a CMD-Profile '''for the Repositories'''. 
-This profile would carry only the minimal necessary primarily technical information. In particular it shouldn't provide any information about the data provided, but rather link to separate MDRecords of a collection or a resource, that would provide information like `ResourceType`, `Language`, available `AnnotationTiers`, `Time/Space Coverage` etc.
+For this, a separate service was conceived and implemented - the CenterRegistry -, together with a dedicated CMD-Profile '''for describing the Repositories''' the [[http://catalog.clarin.eu/ds/ComponentRegistry?item=clarin.eu:cr1:p_1320657629667|CenterProfile]]. This profile stores besided organizational information, mainly the endpoints to available services of given center (and minimal technical details).
 
-We also have to beware of a big semantic/functional overlap of such a `Repository`-MDRecord and the `SRU-explain`-response of given service and '''TODO:''' have to clarify the interaction and dependencies.
+''(Sidenote: There is a semantic/functional overlap of such a CMD record for the endpoint and the `SRU-explain`-response of given service. [[BR]]'''TODO:''' have to clarify the interaction and dependencies. )''
 
-Following is a proposal of a sample `Repository`-instance:
+Following is a snippet of a `CenterProfile` linking to the FCS-endpoint:
 {{{
- <CMD>
-   <Resources>
-     <ResourceProxyList> <!-- should refer to collections or resources that are reachable by given Repository. -->
-       <ResourceProxy id="mpi-subcorpus">
-         <ResourceType>Metadata</ResourceType>
-         <ResourceRef>{collection-handle}</ResourceRef>
-            </ResourceProxy>
-        </ResourceProxyList>
-   </Resources>
-   <Components>
-     <Repository>
-        <GeneralInfo>
-           <ID>?</ID>
-           <Name>MPI corpus</Name>
-           <Description>MPI Corpora: ESF, CGN, ...</Description>
-        </GeneralInfo>
-       <Endpoint>
-         <URL>http://cqlservlet.mpi.nl/</URL>
-         <type>SRU</type>
-         <Views>
-            <view>text</view>
-         </Views>
-       </Endpoint>
-       <Endpoint>
-         <URL>http://corpus1.mpi.nl/ds/imdi_browser/</URL>
-         <type>WebApp/User Interface</type>
-       </Endpoint>
-      </Repository>
-   </Components>
- </CMD>
+#!xml
+ <WebReference>
+   <Website>http://weblicht.sfs.uni-tuebingen.de/rws/sru/</Website>
+   <Description>CQL</Description>
+ </WebReference>
 }}}
 
-=== indexdata solution ===
-Indexdata/Masterkey framework (from which we are exampine the Pazpar2-component as aggregator) provides [[http://www.indexdata.com/irspy|IRSpy]] (GPL) and [[http://www.indexdata.com/masterkey|Torus]] (seems proprietary).
+There is ongoing discussion, how much information about the data provided should be included in these description (foremost example being the `Language`), as the data is actually already described in separate CMD records.
+So it would be "cleaner" to just link to separate CMD records of a collection or a resource, that would provide information like `ResourceType`, `Language`, available `AnnotationTiers`, `Time/Space Coverage` etc. However that would put an undue burden on the side of the aggregator/client, that would have to crawl through and resolve multiple metadata records, plus be able to make sense of the heterogeneous structure of the CMD records, to get to the required information. Thus for now, `Language` (and possibly a few other basic fields) will be added into the endpoint-description. But there are plans (and prototyping work at Meertens) to '''combine the metadata and content search''', that would allow to filter the content search on any metadata query.
+
+To support the metadata/content search, there is an alternative way of announcing the FCS-endpoint, by adding a [[http://trac.clarin.eu/wiki/FCS-specification#ReferringtoanSRUendpointfromaCMDIfile|`SearchService-ResourceProxy`]]
+into the CMD record of any collection/resource.
+Because the SearchService-Proxy leads just to the "nearest" endpoint, 
+if the endpoint exposes multiple resources, it has to accept the parameter `x-context`, to restrict the search to given resource. A client/aggregator invoking a search for given resource, passes the PID of the resource as `x-context` parameter.
 
 == Further (future) Issues ==