User should define names, descriptions and colours of uncertainty categories

[michalkozak]

When project is created a user should have possibility to change names, descriptions and colors for user recognized uncertainties. The default values for names and descriptions are in the following template TEI file with default taxonomy:

<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0">	
  <teiHeader>
    <fileDesc>
      <titleStmt>
        <title>Uncertainty Taxonomy for project @ProjectName</title>
      </titleStmt>
    </fileDesc>
    <encodingDesc>
      <classDecl>
        <taxonomy>
          <category>
            <catDesc>User recognized uncertainty</catDesc>
            <category xml:id="ignorance">
              <catDesc>Ignorance</catDesc>
              <desc>Ignorance is related to the fact that information could have been incorrectly assessed by the person gathering or organizing the data. It is also possible that people, not fully sure about how to deal with data, ignore some information and generate uncertainty during the evaluation and decision processes.</desc>
            </category>
            <category xml:id="credibility">
              <catDesc>Credibility</catDesc>
              <desc>Credibility concerns the weight that an agent can attach to its judgment. This concept can be linked to that of biased opinions, which are related to personal visions of the landscape, which can make for significant variations between different groups and individuals, given their backgrounds.</desc>
            </category>
            <category xml:id="imprecision">
              <catDesc>Imprecision</catDesc>
              <desc>Imprecision corresponds to the inability to express the true value because the absence of experimental values does not allow the definition of a probability distribution or because it is difficult to obtain the exact value of a measure.</desc>
            </category>
            <category xml:id="incompleteness">
              <catDesc>Incompleteness</catDesc>
              <desc>Incompleteness corresponds to the fact that not all situations are covered. Often it is impossible to know every possible option available.</desc>
            </category>
          </category>
          <category>
            <catDesc>Machine generated uncertainty</catDesc>
            <category xml:id="algorithmic">
              <catDesc>Algorithmic</catDesc>
            </category>
          </category>
        </taxonomy>
      </classDecl>
    </encodingDesc>
  </teiHeader>
</TEI>

When user define these values for a project, then colors should be stored in the database, and names and descriptions in the generated TEI file with a taxonomy for this project. Identifiers for categories should be generated form names by applying lowercase method and replacing whitespaces with a dash.

After defining these values, only colors should be changable in Project Settings View.

The genareted TEI file should be exposed in some URL in a scope of the project in order to ana attribute could refer to the nodes of this XML. It's connected with the task #11.

There is a need for API that returns the names and colors of all uncertainty categories, for instance in order to the annotator could properly handle them.

[virdiignis]

I've created branch, added model for taxonomy, and fields in file upload modal in this commit:
ca9c1d8
Would be nice if @Janchorizo could style the inputs.

[virdiignis]

in c6b928b endpoint to retrieve TEI schema is added under GET /api/projects/<project_id>/taxonomy/

[Janchorizo]

Should this be extended to a new issue for the use case of defining different names and color schemes for entities?

[virdiignis]

@Janchorizo I see that you added some js code for colours and certanity categories handeling. Could you tell me how you want the data regarding that passed from backend? Some sample json would be nice.

[Janchorizo]

Hello. I am currently working on making the annotator work with an arbitrary amount of entities
and certainty categories, Including their own color and icon schemes. However I would not expect to expose this through an API endpoint for the following reasons:

• Making the UI load asynchronously would make the following calls delay even more and end up with unnecessary long loading times for the annotator.

• This information (the user's settings for entities and categories) can be easily provided from within the view method.

• These settings are prone to be static, once set, and even if changed it probably would not be from within the annotator. This means that there is no clear idea about when to update the UI, thus about when to make the API call.

• Asynchronous updates of the UI are prone to confusion and ,even if added, they would be done using web-sockets. For this, there yet not a clear specification about all that would be needed to provided.

• Changing a global setting in the legend of the annotator may not be a good idea because it seems like the user would expect that change to be local to this app. It has to be further discussed.

In summary, I think we can provide the settings in the view to speed up loading, and avoid changes in the UI and modification of the global settings until we are sure about the best way to approach it.