ESciDoc Services Annotator

IN PROGRESS

Introduction

The motivation for defining an Annotator service comes from MPI MB Demonstrator proposal. Main aim is to be able to enrich publications with references or short descriptions/comments on resources about which a publication (or another form of work) is about. There is an assumption that most of these are external resources and are not managed by MPDL services. However, this does not have to be the case.

Some premisses:

• The solution shall not be heavy for PubMan and shall be applicable to other applications as well
• The solution shall be flexible enough and allow for extensions of various types of resources
• The solution shall be scalable
• ...

Related concepts/implementations

• see RDF Metadata store
• see Open Annotation Collaboration (OAC)

Basic Data Model

• For basic data model and definitions please check Open Annotation Collaboration (OAC)
• The ontology developed for the Annotator service at MPDl is shown below

• A Resource is a class of all individuals representing content which is managed in the system. In the depicted ontology, Annotation(SilvaAnnotation) and Body are considered as a Resource.
• An Annotation is a subclass of managed Resource class. It is class of individuals that relate the Body and the Target individuals, and may have some additional metadata.
• A Body is the class of individuals which holds any kind of information about the Target individual associated through the Annotation individual.
• A Target is the class of individuals about which the Body in general is.
• A SilvaAnnotation is a subclass of an Annotation referencing Silva database resources (see MPDL Demonstrator Marine Microbiology for more details)
• A Service is a class of individual services that may be associated with particular types of annotations, e.g. Silva browser

In particular cases Target individual is not related with the Annotation to a Body individual. In this case for the Annotation individual it is assumed that it is an e.g. "textual" annotation (e.g. it is described via a "datatype" property as a content of the annotation rather than an "object" property).

Data Example

• pubman:P-1 is a publication about a "Marine metagenome 1096626369196, whole genome shotgun sequence".

    Environmental Genome Shotgun Sequencing of the Sargasso Sea, 
    J. Craig Venter,Karin Remington,John F. Heidelberg,Aaron L. Halpern,Doug Rusch,Jonathan A. Eisen,Dongying Wu,Ian Paulsen,Karen E. Nelson,William Nelson,
    Derrick E. Fouts,Samuel Levy,Anthony H. Knap,Michael W. Lomas, Ken Nealson, Owen White,Jeremy Peterson,Jeff Hoffman,Rachel Parsons,Holly Baden-Tillson,
    Cynthia Pfannkoch, Yu-Hui Rogers, and Hamilton O. Smith
    Science 2 April 2004: 66-74.Published online 4 March 2004, http://www.sciencemag.org/content/304/5667/66
     

• silva:AACY020292957 is the resource in the Silva database, providing some more details on the sequence (see http://www.arb-silva.de/browser//AACY020292957 ). A Target individual may have additional properties. These are highly dependant on the target itself.
• anni:S-1 is a SilvaAnnotation that has as a body the pubman:P-1 publication in PubMan repository and as a target the silva:AACY020292957 resource in Silva database. This individual has properties refering to the environmental data such as geo coordinates, some description and comment, system generated properties such as: created-by, created-on.
• an:SilvaAnnotationType is an individual of the class AnnotationType and represents an instance of Annotation types related to Silva resources.
• service:MegXBlast and service:SilvaBrowser are concrete services of which the system is aware of. As being related to the an:SilvaAnnotationType via an:hasService property, it is clear that these are services that can derive some functionality for the annotations which are related to an:SilvaAnnotationType individual. For example: MegXBlast algorithm, transformation and automated population of some annotation properties via SilvaBrowser service etc. (Note: the example assumes that the SilvaBrowser may offer data in processable format, to be checked with the institute directly - here provided only as an example).

Remark

• To be considered during implementation: check if it makes sense to keep some automatically ingested Target instance properties with the Annotation instance itself or with the Target instance. This will not conflict the basic ontology model, but would probably require subclassig the Target in similar manner as the Annotations.

Data model extensions

Annotation set

In particular cases there is a need to related various Annotations into an Annotation set. An Annotation set can be considered is an arbitrary choice of Annotations related to a particular topic, created by a particular user or user group (in case of Collaborative annotations). An extension to the model that includes also Annotation sets is given below.

For the purpose of relating the Annotations into an AnnotationSet, OAI-ORE term "aggregates" is used (see OAI-ORE Vocabulary )

Implementation concept

The Annotator service implementation has two general components:

• Annotator store
• Annotator tool

Note: concrete implementation may bring other aspects on this issue, therefore this shall be considered as a high-level design.

Annotator store

• The Annotator store is an RDF store offering interfaces to create and query the data. An architecture similar to the MDStore Architecture is envisioned for this purpose.
• The RDF Store is primary storage for the Annotator resources
• eSciDoc core infrastructure and FedoraCommons repository may be used as an LTA archival solution - however, this would be completely separated from the Annotator store.
• Internal AA component will be built in the Annotator store, however pluggable to implement use external AA components such as eSciDoc AA.

Max Planck Digital Library

Publication Management

Open Archives Initiative Object Reuse and Exchange

Resource Description Framework

Enhanced Scientific Documentation

Long-term Archiving