WebAnnotationClient

The root feature that groups the rest of the features to define a Web Annotation client in the form of Web Browser extension

[Language: EN]

This abstract feature groups annotation servers which store annotations locally (e.g: browser storage or cookies).

Web annotations are stored locally in browser extensions storage. See chrome.storage.local: https://developer.chrome.com/apps/storage

This feature groups annotation servers hosted and accessible by URL and API on the web (e.g.: Hypothes.is).

[Language: EN]

This is a pre-alpha feature, it is not reliable and your data can be lost. Neo4J for annotations is a experimental annotation server that implement Hypothes.is API (https://h.readthedocs.io/en/latest/api/) but using Neo4J as the underlying database.

This feature groups features related with resource to be annotatated. Following the W3C recommendation it is possible to annotate resources taking into account like format (PDF, HTML,...) and location (web, localfile,...),...

This feature gathers the possible file formats that the web annotation client will support to create annotations over. It is possible to select 1 or more.

If selected, web annotation client will support text annotation in PDF documents.

If selected, web annotation client will support text annotation in HTML documents.

This is a pre-alpha feature, can work unexpectedly. If selected, web annotation client will support text annotation in plain-text documents (.txt, .xml, .java,...)

The source feature groups the identifiers that can be used to identify an annotated resource, Internationalized Resource Identifiers (IRIs).

You should select this feature if you want to annotate documents hosted on the Web with a URL

You should select this feature if web annotation client must support user's local filesystem files annotation.

If your annotation client needs to annotate documents that can be identified by Document Object Identifiers (e.g.: research papers), you can select this feature to sync annotations done over the same DOI but in different instances of the document (e.g.: a paper downloaded form ScienceDirect in PDF format and the same paper in HTML format hosted on the Web)

This feature enables text fragments annotations over a document, where the user selects a fragment.

This feature gathers the possible purposes that the web annotation can create annotations with. This follows the annotation purposes and motivations described in the W3C recommendation: https://www.w3.org/TR/annotation-model/#motivation-and-purpose

Selecting this feature allow users to create annotations with the purpose of classifying. This feature is related with the codebook.

Selecting this feature allow users to create annotations with the purpose of commenting. When user right-click over an annotation can click on "comment" button and a form is shown to create a comment. Some practices demand for comments to be assisted to either speed up the commenting process or enhance comments quality, this leads to a further elaboration of this functionality with commenting sub-features.

This feature verifies the content of user's comment when creating the annotation and notifies if the comment has a negative or offensive connotation. It is adequate to avoid offensive content when annotation comments are read by third parties or are used as a mechanism for feedback.

This feature provides an in-context literature lookup, simplifying literature suggestion or linking comments with scholarly literature. Currently it supports lookup in DBLP: https://dblp.uni-trier.de/

Provides functionality for comment reuse. It is useful in contexts where the same comment is repeated or reused in multiple annotations.

When the user starts writing, the system automatically hints with previously created comments. Comments that can be reused are those which has the same classification if classifying feature is selected, otherwise all the comments done are shown.

This feature is closely related to Moodle ones. It shows previously assessed assignments to students, where the user can place add a reference in the comment to student's previous assignments.

When assessing a category must be placed. Those categories are static and always the same for all the annotations. You can define your own categories in input/app/scripts/Config.js file in assessmentCategories attribute

This is a mandatory feature that allows users to create annotations.

This feature groups all the read operations that can be done for annotations.

This feature groups how annotations are read in context or when the user is placed over the target document.

This feature groups possible filtering options for annotations, which let them to hide/unhide annotations on the context.

Filtering is done by users. In the sidebar is shown the list of users that have created annotations in the current document, selecting or deselecting them annotations that are done by that creator are shown/hidden.

This feature groups features that let the user navigate throught annotations done on a document.

This feature creates a button in the sidebar that lets the user to go to the most recently created annotation in the document. This can be useful when a long document is annotated and the annotation activity is stopped and resumed later.

This feature requires classification and consecuently a codebook that is presented in a sidebar. This allows users to use the codebook elements to navigate through the annotations. If clicked on a code, the client will move to an annotation in the document. If clicks again the client will scroll to the next one with the same code.

Take into account that this currently disables the possibility to create page notes.

A canvas visualization is a general visualization of the annotation activity. It creates a button in the sidebar. When clicked, a popup is shown with all the annotations done in the current document in a tabular distribution.

This is a mandatory feature that allows annotation visualization highlighted over the annotated target.

This feature groups mechanisms for visualization of web annotations in a third-party service on the web. Here, it provides no rendering but resort to API-calls to export annotations to third-parties. This requires the existance of a mapping from W3C JSON-LD format (WACline export format) to some API parameter structure.

Creates a spreadsheet out of the annotations done with a codebook:

Non-developed feature. It is a specialization of a spreadsheet visualization where it is shown in the spreadsheet if multiple annotators agree or disagree in classification activity.

Non-developed feature. This feature creates a mind map in Mindmeister using its API, where annotations, grouping in nodes by the codebook that the user has defined or taken from the one configured from Mindmeister.

This feature groups visualizations from annotations that can be done in Moodle.

Web annotation client reports to moodle automatically maps annotation activity to moodle evaluation rubrics. Requires that the codebook was defined using Moodle rubric feature.

Moodle grades and comments are propagated to grade panel:

If feedback comment is activated in moodle, a report with links to evidences is created ready to by consumed by the student:

Web annotation client reports automatically to moodle discussion between the teacher and the student to Moodle comments section in the students assignment.

This feature groups how annotations are read out of context but are not part of a third-party service on the web.

This feature shows a button in the sidebar. If user clicks on it, a new browser tab will be opened and it will show annotations done in form of a list. In this view it is possible to search by user, tag and so on. If browserStorage annotation server is selected, this feature is a pre-alpha feature so may not work as expected in annotation searching.

Annotation list with selected annotation server Hypothes.is:

Annotation list with selected annotation server "BrowserStorage":

This is a mandatory feature that lets users to right-click on an annotation and delete it. It is possible to delete annotations only if the user is the creator of the annotation.

[Language: EN]

If selected, a button is shown in the sidebar toolbar. When clicking on it, web annotation clients deletes all the annotations done within the current document by the user.

This feature allows users to modify a created annotation. Take into account that currently it is possible to modify a comment, a reply or assessment, but not the classification of an annotation. See issue #29.

This feature groups features related with exporting and importing annotations.

If this feature is selected, a button is created in the sidebar, which allow users to import annotations in a .json file created previously with Export->JSON feature. The only supported importing format is JSON-LD following the W3C annotation data model recommendations. Depending on the features selected, some of the annotations' attributes are not imported (e.g.: if you import annotations with comments, but the web annotation client does not have commenting feature selected, it won't import the comment in the annotation).

This feature groups features that are able to export annotations to a file format.

This feature groups features that are able to export the annotated target with its annotations (inyecting in the document if possible).

This feature creates a button in the sidebar to export the annotated resource in PDF format with the annotations highlighting the annotated content. Due to lack of a library to augment/extend/annotate PDF documents in javascript/node the exported document is a PDF document with screenshots of the PDF document with the highlighted annotations.

This feature creates the functionality to export annotations in json format. A button is created in the sidebar toolbar to let users export annotations to a json file. It can be later be imported again using Import feature.

Creates a text summary of the annotations done in the current document. Creates a button in the sidebar to let the user create a report of annotation activity, including: each annotation with its comment, annotated text fragment,...

This feature groups codebook related features. The codebook captures the practices of conducting classification annotation, collecting a controlled vocabulary or taxonomy used to classify annotations. This feature requires Classifying purpose.

Each codebook has its own annotation group, so creating or deleting annotation codebooks implies creation and deletion of groups respectively.

The feature groups the operations that can be done over a codebook, create, read, update and delete.

This feature permits users to modify the codebook (controlled vocabulary to classify) that they are annotating with. That means that this feature allows creation of new concepts, modification of name and its description and deletion in runtime.

Need to mention that modifications and deletions must be done by the creator of the concept in a collaborative setting (e.g.: annotation server Hypothes.is)

A codebook has a name that it is set when the codebook is created. This feature allows renaming of the codebook.

This feature provides the functionality to delete a codebook. Currently, it is only possible to delete a codebook if manual selection of codebooks is set. If the annotation server provides mechanisms to delete annotation groups it is possible to delete them manually too.

This feature groups how codebook is selected when a document is opened to be annotated.

Usually annotation systems provide a mechanism for the user to choose with which one is going to classify in the annotation activity. In the sidebar it is shown a dropdown list with all the codebooks available to annotate.

A predefined and unique codebook is defined and always it is used the same. It can be modified if Operation->Update is selected, but it will be unique in the annotation client.

This feature takes into account the target opened and automatically selects the corresponding codebook to evaluate opened document. The file must be downloaded from Moodle's student assignment upload page and the system (if codebook is created using Create->Outsourced->Moodle) will automatically select and show the codebook to assess that document.

This feature groups different mechanisms to create codebooks. All of them are alternative, so only one can be selected.

 The annotation client creates a predefined codebook. This predefined codebook can be modified in file input/app/scripts/codebook/operations/create/builtIn/BuiltInCodebookScheme.js

This feature groups features to consume the codebook from a third-party service.

This feature allows creation of codebooks from spreadsheets hosted in Google Sheets. When the user browses a google sheet on the browser, clicking on the extension button will create a codebook based on the information provided in the spreadsheet. This specification must follow a particular structure (first row for Themes and second row using data validation the corresponding codes). You can see a sample spreadsheet here: https://docs.google.com/spreadsheets/d/1__DCJvzGya1_an8i-uhF8cOIrLnHr8NuXjkixZsiwWw/edit#gid=0. Further documentation of spreadsheet layout that the client can consume is defined here: https://github.com/haritzmedina/highlightAndGo/wiki/For-end-users#spreadsheet-layout

This feature consumes a rubric defined in Moodle and creates a codebook that allows users to annotate documents. See this video to learn how to create a rubric in Moodle and how codebook is created out of the rubric: https://youtu.be/4ZPBlIibqzw?t=19

This feature is not implemented yet. It will be able to consume nodes from mindmap in mindmeister and create a codebook to classify annotations based on ideas defined in the mindmap.

This feature groups the typology of the Codebook that can be created, e.g.: a taxonomy, a structured vocabulary,...

If selected, codebooks are able to group codes into themes, creating a hierarchized codebook to classify annotations.

Codebook if hierarchy is not selected:

Codebook with hierarchy selected:

If the feature is selected, it is possible to classify with more than one code pertaining to a theme in the codebook. For example, a codebook that classifies applications, an application have programming languages, and can be used jointly javascript and typescript. If this feature is selected, it is possible to annotate evidences with both languages.

If the feature is deselected, it is only possible to classify with one code for each theme in the codebook. For example, a student is evaluated with a criterion, and possible marks are 0, 5 or 10 points. The domain doesn't allow that the student for a criterion to have more than one mark. So if multivalued is deselected, all the annotations in a theme will have the same code, and if changed it is changed in all the annotations for that theme.

This feature groups how codebook is, captures the GUI variations for the codebook. Interface and order of elements of the codebook.

How are ordered the codebook elements. In some cases an alphabetical order is more appropriate, while in others a numerical order or order by creation date is preferable.

Orders themes and its codes alphabetically, facilitating code look up to annotate.

Codebook elements are ordered by date, where the most recent one is shown at the top and the oldest one at the bottom. It is useful when new terms are added and the annotation classification practice requires to use the newest ones more frequently.

Codebook is ordered in numerical order. In some cases it more convenient to order by number. E.g.: 2 is lower than 5 and than 10 and than 101, but if it is ordered alphabetically it will show 10, 101, 2, 5. This feature will order them correctly from lowest to highest: 2, 5, 10, 101.

This feature groups codebooks possible representations. Depending on the annotation practice it is more convenient to be placed in the sidebar (e.g.: to allow navigation among codes) as other tools indicate that it is better to show it over the highlight content as a popup (e.g.: to reduce interaction with the mouse). Currently it is only supported the presentation in a sidebar.

Shows the codebook in the sidebar as buttons in different colors.

This feature groups features related to codebook exporting and importing capabilities. This allows easy shareability and reuse of codebooks.

This feature if selected allows users to export created codebooks to a json file. This one can be shared and imported at any time. The export button is shown opening the codebook selection dropdown (in Manual selection mode) and opening the dropdown of the codebook that you want to export.

This feature allows importing of codebooks described in json format and defined by the same (or other) annotation tool created from WacLine. It creates a button that is shown when opening the dropdown of the codebook selection in Manual mode.