an interface for user correction of auto taggin system

[afshinsadeghi]

fw side of the aran auto tagger plugin, adding an interface for user correction.

[afshinsadeghi]

First: we want forced tags. so that user can choose between available tags for sections. if the author has not selected any tag for a section the system do it automatically. (so the system works when it does not exist.)

so the interface can be like adding comments. but they are not shown. only when clicked upon someone can see. The automatic tags do not need to be shown in FW.

second: add tags to sentences. exactly like the comments. but when exported they are inserted in the body not in interface. this tag is also limited. the user only must choose from a list. we define this list in future.

[afshinsadeghi]

another prerequisite: exporting table exists but we are not tagging them. add tags to them.

[johanneswilm]

Hey, I would do it the other way round: first autonatic tags that can be seen. These can be applied when the user creates an auto-tagging button. They are visible so that tge user can make corrections to them - remove those that are incorrectly placed and add sone that are missing. When the ecport happens, all tags should be visible. If there are no tags at all in the document at the time of export, give a warning message before exporting.

[afshinsadeghi]

doco:table for tables doco:figure for diagrams.

[afshinsadeghi]

Hey, the problem is that we do not see the exported document in FW. It adds tags in the html exported file not in the document. So you mean we apply the system inside FW documents?

[johanneswilm]

Yes, I've seen the code. I think to be useful the tagging stage needs to be moved to the document editing stage. The tags there need to be stored in the document as marks. This applies to both manual and automatic tags. In the exporting stage the tags then only need to be translated to the corresponding html attributes. This will require changes to the document schema. To do this efficiently, and because it will be hard to undo, we should look at all the taghing things that are out there. What do we think about schema.org for example?

[johanneswilm]

The changes to the schema could be made in a very general way so that it could be used both for this and other plugins. For example, we could add a mark with the name "tag" and the attributes "type" and "data".

So for example, a mark representing a tag for a headline of the conclusion could have these values:

name: "tag", 
attrs: {
    tagName: "conclusion-header",
    data: {...} // some extra data in the form of an object
}

We also may want to distinguish between those tags that are applied to individual elements and those tags applied to arbitrary text. IN that case we should maybe add an attribute for that and turn the above into

name: "tag", 
attrs: {
    tagType: "block",
    tagName: "conclusion-header",
    data: {...} // some extra data in the form of an object
}

[afshinsadeghi]

@johanneswilm To make it in the document editing stage, how do you trigger exporting the HTML document?

[johanneswilm]

You basically have two independent parts:

1. The auto-tagging and manual tagging system. For this we need new buttons.

2. The export system. This is being triggered like hitherto. If a user triggers this export on a document with zero tags in it, instead of exporting we could show a dialog box "The Dokieli format requires tagging of content. This document does not contain any tags at all. Are you sure you want to export this document?"

[afshinsadeghi]

We have now manual annotation and automatic annotation. The manually annotated document can be annotation automatically in the export.

It can happen that we have the repetition of annotations of manual and automatic annotation. To avoid the collision in the automatic annotation we add a check, if it is already annotated it does not do it.

[afshinsadeghi]

we convert it to a plugin afterwards

[johanneswilm]

It is a plugin already. Automatic tagging on export will not work because that will also add incorrect tags with no way for the user to adjust them.

[s6fikass]

The idea is also to change the plugin where it doesn't tag any manually edited tags

[afshinsadeghi]

with the approach above at least we give the user the chance to set them first so the automatic annotator will not annotate then. @johanneswilm have you checked to what percent it was doing wrong? that is also of interest.

[johanneswilm]

Text taggers have been around for a while and they tend to always be working this way: first automatic tagging, then user tagging corrections. This is the only way I can think of to ensure both making life easier for the user AND giving tge user ultimate control over the tags. Other approaches have the aforementioned problems. You will not be able to get any percentages on it either, as noone will be using a tagger they cannot control. But there is still room for experimentation in user interface design: for example - what to do if the auto tagger is used after manual tagging? Or what happens if the user doesn't tag at all and then wants to export to a format that requires tags?

[afshinsadeghi]

I was trying to say this from the beginning. user manually sets tags, and for those that he has not the automated tagger work.

[johanneswilm]

Ok just to be sure we are saying the same thing: If you have the automatic tagger AFTER the manual, the automatic tagger will possibly set sone tags incorrectly and the user has no way to remove those tags. That will be very frustrating to the user. So the order needs to be: FIRST automatic tagging THEN manual adjustment of tags.

Is that also what you were trying to say?

[afshinsadeghi]

No, I had the other way round in mind.

1. The user sets the tags he prefers manually, then on export,
2. The automatic tagger tags those places that are not done by users. But Yes The user always can edit the tag of the exported document.(yes that is already possible in dokieli)
3. The user can check if in places the document is tagged with wrong tags edit them in the exported document via the interface of dokieli.

[johanneswilm]

Unless they have set up a special system, that basically means editing the source code by hand. Also, the collaborative features are gone.