Issue 12064

Update for limnodata dataset 1466

12064
Reporter: kbraak
Assignee: jlegind
Type: Bug
Summary: Update for limnodata dataset 1466
Priority: Major
Status: Open
Created: 2012-10-23 13:49:57.011
Updated: 2013-12-13 13:44:20.549
        
Description: On Oct 23, 2012, at 1:24 PM, Xander van der Sar wrote:

Dear Jan and others,

I have done some research on updating the limnodata dataset (http://data.gbif.org/datasets/resource/1466/). As i remarked previously, we want to migrate this dataset from TAPIR to the IPT. At the same time we want to change the owning organisation for NLBIF to STOWA (http://gbrds.gbif.org/browse/agent?uuid=68a216ee-f721-40cd-932c-84153afd9451).

The description about migrating says this is not possible, because the dataset owner needs to stay the same. Is this correct? And if so, what are the alternatives for migrating this dataset.

With kind regards,

Xander]]>
    


Author: kbraak@gbif.org
Created: 2012-11-01 20:40:26.837
Updated: 2012-11-01 20:40:26.837
        
I rearranged the owning organization in the registry and have given Xander the proper set of instructions to update the resource from his IPT.

On the side of indexing, we will have to add STOWA to the data_portal table, and update resource 1466 to use this new entry in order to preserve the data resource ID in the portal. Otherwise, on indexing, a new data provider and data resource will get created.

More followup needed in the Registry after all this:

1) add the IPT serves dataset relationship
2) delete the TAPIR serves dataset relationship (if the whole TAPIR installation is to disappear, but there is yet 1 more dataset being served by it)
    


Author: kbraak@gbif.org
Comment: This morning I added STOWA to the data_portal table, and updated resource 1466 to use this new entry in order to preserve the data resource ID in the portal. Next step, indexing.. 
Created: 2012-11-05 12:18:02.398
Updated: 2012-11-05 12:18:02.398


Author: kbraak@gbif.org
Created: 2012-11-16 10:21:13.437
Updated: 2012-11-16 10:21:13.437
        
One thing we still need to check:

Do the GBIF Log Messages need to be updated also?
    


Author: ahahn@gbif.org
Created: 2012-12-04 13:30:57.316
Updated: 2013-01-18 11:48:47.42
        
Need to discuss: in principle, leaving the old data provider id in old log messages is factually correct, as the messages were logged at a point where the old provider was in control of the dataset, so usage logs and feedback messages summarised for the provider would be correctly attributed over time.

However, we need to check whether this might cause technical issues in the portal application. Leftover log messages after record deletions used to cause some rather grave errors in the data portal, so that we need to check there are no implications on that side if log messages reference an organisation that is no longer linked to the dataset in question.

For 1466, the situation currently is
PROCESSING> select distinct(data_provider_id),count(*) from gbif_log_message where data_resource_id = 1466 group by 1;

| data_provider_id | count(*) |
|              139 |   450165 |
|              472 |        4 |

    


Author: ahahn@gbif.org
Comment: I am not sure what the status on this is - has it gone out of scope/ been resolved?
Created: 2013-12-13 13:44:13.497
Updated: 2013-12-13 13:44:13.497