I should have added, it you find javascript that needs i18n, please raise a bug for this in github. We have tried to ensure all javascript is using i18n, but we may have missed a few things. Cheers Dave On 15/09/2014 12:07 pm, "David.Martin@csiro.au" <David.Martin@csiro.au> wrote:

Thanks Santiago.

The released version of the collectory was actually 1.1.1. I can see you¹ve got the snapshot version 1.1.2-SNAPSHOT running (if you view source the version is in the header). I don¹t think there are any commits for 1.1.2-SNAPSHOT (yet), but we are trying to discourage folks from using snapshots and rely on the releases.

1) Heres the same page on the demo site with 1.1.1: http://ala-demo.gbif.org/collectory/datasets/

The problem has been caused by setting the configuration variable ³ala.baseURL² to "http://datos.gbif.es² instead of "http://www.ala.org.au"

ALA-DEMO version: <script src="http://www.ala.org.au/wp-content/themes/ala2011/scripts/jquery.autoco m plete.js" type="text/javascript" ></script>

ES version: <script src="http://datos.gbif.es/wp-content/themes/ala2011/scripts/jquery.autocom p lete.js" type="text/javascript" ></script>

We have plans to remove this import from the collectory, but in the meantime to fix the problem, switch to ala.baseURL=http://www.ala.org.au

2) To answer the specific questions:

- Is it necessary the use of these provider maps to create the relations?

Yes.

- Could you explain how works this matching code?

During the processing, when the biocache code encounters a new combination of institution code and collection code, it calls the collectory like so:

Example record: http://datos.gbif.es/generic-hub/occurrences/6a5c6786-9794-460d-8335-09354 0 9b999c

collectionCode=ADIMAN-FLORA institutionCode=ADIMAN

dataResourceUid=dr66

Web service lookup: http://datos.gbif.es/collectory/ws/lookup/inst/ADIMAN/coll/ADIMAN-FLORA

To be clear, the provider map codes should NOT be UIDs like ³co1² or ³in1². Provider map codes should be values that you are seeing in the raw data e.g. ADIMAN.

I think this is an example problem record:

http://datos.gbif.es/generic-hub/occurrences/9e59738e-56f9-41ea-ba64-106d6 5 1c0560

collectionCode=ADIMAN-MANCHUELA-2007 institutionCode=ADIMAN dataResourceUid=dr40

Web service lookup: http://datos.gbif.es/collectory/ws/lookup/inst/ADIMAN/coll/ADIMAN-MANCHUEL A -2007

So currently there isn¹t a mapping in place for that combination. I suspect what has happened is there have been changes to collectory configuration for these resources after the data was originally loaded + processed.

To be clear, if you make changes in the collectory mappings (provider codes, resource consumers etc), these will NOT be picked up in the searching until you re-run processing & indexing like so:

biocache process -dr dr66 biocache index -dr dr66

Hope this helps,

Dave

On 13/09/2014 12:18 am, "Santiago Martinez de la Riva" <sama@gbif.es> wrote:

...

Hi all,

I updated our collectory module with the last release, collectory 1.1.2. And I found two issues that I would like to comment you.

1) DATASETS: http://datos.gbif.es/collectory/datasets/

In this url the datasets are never loaded. You can see in the Firebug that the page has 3 erros, one of these is the next:

TypeError: jQuery(...).autocomplete is not a function selectFirst: false

/collec...tasets/ (línea 70, col 16)

2) ADDING RESOURCES / COLLECTION / INSTITUTION: http://datos.gbif.es/collectory/public/show/in1

In this context, we have one Institution (in1) that has 2 collections. Now I'm goin to explain the procedure that I do to create these relations:

The first thing that I do is upload the resource, and after, I create the entities for that collection and that instution. In this moment, I edit the data resource and the collection for creating the relations:

- The first collection "Inventario Fauna Vertebrada de la Manchuela Conquense (CUENCA), 2007 (ADIMAN-MANCHUELA-2007)" is related to the data resource "dr40" that has 2.790, the collection code is ADIMAN-MACHUELA-2007 and the internal code/id is co3. The record consumer of the data resource "dr40" are co3 and in1. (image_1) but when I create the relation between this collection and the institution, the record cosumer are (view image_2)

- The second collection "Inventario de Flora y Vegetación del Municipio de Enguídanos (Cuenca), 2010 (ADIMAN-FLORA)" is related to the data resource "dr66" that has 5.291 records. The collection code is ADIMAN-FLORA and the internal code/id is co2. The record consumer of the data resource "dr66" are co2 and in1. (image_3) but when I create the relation between this collection and the institution the record cosumer are: (view image_4)

I think that in both cases, image_2 and image_4, are wrong, because, how is it possible that one collection contributes with digitised records to the other? This doesn't make sense.

When I have created this structure, then I do the ingest of these resource: ingest -dr dr40 ingest -dr dr66

But, what is my surprise that when I access to the page of each resource, I see that the total records of ADIMAN-MANCHUELA-2007 is the sum of the record of both collections, and ADIMAN-FLORA doesn't have records. You can see this in this links: - http://datos.gbif.es/collectory/public/show/co3 (ADIMAN-MACHUELA-2007) - http://datos.gbif.es/collectory/public/show/co2 (ADMINA-FLORA)

I can also create the provider Map for both cases, but I don't exactly know, if the provider codes have to be the internal codes like: in1, co2 and co3 or the orginal codes like ADMIN, ADIMAN-FLORA and ADIMAN-MACHUELA-2007. In the image_5 and image_6, you can see the ProviderMap for this case. Two question? - Is it necessary the use of these provider maps to create the relations? - Could you explain how works this matching code? I mean, It's possible that in one collection we have two collection codes, For example: in ADIMAN-MACHUELA-2007 we have other collection code that is ADIMAN-CENSOAVUTARDA-2008. I figure up that I can define these rules with the parameters: "exact" and "Match Any Collection Code". Is right?

Thanks so much for the help and sorry for this long message.

PD: I'm working also with the i18n, and soon we will have translated and implemented all the variables in the project. You can see some advance in this link http://datos.gbif.es/collectory, I have had to edit some javascripts to do all the translation.

------------------------------------------------------------------------- - ------------- Santiago Martínez de la Riva GBIF.ES, Unidad de Coordinación Tel. +34 91 4203017 x 273 Real Jardín Botánico - CSIC Fax +34 91 429 2405 Plaza de Murillo, 2 sama@gbif.es 28014 Madrid, Spain www.gbif.es

_______________________________________________ Ala-portal mailing list Ala-portal@lists.gbif.org http://lists.gbif.org/mailman/listinfo/ala-portal

Hi Dave, Thanks 4 this change in collectory - $.ajax({url: baseUrl + "/public/dataSetSearch?q=" + query,... -. I hope that I can understand better this project in a few weeks and I'm able to do these changes by myself. Cheers, Santi. --------------------------------------------------------------------------------------- Santiago Martínez de la Riva GBIF.ES, Unidad de Coordinación Tel. +34 91 4203017 x 273 Real Jardín Botánico - CSIC Fax +34 91 429 2405 Plaza de Murillo, 2 sama@gbif.es 28014 Madrid, Spain www.gbif.es ________________________________________ De: ala-portal-bounces@lists.gbif.org [ala-portal-bounces@lists.gbif.org] En nombre de Santiago Martinez de la Riva [sama@gbif.es] Enviado el: miércoles, 17 de septiembre de 2014 9:02 Para: David.Martin@csiro.au; ala-portal@lists.gbif.org Asunto: Re: [Ala-portal] DATASETS and MANAGE RESOURCES / COLLECTION AND INSTITUTION Hi Dave, In the point one, I mean that when the user wants to filter the datasets by some words, the javascript "dataset.js" executes always the next code and this is a problem because, the searches always point to: In this case I have done a search in the vagrant machine 10.1.1.2 with the word "universidad" and the response is this json request: http://bie.ala.org.au/search.json?q=universidad&fq=idxtype:DATASET&pageSize=... It's obviously that this works in your demo-ala but not work in my case, because the datasets that I want to filter, are not in bie.ala.org.au. DATASET.JS function filterList() { // clear list of data sets clearList(); // clear search term $('#dr-search').val(''); // revert to full list resources = allResources; // aggregate all search criteria var searchTerms = []; $.each(currentFilters, function(i, obj) { if (obj.name == 'contains') { searchTerms.push(obj.value.toLowerCase()); } }); // perform any solr search and wait for result if (searchTerms.length > 0) { $('.collectory-content').css('cursor','wait'); // build query string from terms var query = ''; $.each(searchTerms, function(i, term) { query += (i == 0) ? term : "&fq=text:" + term }); // do search HERE---------> $.ajax({url:"http://bie.ala.org.au/search.json?q=" + query + "&fq=idxtype:DATASET&pageSize=1000&sort=name", dataType:'jsonp', success: function(data) { var uids = extractListOfUidsFromSearchResults(data); applyFilters(uids); $('.collectory-content').css('cursor','default'); } }); } // no search - so just do it now else { // do it now applyFilters(); } } Kind regards Santi --------------------------------------------------------------------------------------- Santiago Martínez de la Riva GBIF.ES, Unidad de Coordinación Tel. +34 91 4203017 x 273 Real Jardín Botánico - CSIC Fax +34 91 429 2405 Plaza de Murillo, 2 sama@gbif.es 28014 Madrid, Spain www.gbif.es ________________________________________ De: David.Martin@csiro.au [David.Martin@csiro.au] Enviado el: lunes, 15 de septiembre de 2014 4:07 Para: Santiago Martinez de la Riva; ala-portal@lists.gbif.org Asunto: Re: [Ala-portal] DATASETS and MANAGE RESOURCES / COLLECTION AND INSTITUTION Thanks Santiago. The released version of the collectory was actually 1.1.1. I can see you¹ve got the snapshot version 1.1.2-SNAPSHOT running (if you view source the version is in the header). I don¹t think there are any commits for 1.1.2-SNAPSHOT (yet), but we are trying to discourage folks from using snapshots and rely on the releases. 1) Heres the same page on the demo site with 1.1.1: http://ala-demo.gbif.org/collectory/datasets/ The problem has been caused by setting the configuration variable ³ala.baseURL² to "http://datos.gbif.es² instead of "http://www.ala.org.au" ALA-DEMO version: <script src="http://www.ala.org.au/wp-content/themes/ala2011/scripts/jquery.autocom plete.js" type="text/javascript" ></script> ES version: <script src="http://datos.gbif.es/wp-content/themes/ala2011/scripts/jquery.autocomp lete.js" type="text/javascript" ></script> We have plans to remove this import from the collectory, but in the meantime to fix the problem, switch to ala.baseURL=http://www.ala.org.au 2) To answer the specific questions: - Is it necessary the use of these provider maps to create the relations? Yes. - Could you explain how works this matching code? During the processing, when the biocache code encounters a new combination of institution code and collection code, it calls the collectory like so: Example record: http://datos.gbif.es/generic-hub/occurrences/6a5c6786-9794-460d-8335-093540 9b999c collectionCode=ADIMAN-FLORA institutionCode=ADIMAN dataResourceUid=dr66 Web service lookup: http://datos.gbif.es/collectory/ws/lookup/inst/ADIMAN/coll/ADIMAN-FLORA To be clear, the provider map codes should NOT be UIDs like ³co1² or ³in1². Provider map codes should be values that you are seeing in the raw data e.g. ADIMAN. I think this is an example problem record: http://datos.gbif.es/generic-hub/occurrences/9e59738e-56f9-41ea-ba64-106d65 1c0560 collectionCode=ADIMAN-MANCHUELA-2007 institutionCode=ADIMAN dataResourceUid=dr40 Web service lookup: http://datos.gbif.es/collectory/ws/lookup/inst/ADIMAN/coll/ADIMAN-MANCHUELA -2007 So currently there isn¹t a mapping in place for that combination. I suspect what has happened is there have been changes to collectory configuration for these resources after the data was originally loaded + processed. To be clear, if you make changes in the collectory mappings (provider codes, resource consumers etc), these will NOT be picked up in the searching until you re-run processing & indexing like so: biocache process -dr dr66 biocache index -dr dr66 Hope this helps, Dave On 13/09/2014 12:18 am, "Santiago Martinez de la Riva" <sama@gbif.es> wrote:

Hi all,

I updated our collectory module with the last release, collectory 1.1.2. And I found two issues that I would like to comment you.

1) DATASETS: http://datos.gbif.es/collectory/datasets/

In this url the datasets are never loaded. You can see in the Firebug that the page has 3 erros, one of these is the next:

TypeError: jQuery(...).autocomplete is not a function selectFirst: false

/collec...tasets/ (línea 70, col 16)

2) ADDING RESOURCES / COLLECTION / INSTITUTION: http://datos.gbif.es/collectory/public/show/in1

In this context, we have one Institution (in1) that has 2 collections. Now I'm goin to explain the procedure that I do to create these relations:

The first thing that I do is upload the resource, and after, I create the entities for that collection and that instution. In this moment, I edit the data resource and the collection for creating the relations:

- The first collection "Inventario Fauna Vertebrada de la Manchuela Conquense (CUENCA), 2007 (ADIMAN-MANCHUELA-2007)" is related to the data resource "dr40" that has 2.790, the collection code is ADIMAN-MACHUELA-2007 and the internal code/id is co3. The record consumer of the data resource "dr40" are co3 and in1. (image_1) but when I create the relation between this collection and the institution, the record cosumer are (view image_2)

- The second collection "Inventario de Flora y Vegetación del Municipio de Enguídanos (Cuenca), 2010 (ADIMAN-FLORA)" is related to the data resource "dr66" that has 5.291 records. The collection code is ADIMAN-FLORA and the internal code/id is co2. The record consumer of the data resource "dr66" are co2 and in1. (image_3) but when I create the relation between this collection and the institution the record cosumer are: (view image_4)

I think that in both cases, image_2 and image_4, are wrong, because, how is it possible that one collection contributes with digitised records to the other? This doesn't make sense.

When I have created this structure, then I do the ingest of these resource: ingest -dr dr40 ingest -dr dr66

But, what is my surprise that when I access to the page of each resource, I see that the total records of ADIMAN-MANCHUELA-2007 is the sum of the record of both collections, and ADIMAN-FLORA doesn't have records. You can see this in this links: - http://datos.gbif.es/collectory/public/show/co3 (ADIMAN-MACHUELA-2007) - http://datos.gbif.es/collectory/public/show/co2 (ADMINA-FLORA)

I can also create the provider Map for both cases, but I don't exactly know, if the provider codes have to be the internal codes like: in1, co2 and co3 or the orginal codes like ADMIN, ADIMAN-FLORA and ADIMAN-MACHUELA-2007. In the image_5 and image_6, you can see the ProviderMap for this case. Two question? - Is it necessary the use of these provider maps to create the relations? - Could you explain how works this matching code? I mean, It's possible that in one collection we have two collection codes, For example: in ADIMAN-MACHUELA-2007 we have other collection code that is ADIMAN-CENSOAVUTARDA-2008. I figure up that I can define these rules with the parameters: "exact" and "Match Any Collection Code". Is right?

Thanks so much for the help and sorry for this long message.

PD: I'm working also with the i18n, and soon we will have translated and implemented all the variables in the project. You can see some advance in this link http://datos.gbif.es/collectory, I have had to edit some javascripts to do all the translation.

-------------------------------------------------------------------------- ------------- Santiago Martínez de la Riva GBIF.ES, Unidad de Coordinación Tel. +34 91 4203017 x 273 Real Jardín Botánico - CSIC Fax +34 91 429 2405 Plaza de Murillo, 2 sama@gbif.es 28014 Madrid, Spain www.gbif.es

Ala-portal mailing list Ala-portal@lists.gbif.org http://lists.gbif.org/mailman/listinfo/ala-portal

Thanks again. --------------------------------------------------------------------------------------- Santiago Martínez de la Riva GBIF.ES, Unidad de Coordinación Tel. +34 91 4203017 x 273 Real Jardín Botánico - CSIC Fax +34 91 429 2405 Plaza de Murillo, 2 sama@gbif.es 28014 Madrid, Spain www.gbif.es ________________________________________ De: David.Martin@csiro.au [David.Martin@csiro.au] Enviado el: miércoles, 17 de septiembre de 2014 12:22 Para: Santiago Martinez de la Riva; ala-portal@lists.gbif.org Asunto: Re: [Ala-portal] DATASETS and MANAGE RESOURCES / COLLECTION AND INSTITUTION Thanks Santiago. Theres 2 issues here for the collectory: 1) dependence on BIE web service 2) ala.baseURL configuration which causes a problem with a javascript dependency We've just pushed out a 1.1.2 bug fix release (now deployed on ala-demo.gbif.org) This should fix 1). The ansible scripts are now using 1.1.2. For 2) the workaround for now will be to change your local configuration to ala.baseURL=http://www.ala.org.au This is something we're planning to refactor so there aren't references to www.ala.org.au. Cheers Dave On 17/09/2014 5:02 pm, "Santiago Martinez de la Riva" <sama@gbif.es> wrote:

Hi Dave,

In the point one, I mean that when the user wants to filter the datasets by some words, the javascript "dataset.js" executes always the next code and this is a problem because, the searches always point to:

In this case I have done a search in the vagrant machine 10.1.1.2 with the word "universidad" and the response is this json request:

http://bie.ala.org.au/search.json?q=universidad&fq=idxtype:DATASET&pageSiz e=1000&sort=name&callback=jQuery171022993668541156054_1410936808886&_=1410 937071339

It's obviously that this works in your demo-ala but not work in my case, because the datasets that I want to filter, are not in bie.ala.org.au.

DATASET.JS

function filterList() { // clear list of data sets clearList(); // clear search term $('#dr-search').val(''); // revert to full list resources = allResources;

// aggregate all search criteria var searchTerms = []; $.each(currentFilters, function(i, obj) { if (obj.name == 'contains') { searchTerms.push(obj.value.toLowerCase()); } });

// perform any solr search and wait for result if (searchTerms.length > 0) { $('.collectory-content').css('cursor','wait'); // build query string from terms var query = ''; $.each(searchTerms, function(i, term) { query += (i == 0) ? term : "&fq=text:" + term }); // do search

HERE---------> $.ajax({url:"http://bie.ala.org.au/search.json?q=" + query + "&fq=idxtype:DATASET&pageSize=1000&sort=name", dataType:'jsonp', success: function(data) { var uids = extractListOfUidsFromSearchResults(data); applyFilters(uids); $('.collectory-content').css('cursor','default'); } }); } // no search - so just do it now else { // do it now applyFilters(); } }

Kind regards Santi

-------------------------------------------------------------------------- ------------- Santiago Martínez de la Riva GBIF.ES, Unidad de Coordinación Tel. +34 91 4203017 x 273 Real Jardín Botánico - CSIC Fax +34 91 429 2405 Plaza de Murillo, 2 sama@gbif.es 28014 Madrid, Spain www.gbif.es

________________________________________ De: David.Martin@csiro.au [David.Martin@csiro.au] Enviado el: lunes, 15 de septiembre de 2014 4:07 Para: Santiago Martinez de la Riva; ala-portal@lists.gbif.org Asunto: Re: [Ala-portal] DATASETS and MANAGE RESOURCES / COLLECTION AND INSTITUTION

Thanks Santiago.

The released version of the collectory was actually 1.1.1. I can see you¹ve got the snapshot version 1.1.2-SNAPSHOT running (if you view source the version is in the header). I don¹t think there are any commits for 1.1.2-SNAPSHOT (yet), but we are trying to discourage folks from using snapshots and rely on the releases.

1) Heres the same page on the demo site with 1.1.1: http://ala-demo.gbif.org/collectory/datasets/

The problem has been caused by setting the configuration variable ³ala.baseURL² to "http://datos.gbif.es² instead of "http://www.ala.org.au"

ALA-DEMO version: <script src="http://www.ala.org.au/wp-content/themes/ala2011/scripts/jquery.autoco m plete.js" type="text/javascript" ></script>

ES version: <script src="http://datos.gbif.es/wp-content/themes/ala2011/scripts/jquery.autocom p lete.js" type="text/javascript" ></script>

We have plans to remove this import from the collectory, but in the meantime to fix the problem, switch to ala.baseURL=http://www.ala.org.au

2) To answer the specific questions:

- Is it necessary the use of these provider maps to create the relations?

Yes.

- Could you explain how works this matching code?

During the processing, when the biocache code encounters a new combination of institution code and collection code, it calls the collectory like so:

Example record: http://datos.gbif.es/generic-hub/occurrences/6a5c6786-9794-460d-8335-09354 0 9b999c

collectionCode=ADIMAN-FLORA institutionCode=ADIMAN

dataResourceUid=dr66

Web service lookup: http://datos.gbif.es/collectory/ws/lookup/inst/ADIMAN/coll/ADIMAN-FLORA

To be clear, the provider map codes should NOT be UIDs like ³co1² or ³in1². Provider map codes should be values that you are seeing in the raw data e.g. ADIMAN.

I think this is an example problem record:

http://datos.gbif.es/generic-hub/occurrences/9e59738e-56f9-41ea-ba64-106d6 5 1c0560

collectionCode=ADIMAN-MANCHUELA-2007 institutionCode=ADIMAN dataResourceUid=dr40

Web service lookup: http://datos.gbif.es/collectory/ws/lookup/inst/ADIMAN/coll/ADIMAN-MANCHUEL A -2007

So currently there isn¹t a mapping in place for that combination. I suspect what has happened is there have been changes to collectory configuration for these resources after the data was originally loaded + processed.

To be clear, if you make changes in the collectory mappings (provider codes, resource consumers etc), these will NOT be picked up in the searching until you re-run processing & indexing like so:

biocache process -dr dr66 biocache index -dr dr66

Hope this helps,

Dave

On 13/09/2014 12:18 am, "Santiago Martinez de la Riva" <sama@gbif.es> wrote:

...

Hi all,

I updated our collectory module with the last release, collectory 1.1.2. And I found two issues that I would like to comment you.

1) DATASETS: http://datos.gbif.es/collectory/datasets/

In this url the datasets are never loaded. You can see in the Firebug that the page has 3 erros, one of these is the next:

TypeError: jQuery(...).autocomplete is not a function selectFirst: false

/collec...tasets/ (línea 70, col 16)

2) ADDING RESOURCES / COLLECTION / INSTITUTION: http://datos.gbif.es/collectory/public/show/in1

In this context, we have one Institution (in1) that has 2 collections. Now I'm goin to explain the procedure that I do to create these relations:

The first thing that I do is upload the resource, and after, I create the entities for that collection and that instution. In this moment, I edit the data resource and the collection for creating the relations:

- The first collection "Inventario Fauna Vertebrada de la Manchuela Conquense (CUENCA), 2007 (ADIMAN-MANCHUELA-2007)" is related to the data resource "dr40" that has 2.790, the collection code is ADIMAN-MACHUELA-2007 and the internal code/id is co3. The record consumer of the data resource "dr40" are co3 and in1. (image_1) but when I create the relation between this collection and the institution, the record cosumer are (view image_2)

- The second collection "Inventario de Flora y Vegetación del Municipio de Enguídanos (Cuenca), 2010 (ADIMAN-FLORA)" is related to the data resource "dr66" that has 5.291 records. The collection code is ADIMAN-FLORA and the internal code/id is co2. The record consumer of the data resource "dr66" are co2 and in1. (image_3) but when I create the relation between this collection and the institution the record cosumer are: (view image_4)

I think that in both cases, image_2 and image_4, are wrong, because, how is it possible that one collection contributes with digitised records to the other? This doesn't make sense.

When I have created this structure, then I do the ingest of these resource: ingest -dr dr40 ingest -dr dr66

But, what is my surprise that when I access to the page of each resource, I see that the total records of ADIMAN-MANCHUELA-2007 is the sum of the record of both collections, and ADIMAN-FLORA doesn't have records. You can see this in this links: - http://datos.gbif.es/collectory/public/show/co3 (ADIMAN-MACHUELA-2007) - http://datos.gbif.es/collectory/public/show/co2 (ADMINA-FLORA)

I can also create the provider Map for both cases, but I don't exactly know, if the provider codes have to be the internal codes like: in1, co2 and co3 or the orginal codes like ADMIN, ADIMAN-FLORA and ADIMAN-MACHUELA-2007. In the image_5 and image_6, you can see the ProviderMap for this case. Two question? - Is it necessary the use of these provider maps to create the relations? - Could you explain how works this matching code? I mean, It's possible that in one collection we have two collection codes, For example: in ADIMAN-MACHUELA-2007 we have other collection code that is ADIMAN-CENSOAVUTARDA-2008. I figure up that I can define these rules with the parameters: "exact" and "Match Any Collection Code". Is right?

Thanks so much for the help and sorry for this long message.

PD: I'm working also with the i18n, and soon we will have translated and implemented all the variables in the project. You can see some advance in this link http://datos.gbif.es/collectory, I have had to edit some javascripts to do all the translation.

------------------------------------------------------------------------- - ------------- Santiago Martínez de la Riva GBIF.ES, Unidad de Coordinación Tel. +34 91 4203017 x 273 Real Jardín Botánico - CSIC Fax +34 91 429 2405 Plaza de Murillo, 2 sama@gbif.es 28014 Madrid, Spain www.gbif.es