We need for something like GData API but for RDF

Semantic Web is the greatest technology and different useful services and tools already exist too, but we haven’t have a significant impact of them in our live. Several huge online storages, like Wikipedia, DBLP and others, have been represented as RDF under Open Liked Data Initiative. But it isn’t enough, because we as ordinal users haven’t ways for publishing our semantic data directly like we can in Google Base (GData API Protocol is used), Amazon BaseDB, CouchDB.

I would like to write different useful agents on top of a ‘future semantic API’ for reading/writing RDF directly: PIM, bibliographic manager, moneys, personal categories and so on, information from one agent will be available in another immediately and visa versa. For an example, I would like to describe my personal music collection and prefers and then I will show that data in my blog through a special WordPress plugin and see only interest for me news in the Amazon site. Moreover, we could use another implementation of that API in desktop and use it personally or in an Intranet.

Luckily we already have all technologies to create that API: REST Architecture, RDF Data Model, SPARQL Query Language and different RDF serialization formats. I have just developed my own semantic API version from scratch. But, I think, that it’s very responsible work, and I would like to participant in a similar project.

We need to choose the embedded RDF storage

After we have developed semap RESTful API we have been starting to work on the semap-1.0-M1 version. But the first thing that we should solve is a choice of a compatible with the Apache License 2.0 embedded RDF storage. It’s a difficult task for us and we created the special wiki-page and have developed the open source project selection criteria for it first.

Now we have only three real candidates: Sesame, Open Anzo and Mulgara. Unfortunately, we dropped the Jena from our list, because, it has the old annoying graph model and some problems with scalability (see more in the “RDF Triple Stores“).

Revision note (from 19 Nov 2007): we have decided to use Sesame2 Native RDF Repository only (see the comment bellow about that decision). In the future we will try to use embedded RDBMS too, such as H2 or Berkeley DB and will measure performance parameters too. It’s important for us now to quickly implement the initial version 1.0-M1 and after that improve the performance, write more documentation and so on, because, we are in the “Proof of Concept” stage now.

Some words about semap RESTful API

Today we have prepared the initial version of semap RESTful API. It was very interesting work for us, because we didn’t see any similar approaches how to work with RDF via REST-style way.

But, first of all, some words about semap project. It’s the attempt to realize our “semantic bus” vision, then we can create, modify, delete and search RDF information without deeper knowledges about RDF storages, OW-DL reasoners, named-graphs implementations and so on, as simple as we usually work with ordinary files. Even any user should simply write easy scripts in any programming languages to work with semantic information about its friends, music, photos, video, books. On the other hand advanced users can expand semap to support additional data formats, databases, features through semap’s eclipse-based plugin architecture.

Semap is a middleware solution and it doesn’t have any constraints on the stored RDF data, all work is done by various semantic services above it via RESTful API. We have ideas about several useful semantic services, but with semap we are developing only one – address book service. This is the console-based reference implementation of a semantic service for semap. We have developed the console interface specification for it and are going to create the Firefox plugin to quickly find required contacts directly from the browser. For example, you will be able to import any contact from the Internet via URI dereferencing via console tool and after that immediately find this information in the browser via plugin. Or, may be, we will configure the Zotero to store it’s data in semap too. As you can see, semap is like the “semantic bus” – any semantic service can store RDF information into it and any other semantic service can read them after that at once.

At the given state it’s very important for us to develop useful and easy to use semap API for any potential semantic service developer. We will demonstrate you some examples on basis of some real contacts semantic data, other details you can find in the specification.

Today this blog was created!