Nicky I have set up a proxy for our Landcare LSIDs and it is just a plain redirect (ie treating the LSID as a string). This was probably mainly because I was experimenting and not implementing a "robust" system. However I don't really see anything wrong with treating the LSID as a string in this case - other parts of DNS and resolution treat various "components" of the resolution process as strings, without assuming any specific protocol etc.
As Rod pointed out though, if you use full LSID resolution on the proxied LSID, then you will be able to resolve any LSID that is passed to the IPNI resolver. I'm not sure this is a good thing though?? ie
should http://zoobank.org:80/?lsid=urn:lsid:ipni.org:names:20012728-1:1.1 return metadata or an error? the proxied URI http://zoobank.org:80/?lsid=urn:lsid:ipni.org:names:20012728-1:1.1 is NOT the sameAs the LSID urn:lsid:ipni.org:names:20012728-1:1.1, so it probably should return an error?? But this sounds counter-productive to me...
I'd say go with whatever is easiest for now.
Kevin
-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Nicola Nicolson Sent: Wednesday, 22 April 2009 4:41 a.m. To: tdwg-tag@lists.tdwg.org Subject: [tdwg-tag] LSID HTTP Proxy - design question
Hi,
I've been looking into setting up an HTTP proxy for the ipni.org LSIDs. I've read the usage recommendations at http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRecommendation but want to ask a question re the design of the proxy itself, ie: Should an HTTP proxy for LSIDs behave as: (1) a webapp that acts as an LSID "client" or (2) a mechanism to issue redirects to the metadata address as specified in the LSID authority WSDL The latter is simple - I can just set up a mod_rewrite rule so that http://lsid.ipni.org/%5Blsid] is redirected to the HTTP URL for the metadata for the specified LSID. This will of course only work for LSIDs for which ipni.org is the authority, but I think that is OK. If the former, I'll need to encode the resolution process: ie parse the LSID, extract the authority, do the DNS lookup, get the WSDL, construct the address etc, BUT it will mean that the HTTP LSID proxy is dependent upon correct functioning of the LSID infrastructure (DNS SRV records, authority WSDL etc). I guess the TDWG LSID proxy behaves this way, but that is to be expected as it can be used as an HTTP proxy for *any* LSID. In summary option (1) treats the proxied LSID as *an LSID*, the other really just treats it as a character string. Which is preferred? cheers, Nicky
- Nicola Nicolson - Science Applications Development, - Royal Botanic Gardens, Kew, - Richmond, Surrey, TW9 3AB, UK - email: n.nicolson@rbgkew.org.uk - phone: 020-8332-5766 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz