compared with
Current by Vladimir Alexiev
on Feb 15, 2013 14:41.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (42)

View Page History
| *Entity* | *Description* | *Mapped to* |
| Basket | List of Bookmarks, owned by a particular user | ore:Aggregation |
| Bookmark | Pointer to an Item, made by particular user, with optional description | oac:Annotation rso:Bookmark |
| Target Item | RS URI or web URL or pure text, (in some cases) having Preview, short URL, creator | see [#Item Types] |

- Jana: why do we need a Basket?
-- Vlado1: To distinguish the bookmarks of one user from those of another
--* {color:#ff00ff}Jana: I rather imagined it denormalized with owning user being just a property of the bookmark. Having a basket is not a problem of course - just that we never actually deal with this object and we need some additional effort for maintaining it.{color}
- Jana: if Bookmark's type is oac:Annotation, how can we distinguish from other annotations, eg forum posts?
-- Vlado1: I think it can be distinguished by the fact that it's in a Basket. We never search for "all annotations", we search for annotations related to something (an Object, a Basket...)
If we need a specific type then I'll add one. In fact OA has such: oax:Bookmark (but they oscillate between using types and using a separate field called oa:hasMotivation)
-- Vlado2: A bookmark can be created by one user, then shared with another. The column "bookmark creator" suggests this: otherwise it'd always have the current user, so what's the need for it?
- We use rso:Bookmark's (a subclass of oac:Annotation) to easily distinguish bookmarks from other annotations, eg forum posts.
-- Bookmarks can also be distinguished by the fact they are in a Basket. We never search for "all annotations", we search for annotations related to something an Object, or in a Basket, etc
-- OA has such class (oax:Bookmark), but they still oscillate between using types and using a separate field called oa:hasMotivation
--* {color:#ff00ff}Jana: We need to double check this won't break the existing Annotation API. I suggest someone reads through all SPARQL queries related to annotations.{color}
-- Vlado2: can you describe more specifically what could break what? We'll now have 3 app-specific classes rso:Bookmark, rso:DataAnnotation, rso:ImageAnnotation (as described below), so there can be no confusion. (Please make a task for the latter two, and quote it here with \{jira} macro)

h2. Prefixes
| foaf | [] | | foaf.ttl |
| oac | [] | | oac.rdf |
| ore | [] | no need | |
| ore | [] | defined one inverse in rso.ttl | |
| rdf | [] | no need | |
| rso | [] | RS internal | rso.ttl |

- For now users are represented with a Nuxeo username, not with URI
- TODO Jana: Can the given URI patterns be implemented?
- A "sequence" service is added, that returns sequentially-numbered URIs of a given prefix (kind)

h2. Item Types

Target Items can have one of the following types. The type is stored in two places for convenience, and with different characteristics:
- Vlado1: It's important that we use the normal rdf:type property, since the type is attached to the item (target node) and not to the bookmark through a customproperty
- rso:hasTargetType
-- custom property, passed through the entityAPI, stored in the bookmark
-- stores exactly one of the types below
-- types are specific and different per target, which allows the Basket implementation to recognize the item type more easily
- oac:hasTarget/rdf:type
-- standard property, stored due to target's (not bookmark's) creation,
-- stores the target type and all of its supertypes
-- in one case is missing (Text Clip)
-- -in another case two targets share the same type (Data and Image Annotation)-
-- now they use the specific type, since that's needed by [Dashboard Design]

| *Type Name* | *rso:hasTargetType* | *oac:hasTarget/rdf:type* | *Icon* | *Comments* |
| Data Annotation | rso:DataAnnotation | rso:DataAnnotation | !data-annotation.png! | see [Annotation with OAC and Reification|Open Annotation Collaboration (OAC)#Annotation with OAC and Reification]\\ Reification]. New subclass of oac:Annotation |
New subclass of oac:Annotation that allows the Basket code to recognize more easily the item type. \\
(!) TODO Mitac & Stanislav: Change the Data & Image Annotation backend to use rso:DataAnnotation and rso:ImageAnnotation |
| Forum | | | !forum.png! | Not in RS3.5 |
| Image | crm:E38_Image | !img.png! | (?) Dominic: we don't have a display of the image only, so do we need this? Yes, we will need this soon\\
(!) TODO Vlado: ##Note2: change RKD mapping to make explicit image URL instead of has_image_file and attach E38. BM mapping already does that |
| Image Annotation | rso:ImageAnnotation | !img-annotation.jpg! | see [Image Annotation Design#Example].\\
New subclass of oac:Annotation: see comment of Data Annotation |
| Image | crm:E38_Image | crm:E38_Image | !img.png! | We currently don't have a display of the image only, but will need it soon
| Image Annotation | rso:ImageAnnotation | rso:ImageAnnotation | !img-annotation.jpg! | see [Image Annotation Design#Example]. New subclass of oac:Annotation|
| Object | rso:FC70_Thing | rso:FC70_Thing | !data-object.png! | This class is set by a rule in [FR Implementation-old] |
| Object Field | rdf:Statement | rdf:Statement | !data-field.png! | see [Annotation with OAC and Reification|Open Annotation Collaboration (OAC)#Annotation with OAC and Reification].\\
When an AP is added to Basket, this Statement is created, same as making annotation or a link to AP |
| Search | rso:Search | !search.png! | new class. It has one field P3_has_note storing the textual representation of the search |
| Text Snippet | (none) | !txt.png! | Does not have item URI, therefore no type. Its title and content (rich-text description) are saved in Bookmark's body\\
(!) TODO Svetoslav & Stanislav: assume that no type means Text Snippet |
| Web Link | foaf:Document | !web.png! | New class with no fields.\\
(!) TODO Svetoslav: add statement as per ##Note1 |
| Search | rso:Search | rso:Search | !search.png! | new class with one field P3_has_note storing the textual representation of the search. Separate API to create this node |
| Text Snippet | rdfs:Literal | (none) | !txt.png! | Does not have target URI. Title and content (rich-text description) are saved in Bookmark's body|
| Web Link | foaf:Document | foaf:Document | !web.png! | New class with no fields. Separate API to create this node (as per ##Note1) |

Re Search:
- Jana: History is currently stored in Nuxeo
- Vlado1: I understand, but I thought we'd be storing the history same as the bookmarks? The question is who & when will create the node
- {color:#ff00ff}Jana: We be better store history in RDF indeed using the same data model. Still, it should be distinguishable from bookmarks as we need them separately in UI. (We may use a second basket for the user - a history one). I think we should use rso:Search for storing queries from history as well as saved searches (when we implement these).{color}
- Vlado2: doesn't "saved search" mean the same as "search placed in basket"? The Search node is the same, no matter whether it's in one or more Histories and/or Baskets

h2. Bookmark
Each bookmark resides in a basket and points to a target item (URL). Fields:
| *UI Field* | *Property (path)* | *Applicability and Notes* |
| | rdf:type | oac:Annotation (fixed value). Distinguished from other Annotations by residing in a Basket |
| Type | oac:hasTarget/rdf:type | All except Text Snippet. See [#Item Types] |
| | rdf:type | rso:Bookmark (fixed value) |
| Type | rso:hasTargetType | See [#Item Types]. In many cases oac:hasTarget/rdf:type has the same value |
| Preview | rso:hasTargetPreview | Image/Image Annotation: RS image URL. Web Link: URL from [Web Preview] service |
| Created by | oac:hasBody/dcterms:creator | |

- oac:hasBody/dcterms:creator and created oac:hasBody/dcterms:creator&created are set from the current user and datetime when the bookmark is created.
They are preserved if the bookmark is copied to another basket.
- oac:hasTarget/dcterms:creator and created oac:hasTarget/dcterms:creator&created are present only for 2 item types. They alraedy exist, they are not added when the bookmark is created.

h3. Web Link Example
<> a oac:Annotation; rso:Bookmark;
oac:hasTarget <>;
rso:hasTargetType foaf:Document;
rso:hasTargetShortURL <>;
rso:hasTargetPreview <>;
oac:hasBody <>.

<> a foaf:Document. ##Note1: creating the Bookmark inserts this statement
<> a foaf:Document. ##Note1: inserted with a separate API

<> a oac:Body;

class oac_Annotation as "<>" {
a oac:Annotation rso:Bookmark
rso:hasTargetType foaf:Document
rso:hasTargetShortURL <>
rso:hasTargetPreview <>
@base <> .

<DT219363.tif/annot/1> a oac:ImageAnnotation;
oac:hasBody <DT219363.tif/annot/1/body>;
oac:hasTarget <DT219363.tif/annot/1/target>.
dcterms:isPartOf <DT219363.tif>.
<DT219363.tif> a crm:E38_Image.
##Note2: RKD doesn't yet have this, BM has it
<DT219363.tif/annot/1/body> a oac:Body;
dcterms:creator "username1";
dcterms:created "2002-03-15T12:34:56"^^xsd:dateTime.

<bookmark/4> a oac:Annotation; rso:Bookmark;
oac:hasTarget <DT219363.tif/annot/1>;
rso:hasTargetType oac:ImageAnnotation;
rso:hasTargetShortURL <>;
rso:hasTargetPreview <DT219363.tif>;

- The illustration below shows "DT219363:tif" instead of "DT219363.tif" because of limitations in plantuml (treats "." as a package name separator)
- It's made with plantuml.jar standalone because of bug in the macro: {jira:PUML-73|server=Atlassian Plugins JIRA Studio} incomplete installation: {jira:OA-1608}

- The specification is written specific according to existing tools. However, the way that the data basket works should be generic for existing and new tools to come.
0 - The production version of ResearchSpace will require an API that means that all tools that adhere to it can be accessed and inetgrated with the databasket tool. This means that there must be a consistent type of URI / URL with tool parameter so that tools can be launched and placed in the appropriate state.
- These links should be ones that could be used as a normal web link in a browser (RESTful) so that the links could be used outside the databasket using a simple browser address box.
- To this end the specification should also have a technical specification outlining the way in which the databasket would interact with the ResearchSpace environment