Use cases
Current page is intended to describe the purposes and use cases for which an annotation system might be useful. on less important: the conditions that may make the system non-viable are also discussed.
Recurring Purposes and Use Case Scenarios are differentiated, as some activities (such as gathering comprehensive information) might be recurrent in different situations (A Research group building a body of knowledge, or an eLearning application).
Recurring purposes
Annotating Resources
Some online resources such as blogs allow to include comments, but it would be interesting to be able to comment/annotate openly on any resource (books, movies, maps) with an open model which would allow any feature that could be developed. Though, most knowledgeable systems aiming for this (Google Sidewiki, Third Voice) have desisted.
Controversies
It is frequent to see "religion wars" in subjects like politics, programming, etc. Many times it is the n-th re-enactment of the same controversy (e.g. "Java is slow"). Some software (as Slashdot/Slashcode) exist where arguments can be replied and qualified, so at the same time people wanting to know all what is said about something has the chance to, and people with not so much interest can focus on the most relevant comments.
Knowledge compilation
Annotations might be useful for represent knowledge. Paper and speech impose a sequential structure. Hyperlinks enable to jump easily into related information. Turning the plain text into a more schematic shape, and introducing semantic information into links might suppose a substantial improvement.
Currently wikis are adequate for this purpose.
When browsing a resource, users might need to know more about some issue. The related content might be in third party resource (which develop in deepth a certain topic, which reference (incoming link) the first resource, or have some kind of correlation with the resource.
Usually this purpose might be accomplished using a search engine, but sometimes there is room for improvement.
Archiving relevant resources
Unfortunately, some resources might dissapear from their source, or might be altered so related work might be affected. One simple approach might be that everyone should have one copy of their essential third party stuff, but it might be better if some coordinated approach is available (e.g. to register the hash for the resources, so it can be retrieved from a P2P network if required).
Owners of copyrighted material (movies, music, etc) might set strict filters on their resources' annotations in order to keep freeloaders at bay (e.g. people annotating bittorrent links). These copyright enforcers, and sensible data owners might exert the right to remove unlawful copies of their materials.
Certain contents are quite heavy in size (high-res images, video, audio). If the users pays for it she can store absolutely anything she wants; otherwise, there might be limits to size, bitrate and media type.
Specific Use Cases
The obelus system should be best targeted to a technologica-enabled public, which might be most inclined to adopt and to contribute to novel technologies.
Research Groups
- Interwoven knowledge. Fine grained style. In a wiki you might usually find pages that are about 100-1000 words long, and quite a few things are mentioned and explained, but these individual concepts might be as well commented on their own. Maybe each individual concept should have its individual page, and use an enriched semantic linking.
- Schematic style: Simple text develop concepts one at a time in a sequencial mode. Maybe it would be good to make extensive use of a more schematic style, so the concepts dependency is more visual. Also, a concept might be discussed in greater deepth and more easily edited and expanded than in plain text.
- Subscription to updates. Researchers want to be notified about relevant additions and modifications on the topics of their interest.
- Fast peer review and feedback. As interested colleagues are promptly notified, they can judge on the novelty and merits of the "intelectual contribution".
- However these things can be done in a wiki. Don't they? We could even use templates to announce the presence of semantic-rich links/annotations (However these links would still be unidirectional, or we should edit both/all link ends to keep up to date.
- Concept provenance: concepts might be linked with the research papers where they are introduced/cited. This might make easier find the right bibliography to cite (who was first, who develops the concept best).
(Might be related with #Concept compilation and #eLearning)
Software Development Metadata
- Example: Figure a software development project (e.g. a receipt system), where several technologies (programming code, database definition and manipulation statements, reporting tools) are integrated. From the cash registers receipts are produced and paid. Each receipt line is registered in database and processed to assess the inventory resupply. Also the data is copied into a Data-warehouse so it can be used for CRM, trend analisis, etc.
- The whole system is composed by different parts that are developed separately and integrated. There is also technical documentation (analisis and design prior to development, technical reference etc).
- Though modern IDEs make extensive use of the available metadata about datatype and method definitions to aid programmers. The definitions in programming code and documentation tend to be repetitive (e.g. the definition/description of the "receipt line" might be repeated not only in different subsystems (e.g. programming code, database definitions, datawarehouse, reports, etc), but also in different parts of the same subsystem (e.g. description of a Java field for the instance field, the getter and setter, and any other method parameter where it might appear). Such repetition might introduce the risk of incoherence: Technical documentation might be obsolete and misleading, data fields might have inadequate verifications (e.g. require a national phone number format for an internal extension, or an international number), correlation and conversion between system might hide some errors (e.g. bad support for extended characters, or text length might be inadequate).
- (General proposal) A global definition of the system in an standarized and accesible source could be used to aid in the development of the functional parts of the system, and the associated documentation.
- (feature) Code generation: Basic data types and methods might be automaticaly generated. This should use customizable patterns and allow for the insertion of custom code (we don't want a system that generates a code that doesn't match our needs, and overwrites our modifications).
- (feature) Coherence check: Check that field definitions match, or are at least all suitable for the range of possible values (e.g. a text field smaller than max possible length)
- (feature) synchronized re-engineering: If a part has to change, the system leads us to all the parts that should be modified and tested.
- (feature) Centralized documentation: E.g. not to tell everything about each field (very long description with comprehensive list of checks to be done, sample values, etc). That can be too long and become incoherent if changes are made
- (requirement) external linking: Some source codes (e.g. a data file) won't be good to contain documentation and explicit anchors for links
- (requirement) versatile fragment locators: XPointer won't be good for Java or SQL DDL. Regular expressions, or tailor-made locators might do a better job
eLearning
For technicians required to keep their knowledge up to date in an specific area, it would be useful to have some bookmarking about the items they must read, and tests they might pass. Not only the body of knowledge compiled at a given time, but the novel concepts as they gain some relevance.
Learners can learn in the order they prefer, avoid redundant issues, mark or hide the entries they have already assimilated. They may as well review older relevant concepts on a timely manner.
Some eLearning products implement these features, but they might as well make use of annotations.
Employers and potential employees may as well use these compilations or relevant concepts and tests as means of certification of expertise.
Specific Type Annotation Systems
- bookmarking/categorization - Delicious
- Voting - Digg, StumbleUpon
- Commenting - Sidewiki that was, W3C Amaya/Annotea, ShiftSpace
Potential problems in system
(main discussion in Inviability Risks)
There have been several intents for similar systems, which have not gone really far. The real problems might be uncertain (maybe these pioners really know the real reasons, and if they know they wont tells. I feel these circumpstances might not be an aid at all:
- The problem itself is a little ethereal (difficult to explain, to develop, to gain users)
- The system might be too cumbersome for the usual scenarios (paper and pencil have much lower cognitive friction).
- The developed system might not be of much use without sufficient user base
- The developed system might end up being under a lot of abuse (spammers, activists, conceited smart alecks)
- The developed system might end up being under a lot of litigation (by people not liking being subject to annotation)
- Might have scalability problems if widespread
- Might be difficult to monetize
