[Annotator] Dates' names are not displayed in the list of dates while adding entity already existing in the list

[virdiignis]

As in title. Works for other entities' types.

[virdiignis]

Still doesn't work for me, locally nor on test server. Also dates' names are not shown in the attributes list in the pop-up. P.S. Time entity has wrong input on when attribute, it should take hours and minutes, not YYYY-MM-DD — I guess there is no need to open separate issue for that.

[Janchorizo]

Date names are correctly being showed for me both in the list and the popup. Including in the test server.

[bug-rancher]

Names for date entities are not displayed, because they aren't sent in websocket response. I missed that case.

All information about unlistable entities (<date> and <time>) are inside of the tags of this entities. We don't use any other structure inside of the document to keep additional information about this entities. I didn't found any appropriate attribute in TEI P5 documentation to keep this entities names inside the tags, so I think only option for keeping name for this entities is between tags (e.g. <date xml:id="date-1" when="2020-09-03">the Third of September, 2020</date>). So, i think name property for unlistable tags should be filled automatically based on selected text, and there shouldn't be a possibility to change this property.

So, we have two options:

1. During creating date or time entity, in interface form "name" field should be filled automatically with selected text and blocked from edition. In request backend will get "name" parameter as any other parameter and handle this as usual. I think this is a better option, because user will see all entity details before he creates entity, and it's transparent for backend
2. During creating date or time entity, there shouldn't be "name" field in interface form, and backend will figure out what insert to this property. In my opinion it is worse option, because user will not see all properties of entity he creating. Moreover, on backend side I will have to add additional text fragment extraction from xml specially for this case instead simply operation on database.

What is yours opinion?

Apart of that, I need to block possibility of editing and removing name property for this entities, and Alejandro should extract names for this entities from text inside the tags (similar to extracting when attributes directly from the tags).

[virdiignis]

I think that makes date entity nearly unuseful. E.g. the text could say "the day after" — there is no way to recognize dates based on that information in the list of existent entities. Maybe let's move dates to the list, and create references like for other entities?

Also, it's really weird, because both yesterday and today Alejandro did receive dates' names from the test server — I'm very curious how this happened if the server code doesn't implement that.

[bug-rancher]

I think that makes date entity nearly unuseful. E.g. the text could say "the day after" — there is no way to recognize dates based on that information in the list of existent entities.

Same as you can't figure out the person's "birth" property basing on person's "name" property. If you want to get value of specified property, you should check value of that property you want, not value of another property :) The text "the day after" from yours example will be a "name" property of entity, and this entity should have filled by user "when" property with correct date too. And then you can recognize dates basing on "when" property, not on "name" property.

Maybe let's move dates to the list, and create references like for other entities?

<date> and <time> are "unlistable" entities in our platform only for one reason - they can not be listed :D TEI P5 specification not allow to do this. If you want to add references to this entities you can do this in the same way as for other entities. We just keep information about this entities inside the text instead in the lists.

Also, it's really weird, because both yesterday and today Alejandro did receive dates' names from the test server — I'm very curious how this happened if the server code doesn't implement that.

I don't know how this happened. Backend don't send this information :)

[virdiignis]

Same as you can't figure out the person's "birth" property basing on person's "name" property. If you want to get value of specified property, you should check value of that property you want, not value of another property :) The text "the day after" from yours example will be a "name" property of entity, and this entity should have filled by user "when" property with correct date too. And then you can recognize dates basing on "when" property, not on "name" property.

This is not particularly helpful. During person addition I see both they name and birthdate, I can decide basing on the context. For date, the text could be "the day after", the when could be "05.09.1946", but the name could be "Freddie Mercury's birthdate". I don't remember this date by heart, but naming it would allow me to introduce context and analyse data in this context. What's the point of annotating dates only with the date itself? @michalkozak maybe there is some solution to this in TEI that we don't see?

[bug-rancher]

I think a date is just a point in the time, so it doesn't need custom name. If you want to described something that happen in some date, I think more appropriate will be use of event entity, and there you can use "name" property for this event, and "when" property, which you proposed yesterday :)

So, If you will have fragment "Plane crashed in the day after Freddie Mercury's birthdate.", I think you can create reference to event entity from fragment "Plane crashed". This entity will have property name with custom phrase "plane crash" and when property with "1946-09-25" value.

[virdiignis]

I think a date is just a point in the time, so it doesn't need custom name.

I disagree. Take this text for example:

On 1st September 1939 World War II began with Nazi Germany invading Poland. The day after, the German forces were already in Wieluń.

The day after represents the date 2nd of September 1939. However, its naming is not descriptive — in context of war it gives one clear idea, but in biography of some American it wound have entirely different meaning. Nevertheless, those two contexts could mix in some project on WWII history. On the other hand, German forces presence at some point is hardly an event, as the presence can extend in time, so there is no exact moment when the "event" occurred.

If it's not feasible to somehow name or comment the dates, then I think we shouldn't list them or allow unifying, but just treat those as simple points in time that describe timespan of history described in given document; and use this info just as the context for other entities' unification.

[virdiignis]

Maybe let's move dates to the list, and create references like for other entities?

<date> and <time> are "unlistable" entities in our platform only for one reason - they can not be listed :D TEI P5 specification not allow to do this. If you want to add references to this entities you can do this in the same way as for other entities. We just keep information about this entities inside the text instead in the lists.

How about this: We could keep The day after in the text, and if user wants to name it, let's have a list of German army presence at Wieluń names in the header?

@michalkozak what do you think? You know the TEI best among us.

[michalkozak]

In my opinion we don't need entity names for dates and times. The dates marked in TEI files will be useful for filtering data in the visual disambiguator.

[Janchorizo]

This is fixed through PR #156, that removes the ability to refer ot other date and time entities, and removes the name property from said entities.