[Repec-data] A first proposal

Christopher Baum kit.baum at bc.edu
Thu Aug 29 17:51:19 UTC 2013


Christian,

This does not make sense to me: the notion of creating one template per time series in a dataset. For instance:

> Federal Reserve Economic Data
> 
> Download, graph, and track 
> 148,000 US and international time series from 59 sources.


Would you suggest that if we include the FRED database, we should have 148,000 templates describing its contents?

Thanks
Kit

On Aug 29, 2013, at 12:41 PM, 'Christian Zimmermann' <zimmermann at stlouisfed.org>
 wrote:

> Let me throw in an example. Take the OECD Main Economic Indicators. You can structure them in various ways:
> 
> OECD MEI
> -> GDP
> --> France
> --> Germany
> -> Inflation
> --> France
> --> Germany
> 
> or
> 
> OECD MEI
> -> France
> --> GDP
> --> Inflation
> -> Germany
> --> GDP
> --> Inflation
> 
> My suggestion would be to have in such a case a "series" (in the sense of a collection) OECD MEI, and have each individual "time series" French GDP, French Inflation etc indexed with a separate template. The fields should describe the series in a sufficent way so that whoever is using the meatadata can cross it whichever way.
> 
> Of course, there are some datasets where the hierarchy is more evident, and one can define subsets in a unique way. But again, a RePEc service using the metadata could then recreate this easily from the templates without using sub-series templates. This works already well with journal
> articles that can easily be regrouped in volumes and issues based on metadata information despite all article template being in a big pile.
> 
> On Thu, 29 Aug 2013, David K. Levine wrote:
> 
>> a table (standard usage in SQL) has rows and columns, i.e. a matrix (not necessarily of numbers). Implementations can differ - there can be many tables in a file (an excel spreadsheet with a number of different sheets, some databases, but not all), or one table in a file, or a table could be split over many files. The point is the metadata should say which it is, the file being a more fundamental object for the purpose of analyzing data than the way it is divided or not divided into files.
>> 
>> ----- On 8/29/2013 07:52 am repec-data at lists.ope wrote -----
>> 
>> David K. Levine writes
>> 
>>> Not entirely sure I follow that.
>> 
>> Yeah, because you are not familiar with ReDIF, I suspect
>> 
>>> So: thinking of a dataset as a bunch of related tables
>> 
>> I'm not sure I understand what a "table" is here.
>> 
>>> it seems like
>>> we want one type of metadata to describe the dataset which seems to
>>> be what Christian proposed. Then I understood we should have a
>>> second type of metadata to describe what is are in the tables
>> 
>> I proposed "file" here. This is a more concrete thing than
>> a "table", I think.
>> 
>>> (at least for those datasets that do in fact consist of a bunch of
>>> related tables). The thing is,
>> 
>> ==
>> 
>> David K. Levine
>> 
>> Professor of Economics and Joint Chair RSCAS
>> Department of Economics                    http://www.dklevine.com/
>> European University Institute              phone:  [+39] 055 468 5954
>> Villa San Paolo                                     office: VSP 45
>> Via della Piazzuola 43
>> I-50133 Firenze - Italy
>> 
>> John H. Biggs Distinguished Professor
>> Department of Economics
>> Washington University in St. Louis     phone: [+1] 314 935 9529
>> Campus Box 12081 Brookings Dr.
>> St. Louis MO 63130-4899
>> 
>> 
>> 
>> _______________________________________________
>> Repec-data mailing list
>> Repec-data at lists.openlib.org
>> http://lists.openlib.org/cgi-bin/mailman/listinfo/repec-data
>> 
> 
> Christian Zimmermann                          FIGUGEGL!
> Economic Research
> Federal Reserve Bank of St. Louis
> P.O. Box 442
> St. Louis MO 63166-0442 USA
> http://ideas.repec.org/zimm/
> 
> _______________________________________________
> Repec-data mailing list
> Repec-data at lists.openlib.org
> http://lists.openlib.org/cgi-bin/mailman/listinfo/repec-data




More information about the Repec-data mailing list