Categories of uncertainty

[michalkozak]

The TEI P5 Guidelines says (21.1.2):

To record uncertainty in a more structured way, susceptible of at least simple automatic processing, the certainty element may be used.

It would be very desirable for purposes of automatic processing or visualization of uncertainty to be able to categorize annotations of uncertainty.

According to the book "Data Uncertainty and Important Measures" by Christophe Simon, Philippe Weber and Mohamed Sallak (John Wiley & Sons, 2018) and other literature, the epistemic uncertainty is most often divided into the following four categories:

• 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.

• 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.

• Incompleteness corresponds to the fact that not all situations are covered. Often it is impossible to know every possible option available.

• Credibility (discord) 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.

We (https://providedh.eu/) postulate to add a new attribute "category" to the "certainty" element. It can be a semi-open list with the above mentioned categories. We do not want to limit others to this taxonomy of uncertainty.

[tuurma]

Thanks @michalkozak for your feature request. Would you be happy to describe your use case a bit more concrete, ideally with examples that illustrate it (and which could be incorporated in the Guidelines, should your proposal be accepted)?

On first read I wonder why not to use @ana attribute for the job, also, would you say there's an overlap between your postulated @category and existing @Locus attribute?

[ana]

Hi! Could you please use @ana @category and so on?

[jamescummings]

Wouldn't this better be solved by having <certainty> claim membership in att.typed? (Thus get @type and @subtype.)

[michalkozak]

Thanks for all your advice.

We are implementing platform for visual analysis of uncertainty in DH collections. In order to use @ana we have to define our taxonomy somewhere (in or outside the system) and link to categories. It is a possible solution, although it requires that links to our taxonomy will be persistent links. It's better to have these categories in the TEI specification.

Regarding @locus, this attribute indicates rather that the uncertainty concerns markup, attribute value or content of the element. Not the category of uncertainty.

The best I like the suggestion of @jamescummings to add att.typed to <certainty> in TEI specification. May I ask you to do so?

[tuurma]

Guess we should have it discussed with the rest of the Council but seems straightforward and I don't see why it would be wrong to have category in att.typed. I will try to put it on the agenda for our next monthly call (mid-November).

[michalkozak]

Yes, I don't mind adding @category to att.typed. It might be useful to have @category, @type and @subtype. But the problem is now, that <certainty> does not have assigned these attributes at all. See: <certainty> schema

[sydb]

I doubt we actually need a phone discussion — I think this is small enough we could probably handle it by e-mail. After all, <certainty> meets our criteria: it is repeatable and (as the OP ably demonstrates) is catagorizable. We already have at least 3 in favor (@jamescummings, @tuurma, @sydb) and I suspect @ebeshero is in favor or she would have said something agin.

[martindholmes]

I'm in favour of adding <certainty> to att.typed, but if there's a list of suggested values we might need to be cautious. The suggested list above includes "imprecision", which in TEI would normally be handled separately using the <precision> element. I'd like to keep the distinction between these elements clear if possible.

[tuurma]

Thanks @sydb, wasn't sure what's the correct procedure ;-)

I'm not convinced we even need the suggested value list for @type, thoughts @jamescummings @sydb @ebeshero @martindholmes?

[ebeshero]

@tuurma @sydb and all: For @type on <certainty> I do think this is one we could leave up to the encoders to decide or customize for themselves.

[ebeshero]

And by that I mean, yes, I like adding <certainty> to att.typed and I don't think we need a list of suggested values. Just leave it open.

[michalkozak]

Have you already decided to add @category or @type with @subtype to <certainty>?
I would like to ask you because the middle of November has passed.

If not, we will use @ana and <taxonomy>, which is also possible and has an additional advantage: we can add many uncertainty categories to one <certainty> element. Such a requirement appeared to us recently in the project.

[sydb]

Council VF2F agrees @tuurma is GO to add <certainty> to att.typed, and create an "open" value list of the OP’s suggested values (in a branch, of course).

That said, we think @michalkozak’s particular case might be better encoded with @ana, anyway.