Redmine: Issueshttps://redmine.openatlas.eu/https://redmine.openatlas.eu/favicon.ico?17112826112024-03-26T17:31:55ZRedmine
Redmine OpenAtlas - Feature #2244 (Assigned): Import of place hierarchyhttps://redmine.openatlas.eu/issues/22442024-03-26T17:31:55ZBernhard Koschiček-Krombholz
<p>This is a follow-up ticket from <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Enhanced Import (Closed)" href="https://redmine.openatlas.eu/issues/1567">#1567</a> Enhanced Import.<br />Since all prerequisites are met, the import of a place hierarchy can be implemented. <br />As example structure, Stefan Eichert provided this CSV: <a class="external" href="https://docs.google.com/spreadsheets/d/1IIPGKvSRNi6Qeir6070VS4u7uvHdlpYenEhRkCaGJcI/edit?usp=sharing">https://docs.google.com/spreadsheets/d/1IIPGKvSRNi6Qeir6070VS4u7uvHdlpYenEhRkCaGJcI/edit?usp=sharing</a></p>
To-do:
<ul>
<li>Add new import button "Place hierarchy" </li>
<li>Link existing references with ID including page number</li>
<li>OpenAtlas Class name to know which level the place is</li>
<li>Parent import ID</li>
</ul> OpenAtlas - Feature #2243 (Acknowledged): Persistent identifiers for transformed actors/artifacts...https://redmine.openatlas.eu/issues/22432024-03-25T13:13:48ZThom Gobbitt
<p>It would be very useful to be able to have persistent identifiers for things which have been transformed, so that searching for a specific thing will produce all its forms. I need to illustrate this with a concrete example:</p>
<p>In Paul the Deacon’s late eighth century historical text the History of the Lombards, he recounts the battle between the Langoabrds and the Gepids. during which:</p>
<p>E21:Actor“Alboin” kills E21:Actor”Cunimund”.<br />As such, Actor “Cunimund” now becomes E20:Human_Remains “Cunimund’s body”. As the system currently works, the activity where this happens both Cunimund and Cunimund’s body are added in to the database, but there is no way to express that oen becomes the other. they are both represented in the database as simply being present.</p>
<p>Actor“Alboin”, then decapitates Human_Remains“Cunimund’s Body” turning it into Human_Remains“Cunimund’s Head” and Human_Remains“Cunimunds Headless Body”. (Alboin then leaves the body on the battlefield and takes the head with him)<br />Here we have a straight transformation of one artifact (human remains) into another, but the E11:Modification event doesn’t seem to have the option to identify and link the start and end forms of the artifact/human remains.</p>
<p>Actor:“Alboin” then modifies Human_Remains“Cunimund’s Head” into an E22:Artefact“Drinking Cup”<br />Again, there doesn’T seem to be away to make it clear that E21:Actor:“Cunimund”, E20:Human_Remains “Cunimund’s Head” and E22:Artifact“Drinking Cup” are all different phases of the same person/object’s biography.</p>
<p>Being able to mark this clearly is not just useful ,but essential as without it key information will be lost. e.g:<br />Later at a feast, Actor “Alboin” forces his wife “Actor“Rosemunda” to drink a toast from Artifact“Drinking Cup”. But without the chain of modifications being integrated into the database, it will conceal the detail that Actor“Rosemunda” is also Actor “Cunimund”’s daughter.</p>
<p>Would it be possible to make some kind of (e.g.) “entity” entry, that can then have actors, artefacts, etc. linked as subordinate items to it?</p> OpenAtlas - Feature #2242 (Acknowledged): Contextual/hierarchical arrangement of subordinate itemshttps://redmine.openatlas.eu/issues/22422024-03-25T12:50:26ZThom Gobbitt
<p>Where various types under <strong>E5 “events”</strong> have subordinate events, it would be very useful to be able to toggle the view between the (current) alphabetical arrangement, and a contextual/hierarchical view.</p>
<p>In such a view, items which are subordinate to a main event (which I understand as comprising a breakdown into individual phases of the main event, should be a) indented below the main heading, and b) arranged in chronological order so events are immediately followed by events which they precede. Such chronological arrangement should, of course, be used for any two events that have a chronological relationship, regardless of whether they are subordinate or main events.</p>
<p>It would probably also be useful to have an option to expand or hide the subordinate items under a given heading, both individually and with “expand all” or “hide all” buttons.</p>
<p>This approach shouldn’t only be for events, but would also be useful for other types of entry: e.g. “Sources” (when the vital <a class="issue tracker-2 status-7 priority-4 priority-default" title="Feature: Sub documents for sources (Acknowledged)" href="https://redmine.openatlas.eu/issues/1970">#1970</a> “sub documents for sources” is implemented); “artifacts” and “places” if the ability to make one subordinate to another (per <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Manual: Subordinate artifacts (and places) (Closed)" href="https://redmine.openatlas.eu/issues/2241">#2241</a>), were to be added.</p> OpenAtlas Discovery - Feature #2237 (New): Test: Create tests that test functionality like naviga...https://redmine.openatlas.eu/issues/22372024-03-19T10:10:07ZMoritz Großfurtner
<p>If the environment variable making the db view available is set, the test should check for an element on that page.<br />If it isn't set, the test should check that you can't navigate to the site.</p> OpenAtlas - Feature #2230 (New): Linking sources with other sourceshttps://redmine.openatlas.eu/issues/22302024-03-13T14:30:05ZNicholas Melvani
<p>I have a drawing (SOURCE) containing the text of an inscription (SOURCE) written on a marble base (ARTIFACT). I have tried two ways of entering data: 1. I created a SOURCE entry for the drawing (<a class="external" href="https://mamems.openatlas.eu/entity/8789">https://mamems.openatlas.eu/entity/8789</a>), entered the text of the inscription under TEXT, and linked the SOURCE entry with the ARTIFACT (the marble base). 2. I created a SOURCE entry for the inscription itself (<a class="external" href="https://mamems.openatlas.eu/entity/5736">https://mamems.openatlas.eu/entity/5736</a>), entered the text under TEXT, and linked the SOURCE with the ARTIFACT (see attached jpeg). However, in both cases, I am losing the connection between the two sources, the drawing and the inscription. Is there a way to link them?</p> OpenAtlas - Feature #2223 (In Progress): Refactor and minor improvementshttps://redmine.openatlas.eu/issues/22232024-02-28T11:25:59ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<strong>To do</strong>
<ul>
<li>Forms: move entity collection from table form fields to form manager</li>
</ul> OpenAtlas - Feature #2200 (Assigned): API: Expand LPF formathttps://redmine.openatlas.eu/issues/22002024-02-22T14:51:33ZBernhard Koschiček-Krombholz
<p>For OpenAtlas Discovery we decided to make a new format out of Linked Places so we can experiment and test it without breaking the original format. In the end of this process, this format will most likely replace the current LPF. All changes are always in the current develop branch and I will not keep track, which change made it to the current main branch. <br />Please feel free to add to-dos.</p>
<p><strong>To do</strong>:</p>
<strong>Done</strong>:
<ul>
<li>Added <code>relations.relationTypeLabel</code> to have the property label without property code and the right <code>locale</code> (<code>?locale=[en, de, ca, es, fr]</code>) if available.</li>
<li>Changed <code>relations.relationType</code> to the correct reference with <code>_</code>, eg. <code>crm:P2_has_type</code></li>
</ul> OpenAtlas Discovery - Feature #2194 (Acknowledged): Designing individual siteshttps://redmine.openatlas.eu/issues/21942024-02-21T15:08:59ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>Like discussed we start with designing the individual sites for different class detail views, e.g. place, person, ...<br />See <a class="wiki-page" href="https://redmine.openatlas.eu/projects/openatlas-discovery/wiki/Site_designs">draft</a>.</p> OpenAtlas - Feature #2171 (Acknowledged): Autocomplete form fieldshttps://redmine.openatlas.eu/issues/21712024-02-01T12:09:16ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>Like discussed in the last developer <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Meeting_2024-01-31">meeting</a> to counter possible performance issues for projects with big data sets we will try out the approach using autocomplete fields.<br />Advantage would be that data is only loaded when typing into respective fields instead loading data tables for all fields every time.</p>
<p>Because this is experimental we will keep it optional and configurable in the profile to use this approach.<br />One good suggestion from Stefan (Probst) was to not limit the results but make them "endless" scroll-able. We could try this out with already existing GeoNames and Wikidata fields.</p> OpenAtlas - Feature #2170 (Acknowledged): Tags on project sitehttps://redmine.openatlas.eu/issues/21702024-02-01T11:14:01ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>As discussed in last developers <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Meeting_2024-01-31">meeting</a> we want to invite non cooperation partners to represent there OpenAtlas projects on our site too.<br />For that we are thinking about using tags to add information about projects presented which also would help with navigation/filtering, see <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Project_topics">draft</a>.</p>
<p>Also we might want to re-think the menu labels while at it. The "Projects" and "Cooperation" item was reported as confusing by some.</p> OpenAtlas - Feature #2169 (Assigned): SEO - Additional metadata for the project sitehttps://redmine.openatlas.eu/issues/21692024-02-01T10:57:02ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>In last developers <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Meeting_2024-01-31">Meeting</a>, Stefan (Probst) kindly offered to help out with metadata for SEO at our project site (<a class="external" href="https://openatlas.eu">https://openatlas.eu</a>).<br />This can be done via pull request and would most likely be about this file: <a class="external" href="https://github.com/craws/OpenAtlas-Website/blob/main/openatlas_website/templates/layout.html">https://github.com/craws/OpenAtlas-Website/blob/main/openatlas_website/templates/layout.html</a></p> OpenAtlas Discovery - Feature #2165 (Acknowledged): Options to show a map on the start pagehttps://redmine.openatlas.eu/issues/21652024-01-23T15:34:29ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
<p>Like discussed in the <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Meeting_2024-01-23">last meeting</a> with Nicholas from the Approaching Byzantium project, showing an interactive map on the first page would be a good idea to convey a lot of information about the project at first glance.</p>
We could try to implement this for the general code base with setting some options, e.g.
<ul>
<li>Option if a map is shown</li>
<li>Dimensions of the map (e.g. full width or a smaller)</li>
<li>Zoom factor </li>
<li>Center point of shown map</li>
</ul> OpenAtlas Discovery - Feature #2164 (Assigned): CMS: Inform users about deplay delay via success ...https://redmine.openatlas.eu/issues/21642024-01-23T10:24:58ZMoritz GroßfurtnerOpenAtlas Discovery - Feature #2163 (In Progress): Documentation for Decaphttps://redmine.openatlas.eu/issues/21632024-01-22T14:04:30ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
It would be nice to have a documentation/help button at the main menu on top.<br />For now a very basic documentation would suffice, we can extend it than as needed. Some important points for now would be:
<ul>
<li>General instruction how to navigate</li>
<li>Explain that deployment will always need some time to see it live</li>
<li>Make aware that content (text and images) is public visible in GitHub (even if they just try something out)</li>
</ul> OpenAtlas - Feature #2161 (Acknowledged): Clean up translationshttps://redmine.openatlas.eu/issues/21612024-01-21T19:21:02ZAlexander Watzingeralexander.watzinger@oeaw.ac.at
Our translation system works but it has evolved and we learned a lot over time, e.g.:
<ul>
<li>Don't capitalize at the beginning of a translation (if it is not capitalized in the respective language)</li>
<li>Don't translate punctuation marks at the end (e.g. a question mark) which should be "hard coded"</li>
</ul>
<p>Although we making new translations more correct now, the former ones should be cleaned up. This could be a bit of work because all translated languages must have to be checked and correctly "refilled".<br />E.g. if a translation identifier changed to a non capitalized beginning the former translation still can be used (not capitalized), but it still needs some manual work to go through them.</p>
<p>In case somebody has the time/motivation to do this please contact me before to discuss what/how to do this.</p>
Some notes:
<ul>
<li>Documentation: <a class="wiki-page" href="https://redmine.openatlas.eu/projects/uni/wiki/Translations">Translations</a> workflow</li>
<li>Especially JavaScript confirm messages should be overhauled</li>
<li>I'm still not sure how to best translate bigger text blocks</li>
</ul>