W3C Web annotations are a powerful way to support metadata information about digital resources. The Web Annotation Data Model proposes standardised RDF structures that express this by implementing a hierarchical annotation structure. Those annotations are designed to be shared, linked, tracked back as well as searched and discovered across di erent peers. However, non-Semantic Web experts may struggle to produce the corresponding RDF data or SPARQL queries. Therefore, we propose Anno4j, a Java-based library that gives developers the possibility to create and consume Web Annotations by using plain old Java objects. Anno4j follows natural Object-oriented idioms including inheritance, polymorphism, and composition to facilitate the development with Web Annotations. An extensible and modular architecture supports enhancements and use-case speci c model alterations, while the plugin functionality of Anno4j allows to enrich querying by adding custom function evaluators.
The Web Annotation Data Group1 recently issued a new version of the Web
Annotation Data Model [
combine information and metadata beyond the boundaries of single enterprises or applications. The resulting combined knowledge base increases the bene t as well as the degree of information of every participant.
This aligns heavily with the \purpose" of the Semantic Web, with its
promising advantages of combined and linked data. Although the advantages are
promising, there exists an initial hurdle to make oneself familiar with the Semantic Web
technologies as well as Linked Data \rules" [
To overcome some of these shortcomings and lower the barrier of Semantic Web technologies, Anno4j2 provides a Java library to directly map Java objects to and from the Web Annotation Data Model. The core contributions are as follows: { Idiomatic access to W3C Web Annotation Data Model following natural object-oriented idioms. { Support for use-case speci c Web Annotation Model alterations and extensions. { A library built on-top of OpenRDF Alibaba3, allowing for a broad eld of application. { Path-based query criteria for extensive annotation search functionality. { Developer-friendly Open-Source Apache V2 license.
The remaining paper is structured as follows. Section 2 brie y lists the core features of the library and section 3 highlights related work in the context of the WADM. Section 4, section 5, and 6 will give more detailed information about persistence, querying, and deeper insight into Anno4j. Finally, section 7 will conclude the paper by depicting future work and a planned roadmap. 2
Anno4j is a Java-based library, that o ers developers the opportunity to easily create and consume annotations conform to the WADM by writing Java POJOs. The framework has been designed in a modular and extensible fashion, allowing users to extend at every feature of Anno4j. The core functionalities of Anno4j are: { Persistence: Simple Java objects provide the basis of persistence and can easily be created and persisted with a given Anno4j object (see section 4). { WADM implementations: Built-in and prede ned implementations for all basic classes proposed by the W3C Web Annotation Data Model. { Querying: A QueryService object created by an Anno4j instance can be supported with di erent query criteria (formalised as LDPath arguments) to query and consume respective annotations of the Anno4j database (see section 5).
{ Plugin Extensions: By supporting a plugin interface, users can de ne own RDF statements in combination with respective evaluation operators, which then can be used as querying criteria in order to even enhance the querying functionality and ne tune it to their particular use-case (see section 6). { Context awareness: RDF databases are often using di erent contexts to divide their data into subgraphs. This feature is also possible in Anno4j, turning RDF triples into quads. { Input and Output: Anno4j is able to both read and write annotations from and to di erent standardised serialisations, such as JSON-LD, TURTLE, N3-Triples, RDF/XML, etc. 3
Alongside the WADM, the Web Annotation Working Group also issued a
protocol, namely the Web Annotation Protocol WAP [
Listing 1.1. Example POST request to create an annotation using the WAP protocol 1 POST / a n n o t a t i o n s / HTTP / 1 . 1 2 Host : e x a m p l e . org 3 Content - Type : a p p l i c a t i o n / ld + json 4 5 f 6 7 8 9 10 11 12 13 g " @ c o n t e x t " : " http : // www . w 3 . org / ns / oa " , " @ t y p e " : " oa : A n n o t a t i o n " , " body " : f " @ t y p e " : " oa : E m b e d d e d C o n t e n t " , " v a l u e " : " I like this page !" g , " t a r g e t " : " http : // www . e x a m p l e . com / i n d e x . html "
Before the WAP has been fully published, similar approaches have been made
in order to give the annotations of the WADM (or in this case formerly known
as the Open Annotation Data Model OA [
In comparison, the REST-based approaches o er some advantages. As it is a protocol, there exists the freedom of implementing only parts of the speci cation, allowing the WAP-conform server or client to be adapted to a speci c use case and thusly be more lightweight. The REST interface enables the server to be used platform independently, annotations are queried as well as created using JSON. On the other hand, all RDF instances in Anno4j are present as a POJO, allowing them to be used further in object-oriented ways, without the need of up-front parsing. Anno4j is also able to read and generate di erent serialisations of the RDF objects if needed. 4
Anno4j's persistence implementation follows a very simple mechanism. The library allows direct mapping plain old Java objects to RDF information from a remote or local SPARQL endpoint. Listing 1.2 shows a simple example how to create RDF information with Java objects. The annotation object is created using an Anno4j instance. The resulting RDF triples will automatically include the necessary information, e.g. that the annotation node is of the type (RDF relationship rdf:type) oa:Annotation. Creating one exemplary body object (type dctypes:StillImage) and initialising its eld accordingly would result in the RDF entities and relationships shown in gure 1. The RDF triples for properties, types, and relationships between objects are created accordingly after the persist was called.
Listing 1.2. Exemplary creation and initialisation of an object // I n i t i a l i s e f i e l d s body . s e t D e p i c t s ( " B a r a c k O b a m a " ) ; a n n o t a t i o n . s e t B o d y ( body ) ; // P e r s i s t the a n n o t a t i o n a n n o 4 j . p e r s i s t ( a n n o t a t i o n ) ; oa:Annotation rdf:type anno oa:hasBody body rdf:type dctypes:
StillImage ex:depicts "Barack Obama"
Anno4j already comes with built-in and prede ned implementations for most of the classes proposed by the Web Annotation Data Model. This enables developers to start right away with the core functionality of producing annotations. However, use-case speci c alterations and enhancements are easy to integrate by extending the persistence layer with their own respective classes. The main element to do this is using the Java annotation @Iri, which is used at interface level of the given Java interface and on each setter/getter pair. The annotation at interface level sets the RDF class (relationship rdf:type) of the respective RDF object, while an assigned @Iri at setter and getter method will create the respective predicate attached to the RDF object. Anno4j will automatically provide a proxy-based implementation for the given interface, which already includes the expected behaviour of RDF mapping.
As an example, consider listing 1.3, showing the implementation of a body that is used to convey detected things on a given image and which was already used in the previous example in listing 1.2.
Listing 1.3. Exemplary body implementation with one eld \depiction" // Sets the type of the c l a s s @Iri ( D C T Y P E S . S T I L L _ I M A G E ) p u b l i c i n t e r f a c e I m a g e D e t e c t i o n B o d y e x t e n d s Body { // S e t t e r s and g e t t e r s r e q u i r e d for the RDF
p r e d i c a t e @Iri ( EX . D E P I C T S ) void s e t D e p i c t s ( S t r i n g d e p i c t i o n ) ; } @Iri ( EX . D E P I C T S )
S t r i n g g e t D e p i c t s () ;
Besides persisting Web Annotations, Anno4j also provides ways to query the annotations or even subparts of them that t speci c needs. On the one hand, Anno4j provides convenient mechanisms to directly query e.g. for all annotation bodies with a particular type or Anno4j Java class. On the other hand, Anno4j o ers more expressive ways, using the path-based query syntax LDPath4, to dene query criteria to reduce the e ort for non-SPARQL experts. LDPath, which is similar to XPath, allows a more compact and inline de nition of criteria in contrast to the verbose pattern-based query language SPARQL. A uent interface API supports readability and comprehensible query de nition. A collection of individual criteria de nes the desired characteristic of the resulting annotations. Hereby, multiple criteria are combined with a logical AND operation.
Listing 1.4 shows an example using LDPath to de ne two di erent criteria for annotations. In this example we are searching for annotations which satisfy the conditions that the annotation body should be a dctypes:StillImage and Barack Obama is depicted on the image.
Listing 1.4. Anno4j Query Example
Although Anno4j uses LDPath as syntax for query criteria, there is no need for a special LDPath-capable RDF endpoint, because LDPath criteria are translated to an equivalent valid SPARQL 1.1 query. This allows developers to reuse generic SPARQL 1.1 endpoints for their use-cases. Besides basic path criteria, Anno4j also supports a wide range of di erent LDPath condition types5: { Forward and reverse path conditions { Resolving of namespace abbreviations { Recursive path like OneOrMore(+) or ZeroOrMore(*) { Comparison methods like equal, greater, or lower for conditions { Union of multiple paths { Type or datatype conditions { Logical combination of conditions { Custom functions (see section 6)
After execution of the translated SPARQL query against the speci ed endpoint, all query results are automatically transformed to corresponding annotated Java objects. This abstraction layer allows developers to easily work with RDF information in contrast to constructing complex SPARQL queries and parse the SPARQL results.
5 For further and detailed description of the LDPath criteria, please refer to the LDPath speci cation at http://marmotta.apache.org/ldpath/language.html
At its core, Anno4j builds upon the OpenRDF Alibaba library (former Elmo codebase) which provides simpli ed RDF store abstractions and combines the exibility and adaptivity of RDF with the powerful object-oriented programming model of Java. It is able to map Java objects to and from RDF resources in a non-intrusive manner that enables developers to work with resources stored in a SPARQL endpoint. Nested properties of RDF resources are lazy evaluated to avoid unnecessary fetching of unused information for faster and e cient query evaluation. Considering listing 1.3, lazy evaluation implies that the RDF value for depicts is not fetched from the SPARQL endpoint until getDepicts of the respective Java object is called.
As mentioned before, Anno4j uses LDPath syntax to de ne query criteria. Internally, LDPath criteria is automatically transformed to valid SPARQL 1.1 syntax. Some LDPath expressions can be directly mapped to similar SPARQL 1.1 property path expressions (e.g. path selection, inverse path selection \^", or alternative path \j"). LDPath expressions which can't be directly mapped to SPARQL 1.1. are translated to similar SPARQL constructs (e.g. datatype or \isa" tests are mapped to SPARQL FILTER constructs). To support extensibility, the translation process follows the Interpreter software pattern. Hence there exists a speci c interpreter for each LDPath expression. This allows developers to easily integrate custom LDPath expressions, such as function predicates, test functions and lters, as well as register a query interpreter which transforms the new query element to valid SPARQL 1.1 to ensure full compatibility with generic SPARQL endpoints.
This extension mechanism was induced by the requirement to integrate query
extensions like the recently proposed SPARQL-MM [
This paper introduced the library Anno4j, which enables Java developers to create and consume RDF annotations. Those annotations are conform to the WADM, allowing them to be shared and exchanged between di erent locations. Anno4j features simple persistence of RDF objects via Java objects, its querying functionality is based on LDPath, supporting a wide range of combinable path criteria to form a powerful annotation consumption tool. Both features can be extended easily, so developers can ne tune their respective Anno4j instance to their needs.
Anno4j is available under Apache V2 license at github. Future work on this library will include the attempt to provide the functionality of Anno4j to other programming languages. First proof-of-concepts show positive results for a C++ mapping using Java Native Interface. This would allow developers to write their software natively in C++ but still use Anno4j for a convenient creation and querying of Web Annotations. Other extensions like SPARQL-MM querying or a QueryWizard for a guided creation of LDPath criteria based on statistics of your SPARQL endpoint are currently actively developed by the community.
The current application of the Anno4j library has led to various lessons learned, as di erent projects make use of Web Annotations in conjunction with Anno4j to make a more convenient use of the annotations. However, as nearly every application of today is web-oriented, a web facet could lift Anno4j to a broader use case. This requirement is exactly tailored to the WAP speci cation, so future steps will include a layer on top of Anno4j, allowing it to be used as a WAP-conform server. Additionally, as the querying mechanism of Anno4j in combination with LDPath is manifold, we intend to extend the WAP requirements for our implementation to deliver more comprehensive querying.
The presented work was developed within the MICO project partially funded by the EU Seventh Framework Programme, grant agreement number 610480.