amattioc
commented
9 years ago Hi, I think the example you do is correct: the right solution for me would be a RJEUROSTAT specific project that leverages RJSDMX and encapsulates all the peculiarities of that scenario. Otherwise the connectors would risk to become too complex and lack a generic perpective.
I see the connectors as a 'simple' plug that people can use to connect to SDMX data providers and obtain data in the most suitable native classes that the tool they are using allows. At the end of this journey data is no longer SDMX data, it is R or MATLAB or whatever tool they use native data. From here on, their process/solution/package starts :-)
Cheers, Attilio
This is a question related to my sidenote in #46. Have you developed an idea for the overall scope of the
SDMXpackage andRSDMXpackage in general? Is it intended as a low-level entry point to SDMX data which other packaged are supposed to build upon, of is the intention to create a one-stop SDMX-data-provider?I am asking this as for the sources I work with (EUROSTAT) I think it would make sense to wrap the retrieved data (including dictionaries) into an object structure (S3, S4). I think this would have the following advantages:
ggplot2Since this might make sense for Eurostat data (which is mostly of annual resolution) it could be problematic for data with higher resolution like exchange rates, so I don't know if such an object structure should be tackled in
RJSDMXor maybe rather in a downstream package tailored to a specific data provider (e.g. RJEUROSTAT).If you have any thoughts on that matter I would be keen to hear your opinion. My overview of the SDMX process as well as R-programming is currently quite limited, so I would be happy to get an expert opinion.
Best Albrecht