Re: [GUSDEV] Storing a provider name for an external database

[Chris S. <sto...@pc...>]

Hi John,
I'm putting this on the gusdev list as non-ApiDB users may have  
similar questions or some insights to offer.

As we just discussed offline, your task here is not to capture where  
the dataset was downloaded but rather who submitted the dataset to  
the resource (e.g., GenBank)  we got it from. ExternalDatabase and  
ExternalDatabaseRelease are meant for the former. Provider  
information (who should be given attribution) should be captured in  
the SRes.Contact table. I don't see an explicit attribute for a home  
page (the URL) but perhaps one of the RAD people can suggest a  
solution since they use Contact extensively for attribution of  
microrarray studies and and samples.

Chris

On Jan 24, 2007, at 5:04 PM, John Iodice wrote:

> Chris,
>
> The attribution info at the bottom of PlasmoDB sequence pages is  
> currently generated by the JSP code, as a function of the species  
> and sequence source_id.  The attribution data in the GFF files we  
> upload to to the Interoperability Working Group are calculated in  
> the SQL in the model files.  We'd like to store this attribution  
> info in the database instead.
>
> There are four character strings to be stored for each dataset:
>
> the dataset name (e.g. "Plasmodium falciparum mitochondrial genome")
> the data provider's name ("London School of Hygiene & Tropical  
> Medicine")
> a short version of the provider's name ("LSHTM")
> the URL ("http://www.lshtm.ac.uk/pmbu/staff/dconway/dconway.html")
>
> Steve and I talked about this today.  We're proposing to store the  
> dataset name, short name and URL in ExternalDatabase.name,  
> ExternalDatabaseRelease.id_type, and  
> ExternalDatabaseRelease.id_url, respectively.  We're proposing the  
> addition of a new varchar column named "provider" to the  
> ExternalDatabaseRelease table.
>
> What do you think of this?  Is there a better way?  Does GUS  
> already support this?
>
> Thanks for any feedback you can give us.
>
> John