- 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>
Role: Primary representative for OpenLink Software (http://www.openlinksw.com). 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 http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0038.html 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 in http://www.w3.org/2009/sparql/wiki/Extensions_Proposed_By_OpenLink Best Regards, Ivan Mikhailov OpenLink Software http://virtuoso.openlinksw.com
Received on Thursday, 26 February 2009 11:24:01 UTC