polifonia-project / clef Goto Github PK

It helps to have a linkable URL.
In some cases, the URL overflows, e.g. https://projects.dharc.unibo.it/musow/view-1638795966-4064233

Snip:

From source code (No virtualenv)

• download the source code from the latest release or clone the repository
• install requirements.txt with pip (pip3 install requirements.txt)

This has to be pip3 install -r requirements.txt

fixed as per polifonia-project/web_portal#3

I'm using the new version of clef, and some problems occurred to me when creating and deleting templates:

• when a template is deleted, its JSON file is not removed from the folder "resource_templates". It is correctly deleted from the list inside the "ask_json.json" file, but it remains in the file "templates.json" list. This can create inconsistencies when loading the application. At the same time, if a template has been deleted and is created again with the same name, the file of the deleted one changes name by adding numbers to it, but it still stays both in the folder and the list in "templates.json" with the new status "deleted".

The same thing happens when it comes to resources: even if they have been deleted as triples from the knowledge graph, their turtle file stays in the folder resources.

Need the ability to hide triples from the front end, but make sure that they are not deleted from record graphs. This is necessary when there are values that should not be shown to users. Currently, if I import a graph via Blazegraph that contains triples that are not in the model, they are deleted if I edit the record via the back end.

Currently if I create two fields in the template creation page (regardless of type) w/ the same rdf property on the front end the values for each will be combined in the output of each. Example:

• One template field is named ‘Academic Discipline’: Textbox, dcterm:subject, value=entity
• Another is named ‘Primary Subject’: Textbox, dcterm:subject, value=URL

In the front end my record will display each field separately but combine all values for both. It would be useful to have a way for this to be split if needed such as in the above example where I want to make a clear distinction between what the values of the dcterm:subject property represent.

1. In the descriptions of a single attribute, if an apostrophe (') is inserted when creating the record every character after it won't be shown in the information box;
2. In the multimedia attribute, when a value is inserted it appears under the box in a white square which aspect instinctively recalls a pop-up widget for suggestions or recently deleted elements. In order to make it clearer that the value has been correctly inserted it would be better to find another visualization, e.g. a transparent background still under the box of insertion.
3. In the "Explore" page, the titles can only start with letters, there is no managing of punctuation which, if present, provides the following error:
   
   This passage is managed by the following lines in "../static/js/main.js":
   

It would be nice to have the possibility to recognise multiple language tags for strings both in the back and front end. Currently additional strings w/ language tags can be added to a triple via Blazegraph however the system doesn’t do anything with them.
In the back end there should be the possibility to specify the language of a string input (Text box > free text, Text Area, Dropdown/Checbox labels) as well as add additional ones. This should be available in the record creation form (rather than the template creation form).
For example if a template’s field matches text box > free text, the record creation form should display an additional option to specify the language of the input as well as the option to add more languages, in which case more fields will be required. Alternatively the language strings could be specified in the text input directly, with the @+letters+comma combination used to separate them in the graph (e.g. my string@en, mia string@it, etc…), as this combination is unlikely to occur naturally (?).

In template.html, the script lines with this structure:
$$("#type__$id option[value$$=$field['type']]").attr("selected","selected");
have no closing square parentheses ']'. This causes a syntax error when trying to modify the template since values are not loaded correctly.
This error is present in every version of CLEF currently available, so even after the correction in the new one it might happen that someone still encounters it.

The repository has moved here to continue the development beyond the usage in musoW. Here the previous issue tracker

To satisfy the constraints of complex models while preserving the usability and user-friendliness of the product, Template creators should be allowed to define multiple linked Templates (referring to different classes) to be associated with a single Web form. In other words, the end-user should be able to generate multiple Records (with different Classes) by filling a single form.

For instance, let's consider the following example about the modelling of provenance information with CIDOC-CRM:

<https://example.com/work/663763> a crm:E22_Man-made-object ;
     crm:P24i_changed_ownership_through <https://example.com/acquisition/22734637> ;
     crm:P24i_changed_ownership_through <https://example.com/acquisition/22734638> ;
     crm:P24i_changed_ownership_through <https://example.com/acquisition/22734639> .

<https://example.com/acquisition/22734637> a crm:E8_Acquisition ;
    crm:P22_transferred_title_to <https://example.com/person/223> ;
    crm:P4_has_time-span <https://example.com/acquisition_timespan/0466456> .

<https://example.com/acquisition_timespan/0466456> a crm:E52_Time-Span ;
	crm:P81a_end_of_the_begin "1640-01-01"^^xsd:date ;
	crm:p81b_begin_of_the_end "1862-12-31"^^xsd:date .

Instead of filling in three different forms (Man-made-object; Acquisition; Time-Span), the end-user will need to select the Man-made-object Template, fill in a "Time-span of the Acquisition" input field, and save the data. The system will automatically process it and generate three separate Records (one for each class).

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.