[Go-essp-tech] Access control for data with different QC Level

[Karl Taylor]

Dear all,

I'll try to get to this later today.

Karl

On 7/20/10 7:52 AM, Martina Stockhause wrote:
> Hi, Bryan,
>
> thanks for writing the stuff down. I leave out the political and
> implementation issues because there are a lot of people who can comment
> on them much better.
>
> Just a question for clarification:
>    
>> b) when, where and how, do we set up the "table" which maps
>> access_token_required onto the dataset.
>>
>> Step 1). we need to record qc information.
>>   - the plan is to build a tool for that in September, to be complete by
>> the end of September, and it will export CIM quality documents via an
>> atom feed. It will  be independent of the questionnaire, and folks could
>> deploy it anywhere, even on a data node.
>>   (Martina: that can cover the DOI information too.)
>>   (I have someone in mind to do the work.)
>>
>>      
> As I understand, you suggest we have separate QC XML documents in the
> data nodes and no ingest or update of the CIM repository, right? This
> sounds to me like an intermediate solution. We should hold it small and
> easy. So, do we really need an XML for every experiment to create an
> AtomFeed out of them afterwards?
> Why don't we just keep small lists with DRS experiment name and QC level
> at the local data nodes or in the gateway?
> Additionally, the security mechanism, which asks for the QC level
> attached to certain data, needs to be quick, since the user tries to
> start a data download.
>
> By the way, I was told by metafor that quality is now a part of several
> CIM documents like simulationRun or dataObject but not an independent
> document any longer.
>
> Maybe your "someone" has already an idea to discuss.
>
> We could keep a second small list with DRS name and DOI link.
>
>    
>>   - we get qc level one for free (the data can't be published by a data
>> node without being qc level one).
>> - given that qc level 2 can only be dealt with at DKRZ, PCMDI and  BADC
>> since it will apply to replicated data, then we only need to deploy the
>> tool there, and gateways will only need to harvest from three places
>> - q3 information can only be made available at DKRZ
>>
>>      
> We can provide a link to additional quality information stored in CERA2
> if someone is interested.
>    
>> Step 2) the qc information needs to be harvested.
>> - this is a gateway issue,  need only to harvest from the three above,
>> plus the QC one at DKRZ.
>>   - It needs to be mapped onto each replica.
>>
>> Step 3) this information needs to propagate into the PDP (or whatever we
>> are calling the policy decision point, I've lost track of the names).
>>
>>
>>      
> Cheers,
> Martina
>
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://*mailman.ucar.edu/mailman/listinfo/go-essp-tech
>
>