<HTML dir=ltr><HEAD><TITLE>Re: [Tdwg-guid] Throttling searches [ Scanned for viruses ]</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR><BASE href=https://mbgowa01.mobot.org/exchange/Chuck.Miller/Drafts/RE:%20%5BTdwg-guid%5D%20Throttling%20searches%20%5B%20Scanned%20for%20viruses%20%5D.EML/1_text.htm></HEAD>
<BODY>
<DIV id=idOWAReplyText64679 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Steve,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>OK thanks, I get that now: LSID is an element of a query response. I guess that leads to more questions about where the LSID goes in which response formats. Just add an LSID concept to Darwin Core for instance?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>But, if SPARQL is a protocol, how does it layer on top of or parallel to all the other protocols that TDWG is attempting to standardize? Or are we proposing it as the "protocol to rule them all"?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>At least with DIGIR, imperfect as it is, it was clear that it was both query/response and protocol. (The complete flow diagram fits on one screen) As we break this all apart and grow it, I think it is becoming difficult for those outside to follow the model and makes it more important to describe the complete query, protocol, response stack for the TDWG membership that will be called to recommend and vote on it.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Which reminds me that we still need the Rosetta Stone that resolves all these things that are on the table: DIGIR, BioCASE, TAPIR, Wasabi, SPARQL, LSID, PURL, RDF, OWL, OWL-DL, WSDL, SOAP, HTTP GET plus XML Schema - Darwin Core(Base plus extensions like GML), ABCD, TCS, SDD, etc. and more. And resolves them in a way that the general TDWG membership can fully grasp during the upcoming TDWG meeting.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Chuck</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Steven Perry [mailto:smperry@ku.edu]<BR><B>Sent:</B> Mon 6/19/2006 10:22 PM<BR><B>To:</B> Chuck Miller<BR><B>Cc:</B> S.Hinchcliffe@kew.org; roger@tdwg.org; tdwg-guid@mailman.nhm.ku.edu<BR><B>Subject:</B> Re: [Tdwg-guid] Throttling searches [ Scanned for viruses ]<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Hi Chuck,</FONT> </P>
<P><FONT size=2>I've been thinking of the case you describe as a query operation. A </FONT><BR><FONT size=2>query operation would take match conditions as input and, when applied </FONT><BR><FONT size=2>to a set of RDF metadata, returns either an RDF graph or values bound to </FONT><BR><FONT size=2>variables (analogous to an SQL select statement). Either type of output </FONT><BR><FONT size=2>may contain references to other data objects by LSID which would have to </FONT><BR><FONT size=2>be resolved by clients.</FONT> </P>
<P><FONT size=2>This query operation is not supported by the LSID spec and requires a </FONT><BR><FONT size=2>distinct service. We've implemented SPARQL as the query service for </FONT><BR><FONT size=2>DiGIR2 (now called Wasabi). SPARQL is a W3C candidate recommendation </FONT><BR><FONT size=2>and is both a query language and a protocol.</FONT> </P>
<P><FONT size=2>See the following for more information:</FONT> </P>
<P><FONT size=2><A href="http://www.w3.org/TR/rdf-sparql-query/">http://www.w3.org/TR/rdf-sparql-query/</A></FONT> <BR><FONT size=2><A href="http://www.w3.org/TR/rdf-sparql-protocol/">http://www.w3.org/TR/rdf-sparql-protocol/</A></FONT> </P>
<P><FONT size=2>-Steve</FONT> </P><BR><BR><BR><BR><BR>
<P><FONT size=2>Chuck Miller wrote:</FONT> </P>
<P><FONT size=2>> This is probably a dumb question and exposes my ignorance, but what if </FONT><BR><FONT size=2>> the originating query is actually "Get all LSIDs where Family = </FONT><BR><FONT size=2>> Orchidaceae". That seems the more likely scenario to me rather than </FONT><BR><FONT size=2>> get one LSID. And that's the one that needs a throttle. </FONT><BR><FONT size=2>> </FONT><BR><FONT size=2>> Chuck </FONT><BR><FONT size=2>></FONT> <BR><FONT size=2>> ------------------------------------------------------------------------</FONT> <BR><FONT size=2>> *From:* Sally Hinchcliffe [<A href="mailto:S.Hinchcliffe@kew.org">mailto:S.Hinchcliffe@kew.org</A>]</FONT> <BR><FONT size=2>> *Sent:* Mon 6/19/2006 7:01 AM</FONT> <BR><FONT size=2>> *To:* roger@tdwg.org</FONT> <BR><FONT size=2>> *Cc:* tdwg-guid@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> *Subject:* Re: [Tdwg-guid] Throttling searches [ Scanned for viruses ]</FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>> Hi Roger</FONT> <BR><FONT size=2>> Thanks for this ... I _think_ I understand it but Nicky is on leave</FONT> <BR><FONT size=2>> this week so I won't know if I do or not till after she returns</FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>> The system doesn't have to be completely villain proof, just slow</FONT> <BR><FONT size=2>> down most of the villains so everyone else can get a look in</FONT> <BR><FONT size=2>> Sally</FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > You don't! The LSID resolves to the binding to the getMetadata() method</FONT> <BR><FONT size=2>> > - which is a plain old fashioned URL. At this point the LSID authority</FONT> <BR><FONT size=2>> > has done its duty and we are just on a plain HTTP GET call so you </FONT><BR><FONT size=2>> can do</FONT> <BR><FONT size=2>> > whatever you can do with any regular HTTP GET. You could stipulate</FONT> <BR><FONT size=2>> > another header field or (more simply) give priority service for those</FONT> <BR><FONT size=2>> > who append a valid user id to the URL (&user_id=12345)</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > So there is no throttle on resolving the LSID to the getMetadata </FONT><BR><FONT size=2>> binding</FONT> <BR><FONT size=2>> > (which is cheap) but there is a throttle on the actual call to get the</FONT> <BR><FONT size=2>> > metadata method. Really you need to do this because bad people may be</FONT> <BR><FONT size=2>> > able to tell from the URL how to scrape the source and bypass the LSID</FONT> <BR><FONT size=2>> > resolver after the first call anyhow. This is especially true if the </FONT><BR><FONT size=2>> URL</FONT> <BR><FONT size=2>> > contains the IPNI record ID which is likely.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > Here is an example using Rod's tester.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > </FONT><BR><FONT size=2>> <A href="http://linnaeus.zoology.gla.ac.uk/~rpage/lsid/tester/?q=urn:lsid:ubio.org:namebank:11815">http://linnaeus.zoology.gla.ac.uk/~rpage/lsid/tester/?q=urn:lsid:ubio.org:namebank:11815</A> </FONT><BR><FONT size=2>> <<A href="http://linnaeus.zoology.gla.ac.uk/%7Erpage/lsid/tester/?q=urn:lsid:ubio.org:namebank:11815">http://linnaeus.zoology.gla.ac.uk/%7Erpage/lsid/tester/?q=urn:lsid:ubio.org:namebank:11815</A>> </FONT><BR><FONT size=2>></FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > The getMetadata() method for this LSID:</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > urn:lsid:ubio.org:namebank:11815</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > Is bound to this URL:</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > </FONT><BR><FONT size=2>> <A href="http://names.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:11815">http://names.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:11815</A> </FONT><BR><FONT size=2>></FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > So ubio would just have to give preferential services to calls like </FONT><BR><FONT size=2>> this:</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > </FONT><BR><FONT size=2>> <A href="http://names.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:11815&user_id=rogerhyam1392918790">http://names.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:11815&user_id=rogerhyam1392918790</A> </FONT><BR><FONT size=2>> <<A href="http://names.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:11815&user_id=rogerhyam1392918790">http://names.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:11815&user_id=rogerhyam1392918790</A>> </FONT><BR><FONT size=2>></FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > If rogerhyam had paid his membership fees this year.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > Does this make sense?</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > Roger</FONT> <BR><FONT size=2>> > p.s. You could do this on the web pages as well with a clever little</FONT> <BR><FONT size=2>> > thing to write dynamic tokens into the links so that it doesn't degrade</FONT> <BR><FONT size=2>> > the regular browsing experience and only stops scrapers - but that is</FONT> <BR><FONT size=2>> > beyond my remit at the moment ;)</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > p.p.s. You could wrap this in https if you were paranoid about people</FONT> <BR><FONT size=2>> > stealing tokens - but this is highly unlikely I believe.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > Sally Hinchcliffe wrote:</FONT> <BR><FONT size=2>> > > How can we pass a token with an LSID?</FONT> <BR><FONT size=2>> > ></FONT> <BR><FONT size=2>> > ></FONT> <BR><FONT size=2>> > > </FONT><BR><FONT size=2>> > >> I think the only way to throttle in these situations is to have some</FONT> <BR><FONT size=2>> > >> notion of who the client is and the only way to do that is to </FONT><BR><FONT size=2>> have some</FONT> <BR><FONT size=2>> > >> kind of token exchange over HTTP saying who they are. Basically </FONT><BR><FONT size=2>> you have</FONT> <BR><FONT size=2>> > >> to have some kind of client registration system or you can never</FONT> <BR><FONT size=2>> > >> distinguish between a call from a new client and a repeat call. </FONT><BR><FONT size=2>> The use</FONT> <BR><FONT size=2>> > >> of IP address is a pain because so many people are now behind </FONT><BR><FONT size=2>> some kind</FONT> <BR><FONT size=2>> > >> of NAT gateway.</FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >> How about this for a plan:</FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >> You could give a degraded services to people who don't pass a </FONT><BR><FONT size=2>> token (a 5</FONT> <BR><FONT size=2>> > >> second delay perhaps) and offer a quicker service to registered </FONT><BR><FONT size=2>> users</FONT> <BR><FONT size=2>> > >> who pass a token (but then perhaps limit the number of calls they </FONT><BR><FONT size=2>> make).</FONT> <BR><FONT size=2>> > >> This would mean you could offer a universal service even to those </FONT><BR><FONT size=2>> with</FONT> <BR><FONT size=2>> > >> naive client software but a better service to those who play </FONT><BR><FONT size=2>> nicely. You</FONT> <BR><FONT size=2>> > >> could also get better stats on who is using the service.</FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >> So there are ways that this could be done. I expect people will </FONT><BR><FONT size=2>> come up</FONT> <BR><FONT size=2>> > >> with a host of different ways. It is outside LSIDs though.</FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >> Roger</FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >> Sally Hinchcliffe wrote:</FONT> <BR><FONT size=2>> > >> </FONT><BR><FONT size=2>> > >>> It's not an LSID issue per se, but LSIDs will make it harder to </FONT><BR><FONT size=2>> slow</FONT> <BR><FONT size=2>> > >>> searches down. For instance, Google restricts use of its spell</FONT> <BR><FONT size=2>> > >>> checker to 1000 a day by use of a key which is passed in with each</FONT> <BR><FONT size=2>> > >>> request. Obviously this can't be done with LSIDs as then they</FONT> <BR><FONT size=2>> > >>> wouldn't be the same for each user.</FONT> <BR><FONT size=2>> > >>> The other reason why it's relevant to LSIDs is simply that </FONT><BR><FONT size=2>> providing</FONT> <BR><FONT size=2>> > >>> a list of all relevant IPNI LSIDs (not necessary to the LSID</FONT> <BR><FONT size=2>> > >>> implementation but a nice to have for caching / lookups for other</FONT> <BR><FONT size=2>> > >>> systems using our LSIDs) also makes life easier for the </FONT><BR><FONT size=2>> datascrapers</FONT> <BR><FONT size=2>> > >>> to operate</FONT> <BR><FONT size=2>> > >>></FONT> <BR><FONT size=2>> > >>> Also I thought ... here's a list full of clever people perhaps they</FONT> <BR><FONT size=2>> > >>> will have some suggestions</FONT> <BR><FONT size=2>> > >>></FONT> <BR><FONT size=2>> > >>> Sally</FONT> <BR><FONT size=2>> > >>></FONT> <BR><FONT size=2>> > >>> </FONT><BR><FONT size=2>> > >>> </FONT><BR><FONT size=2>> > >>>> Is this an LSID issue? LSIDs essential provide a binding </FONT><BR><FONT size=2>> service between</FONT> <BR><FONT size=2>> > >>>> an name and one or more web services (we default to HTTP GET </FONT><BR><FONT size=2>> bindings).</FONT> <BR><FONT size=2>> > >>>> It isn't really up to the LSID authority to administer any </FONT><BR><FONT size=2>> policies</FONT> <BR><FONT size=2>> > >>>> regarding the web service but simply to point at it. It is up </FONT><BR><FONT size=2>> to the web</FONT> <BR><FONT size=2>> > >>>> service to do things like throttling, authentication and </FONT><BR><FONT size=2>> authorization.</FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>> Imagine, for example, that the different services had different</FONT> <BR><FONT size=2>> > >>>> policies. It may be reasonable not to restrict the </FONT><BR><FONT size=2>> getMetadata() calls</FONT> <BR><FONT size=2>> > >>>> but to restrict the getData() calls.</FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>> The use of LSIDs does not create any new problems that weren't </FONT><BR><FONT size=2>> there</FONT> <BR><FONT size=2>> > >>>> with web page scraping - or scraping of any other web service.</FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>> Just my thoughts...</FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>> Roger</FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>> Ricardo Scachetti Pereira wrote:</FONT> <BR><FONT size=2>> > >>>> </FONT><BR><FONT size=2>> > >>>> </FONT><BR><FONT size=2>> > >>>>> Sally,</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> You raised a really important issue that we had not really </FONT><BR><FONT size=2>> addressed</FONT> <BR><FONT size=2>> > >>>>> at the meeting. Thanks for that.</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> I would say that we should not constrain the resolution of </FONT><BR><FONT size=2>> LSIDs if</FONT> <BR><FONT size=2>> > >>>>> we expect our LSID infrastructure to work. LSIDs will be the </FONT><BR><FONT size=2>> basis of</FONT> <BR><FONT size=2>> > >>>>> our architecture so we better have good support for that.</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> However, that is sure a limiting factor. Also server </FONT><BR><FONT size=2>> efficiency will</FONT> <BR><FONT size=2>> > >>>>> likely vary quite a lot, depending on underlying system </FONT><BR><FONT size=2>> optimizations</FONT> <BR><FONT size=2>> > >>>>> and all.</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> So I think that the solution for this problem is in </FONT><BR><FONT size=2>> caching LSID</FONT> <BR><FONT size=2>> > >>>>> responses on the server LSID stack. Basically, after resolving </FONT><BR><FONT size=2>> an LSID</FONT> <BR><FONT size=2>> > >>>>> once, your server should be able to resolve it again and again </FONT><BR><FONT size=2>> really</FONT> <BR><FONT size=2>> > >>>>> quickly, until something on the metadata that is related to </FONT><BR><FONT size=2>> that id changes.</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> I haven't looked at this aspect of the LSID software </FONT><BR><FONT size=2>> stack, but</FONT> <BR><FONT size=2>> > >>>>> maybe others can say something about it. In any case I'll do some</FONT> <BR><FONT size=2>> > >>>>> research on it and get back to you.</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> Again, thanks for bringing it up.</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> Cheers,</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> Ricardo</FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> Sally Hinchcliffe wrote:</FONT> <BR><FONT size=2>> > >>>>> </FONT><BR><FONT size=2>> > >>>>> </FONT><BR><FONT size=2>> > >>>>> </FONT><BR><FONT size=2>> > >>>>>> There are enough discontinuities in IPNI ids that 1,2,3 would </FONT><BR><FONT size=2>> quickly</FONT> <BR><FONT size=2>> > >>>>>> run into the sand. I agree it's not a new problem - I just </FONT><BR><FONT size=2>> hate to</FONT> <BR><FONT size=2>> > >>>>>> think I'm making life easier for the data scrapers</FONT> <BR><FONT size=2>> > >>>>>> Sally</FONT> <BR><FONT size=2>> > >>>>>></FONT> <BR><FONT size=2>> > >>>>>></FONT> <BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>>>> It can be a problem but I'm not sure if there is a simple </FONT><BR><FONT size=2>> solution ... and how different is the LSID crawler scenario from an </FONT><BR><FONT size=2>> <A href="http://www.ipni.org/ipni/plantsearch?id=">http://www.ipni.org/ipni/plantsearch?id=</A> 1,2,3,4,5 ... 9999999 scenario?</FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> Paul</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> -----Original Message-----</FONT> <BR><FONT size=2>> > >>>>>>> From: tdwg-guid-bounces@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> > >>>>>>> [<A href="mailto:tdwg-guid-bounces@mailman.nhm.ku.edu">mailto:tdwg-guid-bounces@mailman.nhm.ku.edu</A>]On Behalf Of Sally</FONT> <BR><FONT size=2>> > >>>>>>> Hinchcliffe</FONT> <BR><FONT size=2>> > >>>>>>> Sent: 15 June 2006 12:08</FONT> <BR><FONT size=2>> > >>>>>>> To: tdwg-guid@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> > >>>>>>> Subject: [Tdwg-guid] Throttling searches [ Scanned for </FONT><BR><FONT size=2>> viruses ]</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> Hi all</FONT> <BR><FONT size=2>> > >>>>>>> another question that has come up here.</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> As discussed at the meeting, we're thinking of providing a </FONT><BR><FONT size=2>> complete</FONT> <BR><FONT size=2>> > >>>>>>> download of all IPNI LSIDs plus a label (name and author, </FONT><BR><FONT size=2>> probably)</FONT> <BR><FONT size=2>> > >>>>>>> which will be available as an annually produced download</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> Most people will play nice and just resolve one or two LSIDs as</FONT> <BR><FONT size=2>> > >>>>>>> required, but by providing a complete list, we're making it </FONT><BR><FONT size=2>> very easy</FONT> <BR><FONT size=2>> > >>>>>>> for someone to write a crawler that hits every LSID in turn and</FONT> <BR><FONT size=2>> > >>>>>>> basically brings our server to its knees</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> Anybody know of a good way of enforcing more polite </FONT><BR><FONT size=2>> behaviour? We can</FONT> <BR><FONT size=2>> > >>>>>>> make the download only available under a data supply </FONT><BR><FONT size=2>> agreement that</FONT> <BR><FONT size=2>> > >>>>>>> includes a clause limiting hit rates, or we could limit by </FONT><BR><FONT size=2>> IP address</FONT> <BR><FONT size=2>> > >>>>>>> (but this would ultimately block out services like Rod's simple</FONT> <BR><FONT size=2>> > >>>>>>> resolver). I beleive Google's spell checker uses a key which </FONT><BR><FONT size=2>> has to</FONT> <BR><FONT size=2>> > >>>>>>> be passed in as part of the query - obviously we can't do </FONT><BR><FONT size=2>> that with</FONT> <BR><FONT size=2>> > >>>>>>> LSIDs</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> Any thoughts? Anyone think this is a problem?</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> Sally</FONT> <BR><FONT size=2>> > >>>>>>> *** Sally Hinchcliffe</FONT> <BR><FONT size=2>> > >>>>>>> *** Computer section, Royal Botanic Gardens, Kew</FONT> <BR><FONT size=2>> > >>>>>>> *** tel: +44 (0)20 8332 5708</FONT> <BR><FONT size=2>> > >>>>>>> *** S.Hinchcliffe@rbgkew.org.uk</FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> _______________________________________________</FONT> <BR><FONT size=2>> > >>>>>>> TDWG-GUID mailing list</FONT> <BR><FONT size=2>> > >>>>>>> TDWG-GUID@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> > >>>>>>> <A href="http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid">http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid</A></FONT> <BR><FONT size=2>> > >>>>>>></FONT> <BR><FONT size=2>> > >>>>>>> _______________________________________________</FONT> <BR><FONT size=2>> > >>>>>>> TDWG-GUID mailing list</FONT> <BR><FONT size=2>> > >>>>>>> TDWG-GUID@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> > >>>>>>> <A href="http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid">http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid</A></FONT> <BR><FONT size=2>> > >>>>>>> </FONT><BR><FONT size=2>> > >>>>>>> </FONT><BR><FONT size=2>> > >>>>>>> </FONT><BR><FONT size=2>> > >>>>>>> </FONT><BR><FONT size=2>> > >>>>>> *** Sally Hinchcliffe</FONT> <BR><FONT size=2>> > >>>>>> *** Computer section, Royal Botanic Gardens, Kew</FONT> <BR><FONT size=2>> > >>>>>> *** tel: +44 (0)20 8332 5708</FONT> <BR><FONT size=2>> > >>>>>> *** S.Hinchcliffe@rbgkew.org.uk</FONT> <BR><FONT size=2>> > >>>>>></FONT> <BR><FONT size=2>> > >>>>>></FONT> <BR><FONT size=2>> > >>>>>> _______________________________________________</FONT> <BR><FONT size=2>> > >>>>>> TDWG-GUID mailing list</FONT> <BR><FONT size=2>> > >>>>>> TDWG-GUID@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> > >>>>>> <A href="http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid">http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid</A></FONT> <BR><FONT size=2>> > >>>>>></FONT> <BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>>> </FONT><BR><FONT size=2>> > >>>>> _______________________________________________</FONT> <BR><FONT size=2>> > >>>>> TDWG-GUID mailing list</FONT> <BR><FONT size=2>> > >>>>> TDWG-GUID@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> > >>>>> <A href="http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid">http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid</A></FONT> <BR><FONT size=2>> > >>>>></FONT> <BR><FONT size=2>> > >>>>> </FONT><BR><FONT size=2>> > >>>>> </FONT><BR><FONT size=2>> > >>>>> </FONT><BR><FONT size=2>> > >>>> --</FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>> -------------------------------------</FONT> <BR><FONT size=2>> > >>>> Roger Hyam</FONT> <BR><FONT size=2>> > >>>> Technical Architect</FONT> <BR><FONT size=2>> > >>>> Taxonomic Databases Working Group</FONT> <BR><FONT size=2>> > >>>> -------------------------------------</FONT> <BR><FONT size=2>> > >>>> <A href="http://www.tdwg.org/">http://www.tdwg.org</A> <<A href="http://www.tdwg.org/">http://www.tdwg.org/</A>></FONT> <BR><FONT size=2>> > >>>> roger@tdwg.org</FONT> <BR><FONT size=2>> > >>>> +44 1578 722782</FONT> <BR><FONT size=2>> > >>>> -------------------------------------</FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>></FONT> <BR><FONT size=2>> > >>>> </FONT><BR><FONT size=2>> > >>>> </FONT><BR><FONT size=2>> > >>> *** Sally Hinchcliffe</FONT> <BR><FONT size=2>> > >>> *** Computer section, Royal Botanic Gardens, Kew</FONT> <BR><FONT size=2>> > >>> *** tel: +44 (0)20 8332 5708</FONT> <BR><FONT size=2>> > >>> *** S.Hinchcliffe@rbgkew.org.uk</FONT> <BR><FONT size=2>> > >>></FONT> <BR><FONT size=2>> > >>></FONT> <BR><FONT size=2>> > >>> </FONT><BR><FONT size=2>> > >>> </FONT><BR><FONT size=2>> > >> --</FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >> -------------------------------------</FONT> <BR><FONT size=2>> > >> Roger Hyam</FONT> <BR><FONT size=2>> > >> Technical Architect</FONT> <BR><FONT size=2>> > >> Taxonomic Databases Working Group</FONT> <BR><FONT size=2>> > >> -------------------------------------</FONT> <BR><FONT size=2>> > >> <A href="http://www.tdwg.org/">http://www.tdwg.org</A> <<A href="http://www.tdwg.org/">http://www.tdwg.org/</A>></FONT> <BR><FONT size=2>> > >> roger@tdwg.org</FONT> <BR><FONT size=2>> > >> +44 1578 722782</FONT> <BR><FONT size=2>> > >> -------------------------------------</FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >></FONT> <BR><FONT size=2>> > >> </FONT><BR><FONT size=2>> > ></FONT> <BR><FONT size=2>> > > *** Sally Hinchcliffe</FONT> <BR><FONT size=2>> > > *** Computer section, Royal Botanic Gardens, Kew</FONT> <BR><FONT size=2>> > > *** tel: +44 (0)20 8332 5708</FONT> <BR><FONT size=2>> > > *** S.Hinchcliffe@rbgkew.org.uk</FONT> <BR><FONT size=2>> > ></FONT> <BR><FONT size=2>> > ></FONT> <BR><FONT size=2>> > > </FONT><BR><FONT size=2>> ></FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > --</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> > -------------------------------------</FONT> <BR><FONT size=2>> > Roger Hyam</FONT> <BR><FONT size=2>> > Technical Architect</FONT> <BR><FONT size=2>> > Taxonomic Databases Working Group</FONT> <BR><FONT size=2>> > -------------------------------------</FONT> <BR><FONT size=2>> > <A href="http://www.tdwg.org/">http://www.tdwg.org</A> <<A href="http://www.tdwg.org/">http://www.tdwg.org/</A>></FONT> <BR><FONT size=2>> > roger@tdwg.org</FONT> <BR><FONT size=2>> > +44 1578 722782</FONT> <BR><FONT size=2>> > -------------------------------------</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>> *** Sally Hinchcliffe</FONT> <BR><FONT size=2>> *** Computer section, Royal Botanic Gardens, Kew</FONT> <BR><FONT size=2>> *** tel: +44 (0)20 8332 5708</FONT> <BR><FONT size=2>> *** S.Hinchcliffe@rbgkew.org.uk</FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>> _______________________________________________</FONT> <BR><FONT size=2>> TDWG-GUID mailing list</FONT> <BR><FONT size=2>> TDWG-GUID@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>> <A href="http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid">http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid</A></FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>>------------------------------------------------------------------------</FONT> <BR><FONT size=2>></FONT> <BR><FONT size=2>>_______________________________________________</FONT> <BR><FONT size=2>>TDWG-GUID mailing list</FONT> <BR><FONT size=2>>TDWG-GUID@mailman.nhm.ku.edu</FONT> <BR><FONT size=2>><A href="http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid">http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid</A></FONT> <BR><FONT size=2>> </FONT><BR><FONT size=2>></FONT> </P></DIV></BODY></HTML>