Data model (ontology) for Data Basket
RS-893

Basket Data Model

Overview

We try to reuse established ontologies as much as possible. We considered using the latest version of Open Annotation (OA) as a basis, but gave up on this idea.In order to have a simple and coherent model, Data Basket uses the same basis as Data+Image Annotation: Open Annotation Collaboration (OAC). Still, we use some approaches from OA, eg ore:Aggregation.

We map entities from the Data Basket Spec 3.5 to the following:

• Jana: why do we need a Basket?
  • Vlado1: To distinguish the bookmarks of one user from those of another
  • 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.
  • 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
• 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
  • 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)

Prefixes

We use the following prefixes:

Basket

A Basket is a bag of Bookmarks (represented as ore:Aggregation), owned by a particular user. Fields:

Processing:

• A basket is created when the first bookmark is being added (on demand)
• A basket is never deleted, even on action Clear All

Basket Example

<http://www.researchspace.org/basket/1> a ore:Aggregation;
  dcterms:creator "username2";
  ore:aggregates <http://www.researchspace.org/bookmark/3>, <http://www.researchspace.org/bookmark/4>.

• For now users are represented with a Nuxeo username, not with URI
• A "sequence" service is added, that returns sequentially-numbered URIs of a given prefix (kind)

Item Types

Target Items can have one of the following types. The type is stored in two places for convenience, and with different characteristics:

• 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		see Annotation with OAC and Reification. New subclass of oac:Annotation
Forum				Not in RS3.5
Image	crm:E38_Image	crm:E38_Image		We currently don't have a display of the image only, but will need it soon RS-1088
Image Annotation	rso:ImageAnnotation	rso:ImageAnnotation		see Image Annotation Design#Example. New subclass of oac:Annotation
Object	rso:FC70_Thing	rso:FC70_Thing		This class is set by a rule in FR Implementation
Object Field	rdf:Statement	rdf:Statement		see 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	rso:Search		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)		Does not have target URI. Title and content (rich-text description) are saved in Bookmark's body
Web Link	foaf:Document	foaf:Document		New class with no fields. Separate API to create this node (as per ##Note1)

Re Search:

• Vlado: should the rso:Search node be created when the Search is put in history, or only when it's put in basket?
• 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
• 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).
• 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

Bookmark

Each bookmark resides in a basket and points to a target item (URL). Fields:

Notes:

• Applicability describes for which item types that field is applicable, and gives extra notes
• The following fields shown on Data Basket UI design don't really exist: Sent by, Tags, Last updated

Processing:

• 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&created are present only for 2 item types. They alraedy exist, they are not added when the bookmark is created.

Web Link Example

<http://www.researchspace.org/bookmark/3> a rso:Bookmark;
  oac:hasTarget <http://www.wikipedia.org>;
  rso:hasTargetType foaf:Document;
  rso:hasTargetShortURL <http://goo.gl/KA4Ll>;
  rso:hasTargetPreview <http://api.webthumbnail.org?width=512&height=384&format=png&browser=firefox&url=http://www.wikipedia.org>;
  oac:hasBody <http://www.researchspace.org/bookmark/3/body>.

<http://www.wikipedia.org> a foaf:Document. ##Note1: inserted with a separate API

<http://www.researchspace.org/bookmark/3/body> a oac:Body;
  dcterms:creator "username2";
  dcterms:created "2012-10-08T12:34:56"^^xsd:dateTime;
  rso:P3_has_title "Wikipedia";
  rso:P3_has_description "Wikipedia is a world-wide collaboratively-created encyclopedia".

Web Link Illustration

In the illustrations below, a red square indicates a pre-existing statement. All others are created when a bookmark is created.

Image Annotation Example

See Image Annotation Design#Example (we present only the relevant part of the image annotation's data)

@base <http://www.researchspace.org/> .

<DT219363.tif/annot/1> a oac:ImageAnnotation;
  oac:hasBody <DT219363.tif/annot/1/body>;
  oac:hasTarget <DT219363.tif/annot/1/target>.
<DT219363.tif/annot/1/target> a oac:ConstrainedTarget;
  oac:constrains <DT219363.tif#xywh=1000,900,250,250>.
<DT219363.tif#xywh=1000,900,250,250>
  dcterms:isPartOf <DT219363.tif>.
<DT219363.tif> a crm:E38_Image.
<DT219363.tif/annot/1/body> a oac:Body;
  dcterms:creator "username1";
  dcterms:created "2002-03-15T12:34:56"^^xsd:dateTime.

<bookmark/4> a rso:Bookmark;
  oac:hasTarget <DT219363.tif/annot/1>;
  rso:hasTargetType oac:ImageAnnotation;
  rso:hasTargetShortURL <http://goo.gl/RdPAb>;
  rso:hasTargetPreview <DT219363.tif>;
  oac:hasBody <bookmark/4/body>.
<bookmark/4/body> a oac:Body;
  dcterms:creator "username2";
  dcterms:created "2012-10-08T12:34:56"^^xsd:dateTime;
  rso:P3_has_title "The nose is large and wrinkled"; # copied from the Image Annotation
  rso:P3_has_description "Some equally silly description".

Notes:

• We omit http://www.researchspace.org/ from the URLs by using @base.
• The hasTargetPreview URL should be resolvable! It's given above as <DT219363.tif>, but an appropriate thumbnail-size IIPserver URL should be used instead
• dcterms:creator&created from <DT219363.tif/annot/1/body> are displayed in the Bookmark, although they are not stored as part of the bookmark

Image Annotation Illustration

• 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 incomplete installation: OA-1608

Discussion

Dominic:

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

Vlado:

• I agree that bookmarking should be more in the style of using "browser address box". However, our URIs are currently not resolvable, see RS URLs and URIs.
  Adding a new item type ("tool") to the basket is a matter of adding it to the table above, and to frontend handling code (different types have somewhat different handling behavior).
• For full extensibility the Basket should be able to figure out the item's type from the item URI alone. That is the case above, except for Web Link (for which we need to add a type statement upon adding to basket).
  • I've used "a foaf:Document" above (that's the range of foaf:homePage)
  • OA recommends using "a dcmitype:Text; dc:format "text/html" which I don't find very nice (and may change)