Skip to end of metadata
Go to start of metadata

20120619 Dominic Spec

Data Basket Spec - Old

201200625 Tom Notes

We had a discussion at BVA about the data basket document and wanted to make the following comments:

  1. Our understanding was that each of the records, fields, records within tools can be linked to (accessible through the actions menu). We therefore think that the data basket should only be a tool to organise these links, rather than a repository for actual data.
  2. A lot of functionality that you cover in your document is already provided by the links and by the tabs functionality.
  3. We think the data basket should not replicate a tool like Zotero. It would make it very difficult to build and very complex for the user. There are already a lot of tools available in the tools.

We therefore think the data basket should have the following elements:

  1. a history tab: which records all opened tools / records in the same way the tabs do with the difference that you can close tabs, but your history always stays intact.
  2. a favourites / saved items tab: here you can add anything you like, each included link could have notes and possibly tags
  3. annotations / comments: an overview of all the changes that you have made (listed hierarchically by records/ fields or by time only). we're not sure if this should be accessible from the basket or rather through the dashboards.

Regarding the user scenarios and objectives you described in your document, we think that a lot of them can be covered by copying and pasting links between tools and into the favourites in the basket. It would be good to discuss with ontotext if the pasted links could "pull" some of the data, so if you're pasting a link to an image, can it pull a thumbnail when it's displayed in the front end? Other functionality is already answered with the tabs and the history functionality of the basket.

20120626 Maria Notes

  • I agree with the proposed metadata for Data Basket item, though I think we should precise them. Now I am a little bit confused by the following and we have to discuss them in details:
    1. Data basket Creator - The person who created the data basket item whether explicitly or implicitly
    2. Sent by - The person that sent the data basket item
    3. Data Author - The person who created the data that was inserted (e.g. annotation)
  • About the “history of use” functionality in Data Basket – I think that this functionality is not relevant with the idea for Data Basket. In the user dashboard we will have dashlet with latest user activities, where the user will be able to start a tool with particular record. Also in the main menu Tools – there is information for the latest objects that has been annotated/ updated.
  • It is important today to discuss also the structure of Data Basket – how items will be organized in it?

Use Cases

During the brief analysis that I performed on your document I identified the following main use cases for Data Basket, which I would like we to agree on during today’s meeting:
1. Add image annotation link to Data basket
2. Add data annotation link to Data Basket
3. Add search to Data Basket
4. Add data object link/ thumbnail to Data Basket
5. Add data item link to Data Basket
6. Add forum link to Data Basket
7. Add painting link/ thumbnail to Data Basket
8. Add document link to Data Basket
9. Copy/paste text to/from Data Basket (use as clipboard)
10. Share Data basket item with other team members
11. Insert Data basket item into annotation/ discussion
12. Open link from Data Basket
13. Comment (Add notes) on Data Basket item
14. Add tags to Data Basket item
15. Search in Data Basket
16. Delete Data Basket item
17. Empty Data Basket
18. Export data from Data Basket

20120626 Discussion

Dominic, Maria, Tom, Vlado, Jana

20120724 Vlado notes

Data Basket UI design Notes

  1. "The yellow band shows what the rollover state for the item is": ok, a mouseover highights (I couldn't see it at first)
    1. Resolved
  2. "Each type of data has an icon": and the type is shown in a tooltip on mouseover.
    Please make a separate table type->icon for the devs
    1. The developers will take the icons from the html page
  3. "comment number at the top": please remove, this is not in spec.
    As answered in Data Basket Spec#Annotate - Should be able to annotate a databasket item from inside the data basket, there's a function to Copy bookmark links into a new Forum discussion (20.DBUC12), and that's all.
    1. This number cannot be at the top - to be removed
    2. Future: The number could be next to the Type icon, for specific items:
      1. object: number of Replies to all annotations about the object
      2. field: number of Replies to annotations about that object field
      3. data/image annotation: number of Replies to that annotation
      4. image: ?
      5. forum:?
    3. We're keeping "start discussion on bookmark". Maria will improve the spec to make it clear to devs what needs to be implemented and what not (there is decision not to be supported such functionality (see
  4. "How do you add an external link? ... action menu on top ... to create new data basket item (would cover external URLs)":
    Agree (see mechanics below) . "If you paste a Researchspace URL the system should recognise it and fill in the other fields automatically. No need for such magics since "add Web Link" is a separate action, and "add Whatever" is in the context menu of Whatever
    1. the action for Web Link is to open it in a new browser window.
    2. (for RS3.5) "add Web Link" should be exposed as a REST web link, so it can be made into a JS bookmark for the user to put in his browser. Add a very simple UI to "publish" the bookmarklet mechanism: demoed from Confluence
    3. To be updated the FS with new requirements in DBUC01: Add item to data basket - a new pop up screen will be opened, where the user will paste the web link, the title will be put automatically and user will be able to update it.
    4. To check if we can use web preview server for the web pages in the data basket?
  5. I'd merge the filter/sort/search buttons on the same line to save some space?
    1. resolved - they are on one line
  6. "Filtering / sorting as per previous mock ups". I'm not so sure filter for Annotations and filter for Bookmarks is the same thing. To be discussed below for Sort: I propose a simple drop-down: Title, Date, Creator, Note. For Search: I think it's the same as Filter (see below), so remove it.
    1. To reuse the functionality for sort/ filter from image annotations
    2. Merge search and filter buttons into one - Filter
  7. URL (shortened): there's no point showing URLs since they are not usable outside of RS.
    I suggest to remove it, and show Note instead.
    We only need URL for the Web Link: this could be put in the same cell as the Title.
    I suggest that the whole row be made an active link; and View be moved to an action menu item.
    1. Keep the URL column. - For RS (internal) items, display fixed text "ResearchSpace item". - For Text, display nothing. - For Web Link, display its shortened URL 
    2. Shorten the Web Link using some URL shortening service (need an extra data field!)
    3. Show the short URL in the column, and the full URL in a tooltip (it usually includes useful info, eg a blog link is usually readable)
    4. It's very important for RS to provide resolvable URIs, but it's a technically complex topic to be addressed in the future
  8. column Preview: not for web links (unless we integrate some Preview service)
    1. can we use a web page preview server to fill out the image for Web Link? I think Google has one??, and was another (but is it out of business?)
  9. "Tags panel can be sorted by popularity": Useful, but not in 3.5.
    This functionality should be present for Annotations as well. See Tags below
    1. Sort tags by popularity not for 3.5. TO be decided for which iteration?
  10. Tags panel showing number of uses: Useful, but not in 3.5.
    1. UI for tags: will be made similar to Confluence & Yammer
    2. Tags should use all existing thesauri, plus a specific Tags thesaurus, which is shared per-project.
    3. A new tag is always added to the Tags thesaurus.
    4. Per data basket item are visible only the tags which are assigned to this item, not all existing tags
  11. "we only have a single pop up (for detail or edit)": good idea; I'd suggest it should be the same popup:
    - Tags as clickable, but as discussed in Tags there's no "Press enter to add" (i.e. no new tag)
    - make Note editable
    - Title is not editable for most of the item types! See discussion below
    1. The item's title is used as a default value and copied to the bookmark title, but then the user can edit the bookmark title (an extra field in the data model!)
    2. When copying: cut the bookmark Title to 40 chars
  12. Detail view: shows data that is not present (Sent by, Data author, Data date) or doesn't need to be shown (URL). The fields (and suggested names & order) are:
    title, icon, type, added by, added on, tags, preview, notes
    1. Keep Data author and Data date, for Annotation, examine the item type, and fetch dcterms:creator and dcterms:created. TODO: Vlado to refer to OAC+DC diagram
    2. Remove sent by
  13. "Databasket as a pop up (eg for use when inserting item in to comment): Clicking on an itme selects it as the item to insert": yes!
  14. "The action menu for each item should have its own individual export... The export is covered by the action menu"
    Folks, there is no Export in 3.5! As discussed in London and email Fri 7/13/2012 3:06 PM (Maria also replied)
    1. No Export
  15. For text clip 
    1. Add Databasket action: "Add text", in addition to Rich Text Editor context menu (I think that we decided the button to be in DataBasket. Or it is in both places?)
    2. The rich text is stored in Notes
    3. A plain-text version of the rich text is stored in Title
  16. Actions## for all Bookmarks: Add Web Link, Add Text, Delete All, Filter, Sort, (not work yet: Export, Print)
    1. for single Bookmark: Delete, Edit,
    2. Click on row opens the bookmark View; click on URL opens the specific tool

Data Basket Spec - Old Notes

Maria, all the long titles seem to be half-resolved issues. You need to resolve them, or move them in a separate section clearly marked "For discussion"!

  1. eg Data Basket Spec#Search - The user should be able to search the data basket using meta data
    • "DBUC08: Filter items in data basket contains both keyword search and filtering by item type, tags.dates"
      What's the difference between Filter and Search?
    • "It is created based on the functionality already developed for search/ filter data and image annotations, as proposed from BVA."
      I'm not so sure filter for Annotations and filter for Bookmarks is the same thing. Maria?
  2. 20.DBUC11: Export data from Data Basket (RS?)
    Move it to separate section to mark clearly this is for future version
  3. Maria, please describe how these 3 specific items are added:
    • Data Field: from context menu.
      Lazily creates the Annotation Point (AP), creates its Title, uses its URI.
      Invokes Databasket Item dialog, so the user can edit Tags and Note
    • Web Link: from top menu of Databasket.
      Invokes Databasket Item dialog, so the user can edit URL, Tags and Note.
      This is the only time URL is displayed in this dialog.
      When the URL is changed, goes out to the web page to fetch the Title.
      Title is editable.
    • Text: from menu item "Add to basket" in the rich text editor.
      Causes the selected text to be copied to the Title of a new item, generating its URI.
      Does this mean we need Rich Text in the Title?
      Should we shorten this title on printout, since the text can be quite long?
  4. Should Title be editable?
    Current spec says no, and indeed for most item types it cannot be since it's shared.
    Depending on details of the Data Model, I'd say that Title could be editable only for Web Link, Text, Search.
    If we decide it should be editable, then we need a bigger space for it, since Text could be long.


Working with tags is not planned in 3.5. I agree that a Yammer-like functionality is best, but:

  • we need a better spec
  • working with tags should be the same across annotations and basket (bookmarks), even if they use different tag sets
  • we need to plan it.

Current Data Basket Spec - Old says:

  • "Tags are not related to project thesauri"
    which contradicts a note by Dominic: tags use all thesauri; while newly added tags are put in a dedicated thesaurus".

20120807 Dominic

  • Why annotations cannot have a property (no_of_replies) which can be incremented every time and therefore not need to be calculated on the fly
    • Every time you decide to cache a number, you have to worry how to keep it up to date. And we have several related numbers (per object, per field/AP, per annotation)
  • I am also not sure why researchspace urls cannot be accessed outside researchSpace subject to authentication.
    • We still don't have a strategy how to keep RS URLs stable, yet resolvable across different environments (dev, test, prod), states (original data vs newly proposed vs published) and branding requirements ( or (not) or, etc), see RS URLs and URIs

20120809 Notes on UI

Maria: We discussed the day before that “Sent by” will not be supported for databasket item

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.