W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

Introduction: Ivan Mikhailov

From: Ivan Mikhailov <imikhailov@openlinksw.com>
Date: Thu, 26 Feb 2009 17:23:19 +0600
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-Id: <1235647399.5402.5530.camel@octo.iv.dev.null>
Role: Primary representative for OpenLink Software

I an a developer in OpenLink Virtuoso Universal Server project. Our main
product is a cross-platform middleware server for SQL, RDF and XML data
integration. Being a hybrid of high-performance RDBMS, web server and
run-time for various hosted languages, Virtuoso become good foundation
for scalable RDF storage and efficient SPARQL web service endpoint.
OpenLink Virtuoso is widely used in Linking Open Data project for public
and private web service endpoints as well as for all sorts of data
manipulation at publishers' side. Both commercial and open-source
versions of Virtuoso are available.

My previous introduction is archived at
Last two years did not make it obsolete. Scalability is better and the
language is enriched but application developers' needs remain the very
same. There's only one change on the horizon.

Some things are good candidates for storing in RDF, such as basic facts
and all sorts of thoughts. Some are bad, notably images and timed
sequences. Some are "double bad", e.g., video that is timed sequence of
images). But even if a thing can not be stored in RDF, its description
and references to its parts can. Say, I can point to specific part of a
picture and share this pointer among community members.

Current achievements in RDF storage scalability let us hope that we will
be able to share numerous descriptions and pointers to parts of the
biggest thing that the biggest community have in everyday use. Geodata.
That is naturally the next big use case for the whole technology. We've
seen small data sets in small communities (intranets). Now we
demonstrate progress in handling small data sets in big communities
(FOAF) and big data sets in small communities (BioRDF and other
scientific applications). Next stop Earth.

Hence the SPARQL language should be optimizer-friendly and at the same
time it should allow optimization by hands; SPARQL protocol should be
convenient for mass processing of uniform requests and for partial
result sets; business intelligence support and internationalized
free-text are also absolutely required. The related proposals are listed

Best Regards,

Ivan Mikhailov
OpenLink Software
Received on Thursday, 26 February 2009 11:24:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:53 UTC