Santiago Martinez de la Riva sama at gbif.es
Wed Sep 17 09:02:26 CEST 2014

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 with the word "universidad" and the response is this json request:


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.


function filterList() {
    // clear list of data sets
    // clear search term
    // revert to full list
    resources = allResources;

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

    // perform any solr search and wait for result
    if (searchTerms.length > 0) {
        // 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",
            success: function(data) {
                var uids = extractListOfUidsFromSearchResults(data);
    // no search - so just do it now
    else {
        // do it now

Kind regards

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 at gbif.es
28014 Madrid, Spain                                 www.gbif.es

De: David.Martin at csiro.au [David.Martin at csiro.au]
Enviado el: lunes, 15 de septiembre de 2014 4:07
Para: Santiago Martinez de la Riva; ala-portal at lists.gbif.org

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:

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:
plete.js" type="text/javascript" ></script>

ES version:
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?


- 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:



Web service lookup:

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:



Web service lookup:

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 +

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,


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

>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)
>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.
>    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.
>    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
>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
>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 at gbif.es
>28014 Madrid, Spain                                 www.gbif.es

More information about the Ala-portal mailing list