View Source

{toc}

h1. Introduction

This spec is simple enough, so we put all parts (data model, spec and API) in this page.

h2. Overview
{excerpt}Tags (labels, topics) are a popular way to organize knowledge using social classification (tagging) processes and producing so-called folksonomies{excerpt}.

An overview of RS tags functionality follows. Please note that because of the limited effort to be spent in RS3.6, only [#RS3.6 Use Cases] will be implemented.

Any RS object can be tagged. Tags are shared between projects, or can be defined per-project (future). Tags come from existing business thesauri, and new ones can be added to a dedicated tags thesaurus. Tags are used for searching objects, and tag cloud (future)

- Source of Tags
-- Tags can be taken from existing business thesauri: you get synergy with existing terminology
-- New tags can be added easily by any user to a dedicated Tags thesaurus
-- Tags are shared between projects
-- Tags can be defined per-project (future)
- Applying Tags
-- Any user can easily add and remove tags from objects
-- The "Add Tag" function uses the same auto-complete functionality used for Search (but uses a slightly different set of thesauri: Taggable instead of Searchable).
-- If the user adds a tag that does not exist, it's added as a new tag into the Tags thesaurus
-- Tags apply to any RS object kind: Bookmark, Data Annotation, Image Annotation;
Museum Object, Forum/Topic/Post, Image (future)
-- Tags are shared between objects (i.e. the same tags thesauri apply to all object kinds)
- Using Tags
-- Tags are displayed with the object, thus adding to the object's information
-- Tags are used as additional search criteria in specific (per object kind) searches
-- A universal Tags search (across object kinds) may also be useful (future)
-- Tag cloud visualizations display popular tags and counts (future)
- Administering Tags (future)
-- Tags approval
-- Tags rename, merge, replace

h2. Effort

The initial version of Tags has modest effort allocation (from [RS Plan 3.6]):
- Tags spec: 1.5 p/d
- Tags backend: 3
- Tags frontend: 4

Jira tasks:
- {jira:RS-541}Discussion
- {jira:RS-1175}Overall
- {jira:RS-1176}Spec

h1. Tags Data Model

h2. Source of Tags

Tags in RS come from two places:
- General thesauri.
Any thesaurus with rso:isTag=1 (marked as "t" in [Meta-Thesaurus and FR Names#Meta-thesaurus table|Meta-Thesaurus and FR Names#Meta-thesaurus table]) can be used as a source of tags
- Dedicated thesaurus.
A special RS Tags thesaurus ([http://www.researchspace.org/thesaurus/tag]). New tags are added here

h2. Applying Tags to Entities

Tags can be applied to the following RS entities (compare with [Data Basket Model#Item Types]):
- Bookmark
- Data Annotation
- Image Annotation

In the future tags can be applied also to:
- Object: need mockup where to put the tags, spec how to integrate with FR search, mockup where to put in search sentence and search results
- Forum/Topic/Post: 3rd party system, new in RS3.6
- Image: no UI to show a single image yet

h2. Tags Ontology

We use the [Tags Ontology|http://www.holygoat.co.uk/projects/tags/] ([tags.n3|http://www.holygoat.co.uk/owl/redwood/0.1/tags/tags.n3]), which defines:
- class tags:Tag as a subclass of skos:Concept. (This is perfect: when a skos:Concept is applied as a tag, it becomes tags:Tag.)
- two inverse properties (tags:taggedWithTag and tags:isTagOf) to relate any resource to a tag

The Tags ontology is depicted here:
!tags.png!
- We don't use tags:Tagging, i.e. don't record who/when added a tag
- There is no ordering of the tags applied to an object

Here is an example that relates ?obj to Rembrandt, and to a user-created tag named "Watercolor".
{noformat}
@prefix tags: <http://www.holygoat.co.uk/owl/redwood/0.1/tags/> .
@prefix rs-tag: <http://www.researchspace.org/thesaurus/tag/> .

rs-tag:1234 a tags:Tag, skos:Concept; skos:inScheme rs-tag:; skos:prefLabel "Watercolor".
rkd-artist:Rembrandt tags:isTagOf ?obj.
rs-tag:1234 tags:isTagOf ?obj.
{noformat}

Design notes:
- tags.n3 will be loaded on next repo reload
- we use tags:isTagOf instead of tags:taggedWithTag, though they are inferred from each other as inverses
- the type tags:Tag is used to generate the counter for the next tag (in the above case would be 1235)
-- it is inferred from any of tags:isTagOf, tags:taggedWithTag

h1. Tags Use Cases

Because of the limited effort in RS3.6, some viable cases are listed under [#Future Use Cases].

h2. RS3.6 Use Cases

h3. Tags in entity detailed view

- Every entity type should use the same Tags section
- Tags are represented as "buttons" for easier recognition
- There's a red "x" after each tag to delete it
- There's an empty box at the end of the tag list.
When the user starts typing, RS does autocompletion against all tag thesauri.
If the user doesn't select from the autocomplete box and presses Add, a new tag is added to the Tags thesaurus (so it's easy for any user to add new tags)

h3. Tags in entity list view

(eg Object search results list, Bookmarks list ...)
TODO: make mockups\!
- It's best to use the same Tags section as above
- Or do we want some "lighter-weight" version of it?
- In particular, do we want the user to be able to add/delete tags from here?

h3. Search by tag

- Clicking on a tag runs a search by that Tag, for that entity kind only
- In the Search dialog for every entity kind, there's a Tags section to add tags to the search
The query is a disjunction (OR between the tags) that is conjoined (AND) to the rest


h2. Future Use Cases

- Universal search (of any kind of object) by tag
- Apply/create tag using twitter notation in rich-text: #tag
- Tags maintenance of the dedicated thesaurus: an admin function
-- Approval of new tags proposed by users.
-- If a tag is rejected, all its instances are deleted
-- Rename tag
-- Merge two tags
- Per-project Tag sets
Each project should be able to define a set of tags that are relevant to the research they are doing (primary tags)
- Tag cloud, in one of the following forms:
!tag-cloud0.jpg! !tag-cloud1.jpg! !tag-cloud2.gif! !tag-cloud3.jpg|width=300!

h1. Tags UI

Use visual design as per [Data Basket UI design#View Bookmark]: gray rounded tags, extra autocomplete text-box

For reference, here is the Yammer UI:
!tags-edit.png!

h1. Tags API

- Saves tag to OWLIM: URI saveTag(String label, URI thesaurusURI, URI objURI);
if thesaurusURI is null then it saves by default rs-tag(class RSConstants.RST_TAG) specified above;
if objURI is null then it saves the tag only;
- Assign tag to an object: void assignTagToObj(URI tagURI, URI objURI);
- Gets tags for an object: Tag\[\] getTags(URI uriObj);
- Deletes any statements that has been created for the tag: void removeTag(URI tagUri);
- Delete only statements(IS_TAG_OF) that has been created for the tag and the object: void removeTagFromObj(URI tagUri, URI objUri);
- Autocomplete Search tags into existing thesauruses: public Tag\[\] searchThesaurusTags(String searchVal)

TODO Jana & Svetoslav

NOTES from meeting 20130108:
- When to save tags? Cannot be immediately, because if you're adding tags on a new object, it does not exist until Save. Must be on Save, therefore the Tags API better have assignTagsToObject not addTagToObject and removeTagFromObject
- when saving to the dedicated thesaurus, make URL from the name
eg prefLabel = "water color" \-> URL = rs-tags:water_color

h1. Tags autocomplete - updating Lucene index with new values (design)

- We need an autocomplete on isTag thesauri
- We don't update or delete tags, we only add new ones
- the dedicated rs-tags: thesaurus (where new tags are added) is not searchable.
Many other isTag thesauri are searchable (in fact isSearchable => isTag because all searchable thesauri are interesting for tagging)
- Need to see new entries almost immediately in GUI
- We can differentiate between the search and tags autocomplete calls But it's preferred that the same FTS index be used in both cases
- If possible, implement this with OWLIM 5.3's incremental FTS indexing