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/[lsid] 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
Dear Nicky, I would only regard (1) as a HTTP proxy, as it can take any LSID and resolve it. Hence, a proxy needs all the paraphernalia of DNS SRV, WSDL, etc. If you only want to provide a clickable link to the LSID metadata, then it's not really a proxy, it's a URL. I notice that Zoobank has URLs like this: http://zoobank.org:80/?lsid=urn:lsid:zoobank.org:act:6FFAFC2C-D46B-4959-BA03... which could be rewritten to something cleaner, as you suggest. Rich Pyle has been clever, in that if I try http://zoobank.org:80/?lsid=urn:lsid:ipni.org:names:20012728-1:1.1 I get bounced to http://lsid.tdwg.org/summary/urn:lsid:ipni.org:names:20012728-1:1.1 which means if the user tries to use http://zoobank.org:80/?lsid= as a general LSID proxy, they don't get an ugly error, they still get what they were after (albeit not served from Zoobank). Perhaps this would be the simplest thing for IPNI to implement? Regards Rod On 21 Apr 2009, at 17:41, Nicola Nicolson wrote:
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/[lsid] 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
--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
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/[lsid] 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
I have gone Semantic Web fundamentalist and so any proxy must pass the Linked Data validator that Rod so kindly pointed out. http://validator.linkeddata.org/vapour If it does this then the proxied LSIDs can be used in Jena and other SW frameworks seamlessly. Ideally there should be some simple content negotiation to return a nice web page for humans and RDF for machines. I don't think a proxy has to service any LSID anyone throws at it. From my point of view the proxy is there to make LSIDs behave as if they were good semantic web URIs. The proxy_string + LSID is a URI to a resource that can be reasoned about. It is therefore best to always use the same proxy for any one LSID. This is what I try to do with BCI. The proxied LSID is effectively another identifier in another technology domain just joined by an owl:sameAs. It should be possible to just write an Apache rewrite rule to turn the LSID into a a 303 redirect to the URL used for the RDF by the LSID Authority. The linked data stuff is just soooo simple. I love it. Praise Lord TBL. All the best, Roger On 21 Apr 2009, at 23:01, Kevin Richards wrote:
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/[lsid] 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 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
Yes. Some of us have believed in the simplicity of an RDF solution since Noel Cross's presentation at TDWG 1999. Jonathan Rees called for 303 redirection on the lsid proxy discussion in 2007. So if we are to do this we must update our recommendations and the lsid applicability statement accordingly. Does anyone disagree? The current position is "An LSID HTTP proxy is a web service that resolves LSIDs by returning the results of the getMetadata() call via HTTP GET." greg 2009/4/22 Roger Hyam <rogerhyam@mac.com>:
I have gone Semantic Web fundamentalist and so any proxy must pass the Linked Data validator that Rod so kindly pointed out.
http://validator.linkeddata.org/vapour
If it does this then the proxied LSIDs can be used in Jena and other SW frameworks seamlessly.
Ideally there should be some simple content negotiation to return a nice web page for humans and RDF for machines.
I don't think a proxy has to service any LSID anyone throws at it. From my point of view the proxy is there to make LSIDs behave as if they were good semantic web URIs. The proxy_string + LSID is a URI to a resource that can be reasoned about. It is therefore best to always use the same proxy for any one LSID. This is what I try to do with BCI. The proxied LSID is effectively another identifier in another technology domain just joined by an owl:sameAs.
It should be possible to just write an Apache rewrite rule to turn the LSID into a a 303 redirect to the URL used for the RDF by the LSID Authority. The linked data stuff is just soooo simple. I love it. Praise Lord TBL.
All the best,
Roger
On 21 Apr 2009, at 23:01, Kevin Richards wrote:
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/[lsid] 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 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
_______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
------ If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.
------
-- Greg Whitbread Australian National Botanic Gardens Australian National Herbarium +61 2 62509482 ghw@anbg.gov.au
Yes, I suspect this should be something more like "An LSID HTTP proxy is an HTTP endpoint that allows resolution of LSID metadata via HTTP GET" ie, this could then be done either using 303 redirect, or just an endpoint that returns the LSID metadata directly. sound ok? Kevin -----Original Message----- From: whitbread.greg@gmail.com [mailto:whitbread.greg@gmail.com] On Behalf Of greg whitbread Sent: Thursday, 23 April 2009 1:16 a.m. To: Roger Hyam Cc: Kevin Richards; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] LSID HTTP Proxy - design question [SEC=UNCLASSIFIED] Yes. Some of us have believed in the simplicity of an RDF solution since Noel Cross's presentation at TDWG 1999. Jonathan Rees called for 303 redirection on the lsid proxy discussion in 2007. So if we are to do this we must update our recommendations and the lsid applicability statement accordingly. Does anyone disagree? The current position is "An LSID HTTP proxy is a web service that resolves LSIDs by returning the results of the getMetadata() call via HTTP GET." greg 2009/4/22 Roger Hyam <rogerhyam@mac.com>:
I have gone Semantic Web fundamentalist and so any proxy must pass the Linked Data validator that Rod so kindly pointed out.
http://validator.linkeddata.org/vapour
If it does this then the proxied LSIDs can be used in Jena and other SW frameworks seamlessly.
Ideally there should be some simple content negotiation to return a nice web page for humans and RDF for machines.
I don't think a proxy has to service any LSID anyone throws at it. From my point of view the proxy is there to make LSIDs behave as if they were good semantic web URIs. The proxy_string + LSID is a URI to a resource that can be reasoned about. It is therefore best to always use the same proxy for any one LSID. This is what I try to do with BCI. The proxied LSID is effectively another identifier in another technology domain just joined by an owl:sameAs.
It should be possible to just write an Apache rewrite rule to turn the LSID into a a 303 redirect to the URL used for the RDF by the LSID Authority. The linked data stuff is just soooo simple. I love it. Praise Lord TBL.
All the best,
Roger
On 21 Apr 2009, at 23:01, Kevin Richards wrote:
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/[lsid] 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 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
_______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
------ If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.
------
-- Greg Whitbread Australian National Botanic Gardens Australian National Herbarium +61 2 62509482 ghw@anbg.gov.au 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
participants (5)
-
greg whitbread -
Kevin Richards -
Nicola Nicolson -
Roderic Page -
Roger Hyam