search

UniStuttgart-VISUS / damast

Code for the DH project "Dhimmis & Muslims – Analysing Multireligious Spaces in the Medieval Muslim World" (VolkswagenFoundation)
MIT License
10 stars 1 forks source link

Changes on the automatically generated report #112

Closed rpbarczok closed 2 years ago

rpbarczok commented 2 years ago

I looked through the record and I like to to suggest the following improvements:

1.) Query report: The first three filters of the query report “evidence must be visible”, “place must be visible” and “place type must be visible” is to my knowledge not part of the filter possibilities of the visualization. Someone has to know the data structure quite well to understand these statements. Therefore, I believe the users will be confused by them. Additionally, to my knowledge, no data in the DhiMu project is hidden. Therefore, I would like these statements to be removed if there are no other objections.

2.) Evidence a) I would rather have the evidences sorted by a) city name, b) religion name, c) start of the time span b) In the English lexicography there is not plural form of Evidence. An English speaker would rather use the term “Pieces of Evidence”. I think we have to change that. c) The evidence fragment of the report distinguishes between hidden and visible data. Is there a case when hidden data is shown in the report? To my knowledge hidden data is not part of the publicly available filtering system? In any case: No hidden evidences, places or region should be part of the DhiMu-data, so it does not need to be included in the report. d) I would like to move the footnote with the evidence comment to the end of the sentence. e) We should use “…religious group…” instead of Religion f) If I understand the source code correctly, a place with the category “unknown” is displayed as “place”. Maybe it would be better to add an “undefined” to it: “undefined place”. What do you think? g) I would rather have a colon between the short title of the source and the content of the source_instance.source_page cell. h) I would like to move the source comment into a footnote at the end of the sentence.

3.) Places a) According the place type "unknown", I suggest to add "undefined" to "place" as above. b) I would like to have the list items in the „Linked to“ section in the following way:

is linked to: Digital Atlas of the Roman Empire (DARE): http://imperium.ahlfeldt.se/places/22329 i.e. without the short title and the ID at the beginning. @tutebatti, @mfranke93: what do you think?
tutebatti commented 2 years ago

Do you mean report instead of record?

tutebatti commented 2 years ago

b) In the English lexicography there is not plural form of Evidence.

I do not think so: "In general English, evidence is always uncountable. However, in academic English the plural evidences is sometimes used: (specialist) The cave contained evidences of prehistoric settlement." (https://www.oxfordlearnersdictionaries.com/definition/english/evidence_1)

d) I would like to move the footnote with the evidence comment to the end of the sentence.

Could you provide a screenshot?

f) If I understand the source code correctly, a place with the category “unknown” is displayed as “place”.

This I don't understand.

Other than that, I agree to the rest of what you propose. :)

rpbarczok commented 2 years ago

Yes, of course, report. 2b) I stand corrected

2d) Evidence comment

2f) https://github.com/UniStuttgart-VISUS/damast/tree/main/dhimmis/reporting/templates/reporting/fragments/evidence.html line 28-30. We have at the moment four types: region, monastery, settlement, and unknown. According to the code, a place is either described by its place type or, when unknown by the unspecified "place". I am not happy with this designation since the place type "unknown" usually designates places where we do not know whether they designate settlements or regions. So I think "undefined place" would be better. I also thought about "geographical entity" but I think that is to broad. Perhaps you can think of something better.

tutebatti commented 2 years ago

So I think "undefined place" would be better. I also thought about "geographical entity" but I think that is to broad. Perhaps you can think of something better.

Geographical entity sounds like a mountain, river, or whatever, maybe something like a town or settlement, but monastery would not come to my mind. So "undefined place" sounds good.

I also see what you mean with the fn. regarding your point 2d.

No more questions, all suggestions approved. ;) I hope, it's easily implementable by @mfranke93?

tutebatti commented 2 years ago

This should be implemented before initial release because the reports are static and will not be updated after later changes (correct?).

mfranke93 commented 2 years ago

1.) Query report: The first three filters of the query report “evidence must be visible”, “place must be visible” and “place type must be visible” is to my knowledge not part of the filter possibilities of the visualization. Someone has to know the data structure quite well to understand these statements. Therefore, I believe the users will be confused by them. Additionally, to my knowledge, no data in the DhiMu project is hidden. Therefore, I would like these statements to be removed if there are no other objections.

I see a larger issue here. See also #3 for this, because "no data in the DhiMu project is hidden" is a statement that only applies to the HU version of the data. Visibility of evidences, places, and place types are baked into the database and the code. Your requirements from the start (I can find you the respective issues later if you want) was that these should not be in the visualization. Consequently, I assumed they should not be in a report generated from said visualization. And in that case, this (kind of implicit) filter criterion should in my opinion be specified as well.

I see two options how to resolve this:

  1. Leave it as it is now.
  2. Remove the filtering of (in)visibility from the visualization and the report generation, and then also the specification of those filters from the reports. For the public version, the behavior you desired would be the result. For the production version of Damast, this would mean that evidences, places and place types you set as hidden would now show up again. But I think this visibility is a functionality that is not really needed anymore anyways, or could in any case be solved by (automatically) assigning tags to the respective evidences, or their complement set. Keep in mind that this solution is a bit of implementation and testing effort, I would say 2 to 3 days.

Removing the text from the report, but not changing the behavior, is not an option for me.

2.) Evidence a) I would rather have the evidences sorted by a) city name, b) religion name, c) start of the time span

Sure. Start of the first time span (if the evidence has more than one)?

b) In the English lexicography there is not plural form of Evidence. An English speaker would rather use the term “Pieces of Evidence”. I think we have to change that.

As far as I can tell, this is no longer part of the issue, right?

c) The evidence fragment of the report distinguishes between hidden and visible data. Is there a case when hidden data is shown in the report? To my knowledge hidden data is not part of the publicly available filtering system? In any case: No hidden evidences, places or region should be part of the DhiMu-data, so it does not need to be included in the report.

You mean here, right? See my answer above for 1.), and forthcoming discussion.

d) I would like to move the footnote with the evidence comment to the end of the sentence.

okay

e) We should use “…religious group…” instead of Religion

okay

f) If I understand the source code correctly, a place with the category “unknown” is displayed as “place”. Maybe it would be better to add an “undefined” to it: “undefined place”. What do you think?

I think that sounds like the result of bad programming (a programming error or bad data sanitation) ;) meaning that it looks like there was no value in the place type field, and JavaScript turned that undefined into text. But my fragile ego aside (:wink:) if that is how you would like unknown places verbalized, then no problem, I can do that. I think in the current version, I just wanted to show a neutral text here, as in "we do not know more".

g) I would rather have a colon between the short title of the source and the content of the source_instance.source_page cell.

okay

h) I would like to move the source comment into a footnote at the end of the sentence.

okay

3.) Places a) According the place type "unknown", I suggest to add "undefined" to "place" as above.

I personally think "undefined place" sounds weird. But as above, okay, if you want to have it that way.

b) I would like to have the list items in the „Linked to“ section in the following way:

is linked to: Digital Atlas of the Roman Empire (DARE): http://imperium.ahlfeldt.se/places/22329 i.e. without the short title and the ID at the beginning.

okay

tutebatti commented 2 years ago

I see two options how to resolve this:

1. Leave it as it is now.

2. Remove the filtering of (in)visibility from the visualization and the report generation, and then also the specification of those filters from the reports. For the public version, the behavior you desired would be the result. For the production version of Damast, this would mean that evidences, places and place types you set as hidden would now show up again. But I think this visibility is a functionality that is not really needed anymore anyways, or could in any case be solved by (automatically) assigning tags to the respective evidences, or their complement set. Keep in mind that this solution is a bit of implementation and testing effort, I would say 2 to 3 days.

My suggestion is to move these points to the end of the list and maybe have a small disclaimer (so the "innocent" reader knows, "ok, this is IT stuff that is important for some, but not for me") instead of removing them.

Other than that, @rpbarczok, would you reply to the rest of the questions, where neccessary?

rpbarczok commented 2 years ago

I think that sounds like the result of bad programming (a programming error or bad data sanitation) ;) meaning that it looks like there was no value in the place type field, and JavaScript turned that undefined into text. But my fragile ego aside (😉) if that is how you would like unknown places verbalized, then no problem, I can do that. I think in the current version, I just wanted to show a neutral text here, as in "we do not know more".

Well, I am not happy with undefined either, and when it is also a term in programming, than we can just use another term. How about unspecified place?

rpbarczok commented 2 years ago

ad 1.) The idea of hiding information in the visualisation was indeed something we implemented before we had the tag function. It was about creating a certain dataset in the visualisation, so Dorothea could ask certain questions. At the moment I use it for evidences that are neither part of the DhiMu- nor of the eOC-project. The tag function is not really equivalent, therefore I still think it might be a useful implementation for our database (not the HU version but our internal version). In short: I do not want it to be removed.

Removing the text from the report, but not changing the behavior, is not an option for me.

Since it obviously is against common and decent behaviour in programming, I totally understand when you want it to stay part of the report. I also do not think that we should move these information to the end of the report, since it is very basic information. So in the end I would like that it stays at it is.

ad 2c) Perhaps, that is more a question than a suggestion and I think you already answered that: Hidden information is not a part of the visualisation and therefore also not part of the report. I was wondering why it still is mentioned in the code, but I suppose it is just a question of coping all possible cases, and therefore diligent programming.

rpbarczok commented 2 years ago

2a) yes, start of the first time span. 2b) yes, it stays as it is.

tutebatti commented 2 years ago

So in the end I would like that it stays at it is.

Again, I do not suggest a major change. However, looking at an example:

The evidence must be visible.
The place must be visible.
The place type must be visible.
The evidence must reference one of the following religions: Latin Church, Rabbanites, or Shia.
The interpretation confidence of the evidence must be either certain or probable.
The place attribution confidence of the evidence to its connected place must be either certain or probable.
The religion confidence of the evidence must be either certain or probable.
The time confidence of at least one of the evidence's time instances must be either certain or probable.
The source confidence of at least one source the evidence was based upon must be either certain or probable.
The evidence must have the tag DhiMu.

Why not have it like something allong the lines:

The evidence must reference one of the following religions: Latin Church, Rabbanites, or Shia.
The interpretation confidence of the evidence must be either certain or probable.
The place attribution confidence of the evidence to its connected place must be either certain or probable.
The religion confidence of the evidence must be either certain or probable.
The time confidence of at least one of the evidence's time instances must be either certain or probable.
The source confidence of at least one source the evidence was based upon must be either certain or probable.
The evidence must have the tag DhiMu.

These filters are applied but cannot be set by the user:

The evidence must be visible.
The place must be visible.
The place type must be visible.
mfranke93 commented 2 years ago

Just for me to keep track, because I am not able to finish this today: