<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">For your information,<div>the Mimore service currently supports search across three resources (MAND, SAND and DIDDD), so the x-context parameter is of direct interest to us as an endpoint parameter</div><div><br></div><div>Marc</div><div><br><div><div>On Aug 16, 2012, at 11:56 AM, Thomas Zastrow wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Matej,<br><br>Am 16.08.12 11:41, schrieb Matej Durco:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">haven't we introduced the x-context parameter exactly for this?<br></blockquote><blockquote type="cite">to allow to tell the endpoint, to query only again given corpus?<br></blockquote><blockquote type="cite">For this the endpoint has to expose the list of corpora (identified <br></blockquote><blockquote type="cite">with (P)IDs)<br></blockquote><blockquote type="cite">and subsequently be able to resolve the ID given in the x-context <br></blockquote><blockquote type="cite">parameter to corresponding corpus.<br></blockquote><br>Yes, you are right, but so far in practice not many endpoints are <br>supporting that functionality. But I have integrated it already in my <br>code now.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- have a collection record per endpoint (a CMDI giving a language list,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">modality, etc. for each corpus) to which we can refer in the center<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">registry or from the scan response<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think I would like the last option the most, as it is relatively<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">light-weight, not too hard to make and it would also be in the hands of<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the centers providing the end points (instead of being hardcoded). What<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">is your opinion?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I don't exactly understand what you mean, but I would think that it <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would be good to have all the necessary information at one point. I'm <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">parsing the center registry now to find the endpoints, can't we add <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">these information there:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><WebReference><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><Website>http://weblicht.sfs.uni-tuebingen.de/rws/cqp-ws/cqp/sru<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"></Website><Description>CQL</Description><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><lang>de</lang><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"></WebReference><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">When we are not storing information about individual corpora here, <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">every endpoint can only serve one language. But I think this <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">shouldn't be a problem because every center can define as many <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">endpoints as they want.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Perhaps we can agree, to handle language special, because of importance,<br></blockquote><blockquote type="cite">but generally I agree here with Dieter, that the conceptually most <br></blockquote><blockquote type="cite">sane because in line with existing infrastructure (CMDI) seems to be <br></blockquote><blockquote type="cite">to provide CMDI-records for collections<br></blockquote><blockquote type="cite">and establish links (via ResourceProxy ) between the endpoint and its <br></blockquote><blockquote type="cite">corpora/collections.<br></blockquote><blockquote type="cite">Especially because, later we will want to filter by other information <br></blockquote><blockquote type="cite">than language,<br></blockquote><blockquote type="cite">and where do we stop duplicating this information from the collection <br></blockquote><blockquote type="cite">records to the endpoint record?<br></blockquote><br>Yes and no - I'm implementing the aggregator at the moment and here I <br>need the information about the language to offer the user a possibility <br>to select in which language a query should run. The aggregator can be <br>configured in two ways:<br><br>a) from the "outer" world, for example the VLO can link from a specific <br>resource or bundle of resources directly to the aggregator. These <br>resources are then automatically preconfigured to be used in a query<br>b) second, the aggregator is also a (graphical) user interface to the <br>whole FCS. That means, that it has to offer all in the FCS available <br>resources to the user who then can decide which ones he will query. In <br>this case, I need the language information *directly* at the endpoints <br>because I don't want the aggregator to be another VLO-"engine" which <br>harvests CMDI files from all the centers ;-)<br><br>Yesterday, Oli proposed to use the "extraTermData" for that which makes <br>sense in my oppinion:<br><br><sru:extraTermData><br> <fcs-scan:lang xmlns:fcs-scan="<a href="http://ww.clarin.eu/fcs/scan">http://ww.clarin.eu/fcs/scan</a>"><br> de<br> </fcs-scan:lang><br><br> <!-- oder laternativ auch eine Variante mit mehren Sprachen --><br> <fcs-scan:langs xmlns:fcs-scan="<a href="http://ww.clarin.eu/fcs/scan">http://ww.clarin.eu/fcs/scan</a>"><br> <fcs-scan:lang>de</fcs-scan_lang><br> <fcs-scan:lang>nl</fcs-scan_lang><br> </fcs-scan:langs><br> </sru:extraTermData><br><br>Best,<br><br>tom<br><br><br>-- <br>Dr. Thomas Zastrow<br>Seminar fuer Sprachwissenschaft<br>Universitaet Tuebingen<br><br>Wilhelmstr. 19<br>D-72074 Tuebingen<br><br><a href="http://www.thomas-zastrow.de">http://www.thomas-zastrow.de</a><br><br>Tel.: 07071/29-73968<br>Fax: 07071/29-5214<br><br>_______________________________________________<br>Dev mailing list<br><a href="mailto:Dev@lists.clarin.eu">Dev@lists.clarin.eu</a><br>https://lists.clarin.eu/cgi-bin/mailman/listinfo/dev<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">***************************************************************<br>* Marc Kemps-Snijders<br>* Meertens Instituut (Afdeling Technische Ontwikkeling) <br>* Joan Muyskenweg 25 / <br>* Postbus 94264 <br>* 1090 GG Amsterdam<br>* tel. +31-(0)20-4628550<br> * <a href="mailto:marc.kemps.snijders@meertens.knaw.nl">marc.kemps.snijders@meertens.knaw.nl</a> <br>***************************************************************<br><br><br><br><br><br><br></div></span></span>
</div>
<br></div></body></html>