polifonia-project/clef

Notes on possible future developments

Opened this issue · 0 comments

Two suggestions for possible future developments of the application:

  • Provide the possibility to at least visualize more entities that describe the same resource on the same page. Currently, if an object needs more classes to be specified to describe it, it is necessary to provide a single template for each aspect and link them through a property. It would be preferable to have one template that can host more than one entity with its relative description, but it would be enough even to continue with the creation of different templates but allow the user to visualize them into a unique webpage.
  • Another functionality that could be useful is to decide for each template which attributes are compulsory, in order to oblige during the data insertion to provide a minimum level of information for a resource to be added to the database.
  • Since titles are the mandatory field, the one that appears in browsing the app, they should be unique, because in the end if two records have the same title, even if it does not create inconsistencies, at least they slow the navigation of the users, which should check each resource and it can bring misunderstandings and errors when adding new information related to that item (even if the preview try to prevent this).
    It would be better and easier to have them as IDS since they already behave like them. If titles are constructed as IDs, or by adding an independent mandatory ID field, ta semantic-meaningful label for the URI of the resource could be provided too.
    In fact, the use of a timespan as a label in the long term makes it harder to maintain the application: at the triplestore level it is impossible to state which resource I'm searching from its link; from the application, it would be impossible to pick the right one if for any reason a manual check is needed, even harder since the turtle file of a deleted resource is not deleted in its folder. The fields of each template are managed through timespan too, and this is the most tricky problem for the customization of the application since it is impossible to manage fields separately, without adding some specific code in which the timespan should be manually updated. Adding semanticity to those ids, e.g. keeping the name of the field inside the id, will increase the overall usability of the app.