Feature #1962
open
API: Entity export functions as Markdown
Description
See file sections for format suggestion.
Add a button in each item/form of Source, Event, Actor, Place, Artifact, Reference, Types that allows to export to print, PDF, Word, markdown, JSON, etc, and also the possibility to apply recursively to a selected group of items
I think it would be very useful get a kind of printed record of a items, containing all items related.
for example, when I export an Actor I would like to get sources, events, relations, members of, Artifacts, references, Files, Notes related to this actor.
I you Alex do a kind of seed/example, I would try to complete and format others, with my low level of Python, but effective.
Files
Updated by Alexander Watzinger about 1 year ago
- Subject changed from Add a button to export item to pdf or another formats to API: Entity export funtions for PDF and other formats
- Description updated (diff)
- Category set to API
- Status changed from New to Acknowledged
- Assignee set to Bernhard Koschiček-Krombholz
- Target version set to Wishlist
Thank you for reporting and the offer to help with the implementation.
There is already quite some export functionality available via the API, e.g. to JSON, RDF, CSV and turtle. It can be used when viewing an entity and having activated the Show API links in the profile.
I enabled this for the demo versions (where profile options can't be set by the demo user) so that it can be tested there, see e.g. https://demo.openatlas.eu/entity/6507
I'm not so sure about PDF regarding the effort and usefulness. I'm not in favor of Word because this being a format for proprietary software and OpenAtlas is all about open data exchange.
However, because this is in the area of Bernhard, I assign this issue to him for further evaluation and discussion.
Updated by Bernhard Koschiček-Krombholz about 1 year ago
Thank you for reporting. As Alex said, we already have some possibilities to export entities and also working on a new JSON format (#1770), which better maps the CIDOC CRM.
As for the formats, I don't think, that there is an easy way to make MS Word files, and as Alex said, it is not really open.
Markdown on the other hand is possible, and I thought of it myself. Technically, it should be not so hard to implement, but first we have to decided how it should look like, and it has to be dynamically. This means, that we only have one template for all entities. This will be the challenging part!
If Markdown is done, we can think about PDF export.
So, if it is ok for you, I will change the title of this ticket to "API: Entity export as Markdown" and we use it to create and discuss the implementation.
And at last, we can not include "Notes" of an entity, because Notes can be public or private, and is "linked" to a user.
Updated by Bernhard Koschiček-Krombholz about 1 year ago
- Subject changed from API: Entity export funtions for PDF and other formats to API: Entity export functions as Markdown
- Description updated (diff)
Updated by Bernhard Koschiček-Krombholz about 1 year ago
- Assignee deleted (
Bernhard Koschiček-Krombholz)
Updated by Bernhard Koschiček-Krombholz about 1 year ago
- Description updated (diff)
Updated by Enric Rodellas about 1 year ago
- File Actor-Markdown-proposal.pdf Actor-Markdown-proposal.pdf added
- File Actor-Markdown-proposal.md Actor-Markdown-proposal.md added
I attach 2 files
- Markdown template for author
- Resulting pdf (from Vscode)
- 'Real content'(to get some example
- name of file enclosed in {}, ex: {actorname}
Variables I inclosed with {} is that I guess that will process template with formatf of Python.
Anyway, when begins to develop this function, I can test, and also write other templates.
Updated by Bernhard Koschiček-Krombholz about 1 year ago
- Description updated (diff)
Dear Enric,
Thank you for your work. This looks nice. If I have time, I will start to implement this. But right now, I have many other things to complete, so it has to wait. But I like this and looking forward to implement it.
And just a clarification, we cannot add Notes, because they are bound to user, and the API doesn't know anything about user data.
Updated by Alexander Watzinger about 1 year ago
Thank you both for taking care about this approach.
I second what Bernhard said about notes, these are meant to be an internal workflow tool while entering data and aren't part of the data model.
Also I would suggest to not go into too much detail for e.g. actor and keep this more generic for all entities. Even if it is done "quickly" it still has than to be maintained for e.g. possible changes and data presentation is not the focus of the OpenAtlas backend.
But I sill like the idea to provide a generic .md presentation via the API which can be used as a starting point for own adaptions later.