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
...