C2C Requirements Prioritization

	A	B	C	D	E
1	Priority (Must/Should/Could)			C2C Requirements Prioritization
2	#	Label	#	C2C Requirements Prioritization

3	1	Must	1.0	Easy-to-use responsive interface, simple and flexible. Make it easy to include annotations: 2-3 clicks process, have a dropdown list of controlled vocabularies, allow tagging with an URL.
4	1	Must	2.0	Keep a simple tool integratable (with a click of a button) with Zotero, Hypothes.is and other tools.
5	1	Must	3.1	Annotations must be visible for non-users
6	1	Must	6.0	Ability to highlight a target (text or image) by color-coding it, drawing a box around it.
7	1	Must	10.1	There will be at least 3 levels of sharing annotations: privately, with a group (members must be identified), and publicly (everyone). (See table below) There may be a need for more levels (for example: “only shared to registered users”). In order to promote sharing open annotations, they should be public by default, but the system will allow the user to configure its account settings to make all new annotations private, public or shared with a group by default. There should also be an option to indicate that you may want the system to ask you each time you annotate whether annotations are shared publicly, privately or with a given group.
8	1	Must	11.0	Modification of annotation target & body must be allowed
9	1	Must	12.0	Keep a log of activities of the system.
10	1	Must	13.0	When creating annotations, the target could be a text chunk, an image or another annotation. Allow adding a tag in a specific place (region) within an image.
11	1	Must	15.0	All annotations are visible by default but can be filtered (e.g. by author, date, category, tags/terms, etc)
12	1	Must	16.0	Annotations must be stored centrally but could also be cached locally.
13	1	Must	19.0	The system must be multi-platform.
14	1	Must	20.0	The system must allow to associate a licence with the annotation for any non-private use.
15	1	Must	21.0	Content creators must alway be logged into the system, never anonymous
16	1	Must	22.0	Only creators can modify (not delete) their own annotations, with the exception of administrators who can modify anyone else’s annotations. If we allow edition, then we will need to link annotations to the different versions of the target (e.g. Google docs “resolve” functionality hides the old comment but its still there, not deleted).
17	1	Must	25.0	The system must be able to handle controlled vocabularies/checklists (thesauri; taxonomies like IPNI for all plant names, The Plant List, WORMS, Catalog of Life, and ITIS; gazetteers, etc.) and allow the creation of list of values, lists of people (authors like IPNI for all plant author names like VIAF, collectors, illustrators, VIAF, etc.), traits like morphological terms (Stearn's "Botanical Latin") and Marine Species Traits, habitats from marineregions.org, WWF Ecoregions and habitat ontologies; "Taxonomic Literature" (Stafleu and Cowan) for author names and journal title abbreviations, ontologies (OBO Foundry, Plant Phenology Ontology, FLOPO, PO, Gene Ontology) and systems like Atlas Living Australia, EOL, Index Herbariorum and IPNI. This must be achieved by “registering” the controlled vocabulary (downloading locally or self building vocabularies) and make it available through the system. This must then allow an user to choose values from those lists, browsing or searching their labels (for example: habitats like mangrove, tropical montane rainforest, paramo), equivalent names (synonymy) and taking into account their hierarchy relations through time (species taxonomy, localities, etc.).
18	1	Must	26.0	The system must allow the user to define topics (for example: using a hashtag sign #), create a reference to an entity, associate terms to an annotation, etc. This could be done using annotations of annotations (like GoogleDocs uses the comment “Resolved” and dissappears the whole conversation if the last comment is of type “Resolved” but reappears it (and “unresolves” it) if a new annotation is added to the thread afterwards). Linking by adding URLs, replying or highlighting are different ways in the interface to input a certain type of annotation.	not really, but you can flag it
19	1	Must	27.0	Implement search functionality by keyword or type (comments/descriptions/customized tags/categories). Any references to entities within an annotation should be indexed and made searchable (for example: hashtag or @)
20	1	Must	33.0	The system must allow an user to filter the annotations by showing only those that came out in the current search result. (see # 15)
21	1	Must	37.0	Different types of annotations should be allowed. For example: specimen reference, taxonomic name, habitat types, corrected text, geographic locations, authors (artist, collector,dates, determined by), notes, reviews, links (URL, URI, DOI, barcode), customized categorization, personalized vocabularies or (hash)tags (“#Interesting”, “#evolution”, “#new_method”, “#lacksDocumentation”, “#lacksanalysis”), bibliography (citation), ratings are just some of the different types that the system could support.
22	1	Must	50.0	The system must be IIIF-compliant, being able to support images held in IIIF- compliant repositories (ie. the repository used (RERUM, Botanicus) should be IIIF-compliant)
23	2	Should	3.2	Filter annotations by: author, date, category, tags/terms and show only those. (see#15)
24	2	Should	4.0	Export different formats (text, image or Rich Text) compatible with existing products (Wikipedia, Flickr, Disqus, Wordpress, Pinterest, Zotero, Google Refine, Trove, Digital New Zealand, Smithsonian Transcription Center, Notes from Nature, VertNet, EOL, iNaturalist, AnnoSys, Tropicos, ADAM)
25	2	Should	5.0	System includes context of images (i.e the area surrounding the region chosen) when showing the result annotations of a search within a digital library (See 34.0 for the case within the repository below)
26	2	Should	7.0	Annotations should include also images and entity references in the text of the body, so the use of a Rich Text field is preferred when capturing the body of the annotation.
27	2	Should	9.0	Ability to print target with annotations (layout TBD, but should include PDF (text) and comments).
28	2	Should	11.1	Versions should be supported if the annotation target & body can be modified
29	2	Should	17.0	Annotations should be discoverable outside of the place where they were added (i.e. separate from the website or target)
30	2	Should	18.0	The system should support assessment of and reply to annotations and notifying of any changes in related annotations
31	2	Should	23.0	Annotations should be flagged (e.g. as inappropriate or irrelevant) or for admin review. (e.g.Three-strikes-out: if three users report an annotation as in violation of the terms of use, it will be hidden).
32	2	Should	24.0	Any autocomplete functionality should be modifiable through the use account configuration, including writing URLs.
33	2	Should	28.0	The system should allow for validation of a target if it changes (e.g. if the page or sentence on page changes, as in replaced or deleted, we need to account for that and build in functionality to address that
34	2	Should	30.0	Allow annotations as frequently as required, creating efficiencies during the data input. (e.g. maintaining default values for each field configurable through the account setting).
35	2	Should	34.0	The system should allow searching annotations across the repository displaying the body and the target. The context of the target (i.e surrounding words of text chosen) should also be shown for contextualization.
36	2	Should	35.0	Filtering annotations on a digital library level or a book search result level should allow to write a text contained in the annotation or an entity referred to in the annotation like Author, categories and range of dates. For the awareness part, when showing the dropdown list of categories, the values would be followed by the number of annotations in that category in the Digital Library or the book search result; alternatively a balloon or status bar could indicate this when hover over or the field gets the focus when the user lands on it. Authors, for example, could be chosen from a list of referred authors in the annotations on this Digital Library or the current book search result. For dates, by default, the creation and modification dates could be filled with the earliest date and the latest date of the annotations in the Digital Library or this current book search result.
37	2	Should	36.0	Filtering annotations on a book viewer level would show the categories used in the current book followed by the number of annotations of that category used in the current page and the number of annotations in that category used in the current book; alternative a balloon or status bar could indicate this when hover over or the field gets the focus when the user lands on it. The same with authors of annotations, they could be chosen from a list of authors of annotations in the current book followed by the number of annotations of this author in the current page and then the number of annotations by this author in the current book. For dates, by default, the creation and modification dates could be filled initially with the earliest date and the latest date of the annotations in the current page.
38	2	Should	51.0	The IIIF manifest should be made available and the annotations should be exported in a PDF, as a JPEG 2000 (Images) or as simple text
39	3	Could	3.0	Tool is integratable (with a click of a button) with Zotero, Hypothes.is and other tools. (See #2. - Must)
40	3	Could	8.0	Annotations could be able to expand to more than one page if needed
41	3	Could	10.0	The tool could also allow an user to read the annotations back from a PDF.
42	3	Could	14.0	An user could be able to see the versions of their annotations and they could be able to update. (When updating, the ID of the annotation will be kept the same but the last modification date will be updated and a new annotation related to the existing one would be created for the previous version (with the former body and date). This way, using the same ID, but having a different timestamp, the system can differentiate when any annotation that referred to this one may be outdated and require that the user be notified to ratify its validity with the new version of the annotation body).
43	3	Could	29.0	We need the functionality to allow for overlapping text and overlapping regions (e.g. 2 different users highlight the same text or image but with slightly different boundaries)
44	3	Could	31.0	The system could contribute to make the user aware of other existing annotations that might be related. For example, by highlighting the number of annotations of the same category that the user is choosing for his annotation, allow to search free text or vocabulary terms, traverse annotations with context in a separate search results page and create a reference to existing annotations in the system (in the page/book/Digital Library/Repository) or follow Kindle’s example of marking for the Reader the parts of a book that are more highlighted by the Community. See #34.0 and #5.0
45	3	Could	32.0	While typing, the system could suggest the characters to type ahead by looking similar values in an annotations referenced from existing indexed terms. Autofill functionality (suggests words based on what you typed before) could use indexed terms stored in the DB or the browser support this and cache the values to service the look ahead function.
46	3	Could	38.0	Users could be able to duplicate an annotation or copy the body an annotation and paste it with a different target within the system or outside the system in other application (for example, like a citation in Zotero, or a comment in Google Docs, or a conversation in text or a table with targets (and context).
47	3	Could	39.0	Setup a website to support the system. Allow for talk page.
48	3	Could	40.0	Wiki’mize more by allowing users to add annotations while recording the history of changes (versioning) and relying on the power users (like groups’ admins) to help out monitoring that and making the necessary corrections/vetting of the content.
49	3	Could	42.0	When connection to the global repository is lost, the annotation could persist in local storage while the user is offline and global repositories could be synchronized (automatically if possible) with local storage as soon as connectivity is restored, managing conflict.
50	3	Could	45.0	The system could allow collaborate editing of annotation vocabulary ( a qualified user should be able to create new entries in a vocabulary if they do not exist)
51	3	Could	46.0	The tool could have tutorials for users (ideally a video)
52	3	Could	47.0	The system could have geotagging
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100