-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS Viewer: Download Data Package Function #43
Comments
@skarampatakis I think this probably should be done by openspending, as os-explorer on OpenBudgets is deployed by directly using the code from https://github.com/openspending/os-explorer. |
I think this is configured somewhere here. Original OS Viewer behavior is to show two links, one for the raw data and one for the datapackage. |
Hi. We have a low priority backlog item for creating ZIP downloads on Openspending, but we likely will not do this ourselves, as this can be very resource intensive for little gain. For RDF, as the vast majority of data used in the Viewer generally does not have an RDF representation, we wouldn't add it as a general option on the Viewer, but it is the type of thing we could have a pull request for to add this functionality in certain conditions (such as on the Fraunhofer server where you know there is an RDF version of the data). |
I see also ZIP files as low priority. But the rest is doable with ease. just add another
on the template and somehow feed the link href with the proper path. Something like that I agree that this is OBEU specific and that's the purpose of |
@skarampatakis sorry for the delay in replaying and thanks for pointing me out. I checked the |
What you mean by this? Every dataset id in rudolf->OS Viewer is the same as it's filename minus the hash. Perhaps you could only change the folder structure as you can't know where exactly that file is, because some are coming from custom pipelines where user can define whatever folder he/she wants or to the Unless you make a These kind of problems could eliminate if only every dataset used what was decided in D1.5 for metadata. At least FDP2RDF pipeline could use this to define the distribution metadata. We are doing this in the CSV2RDF pipeline template
So you could ask the triplestore or Rudolf could provide this kind of information. Another solution would be to create the dump on demand, store it somewhere for future use and send it to the user. This would be also a good solution as you could create the dumps as you like in whatever format. At least for datasets we have transformed in early days, it is a fact that they have separate files for datasets, DSDs and codelists. So, by reconstructing the dump, you could provide the full dump of the dataset and other triples that describe the dataset and not a partial one. |
For example, the dataset in page The title in the page and the title of the dataset does not match. If it follows the same pattern, then of course, it is still possible to locate the dataset. |
The FDPtoRDF pipeline now follows what @skarampatakis described. The URL of the data dump is now stored in dataset metadata as FYI, since it was a small change, I made it directly on the Fraunhofer server to speed up the process. But I of course also updated the pipeline on GitHub. |
Hi @marek-dudas, that means that the triples should be:
e.g.
as can be seen here |
Thanks, I apparently misread the documentation, will fix it. |
It should now be corrected, according to the description above. |
@larjohn @marek-dudas do you have any idea about how to fix this? thanks. |
It should be fixed now - it will be visible in the next refresh. |
I tried this dataset http://apps.openbudgets.eu/viewer/aragon-2016-expenditure__9121b?lang=en
This dataset was generated by a custom pipeline. Is this the root of the problem? |
This can be seen here: http://data.openbudgets.eu/page/dataset/aragon-2016-expenditure/distribution |
Current behavior of the "Download Data Package" button is to redirect the user to the dumps folder.
It could make more sense if it could give the option to get the dataset in various formats (FDP, RDF, zip)
The text was updated successfully, but these errors were encountered: