Page Comparison

...

From the usage scenarios described in Section 2.1, the use cases depicted in Figure 1 have been derived.

Figure 1 - Use cases

The actors of the use case are divided in two types of users, namely, the NanoPub Author and the NanoPub User. While the former interacts with the system for the purpose of annotating an assertion, publishing the assertion or managing the assertions he published, the later consumes the published assertions by means of searching, retrieving and citing the assertions.

...

From the use cases described in the last session, we have decided to split the expected functionality of the system in two separate applications, namely, ORKA and NanoPub Store. ORKA is responsible for providing support to users who want to annotate a triple originated from a graph analysis tool by changing the triple's predicate. The edited triple is then transformed into a nanopublication adding the provenance of the author and keeping the relationship with the original triple. The NanoPub Store is responsible for storing the nanopublications created in the Triple Annotator as well as allowing users to search for stored nanopublications and cite them.

Figure 2 - General architecture of ORKA and NanoPub Store applications

Figure 2 depicts the general architecture of ORKA (yellow) and NanoPub (green) applications. The applications have been divided in the following three main integrated but independent layers:

...

type: GET
path: http://semlab1.liacs.nl:8081/annotator/entry
parameter 1: original triple and referrer (see JSON model 1)
desc: entry point for external tools to initiate annotation
returns: -

Get Predicates (not yet implementedused internally to cache list of predicates)
type: GET
path: /apiannotator/predicates
parameter 1: -
desc: list known predicates, a simplistic approach in making a static list of predicates available
returns: an array of predicate URIs and a label (see JSON model 2)

...

Extensions under consideration:

The optional referrer_context enables the tool that links to the annotator to capture any additional provenance or context in the final nanopublication. This may include e.g. a version number of the dataset that is being annotated, or an internal identifier that can be used to retrieve an annotation nanopublication at a later time. Keys have to be valid RDF predicates and values have to be valid RDF resources or literals.

  “referrer_context”: {       // free choice of key-value pairs for convenience of the referrer
       key1: value1,          // keys should be an RDF predicate
       key2: value2,          // values are RDF resources or literals
       ...
  }
}

...