@prefix rdf: . @prefix ns1: . @prefix foaf: . ns1:this rdf:type foaf:Person . @prefix atom: . rdf:type atom:Feed . @prefix sioct: . rdf:type sioct:Weblog . @prefix rdfs: . rdfs:label "kidehen@openlinksw.com's BLOG [127] description" . rdf:type sioct:BlogPost , atom:Entry . @prefix dc: . dc:title "Email As A Platform" ; foaf:maker ns1:this ; rdfs:label "Email As A Platform" . @prefix dt: . @prefix dcterms: . dcterms:created "2005-02-10T17:01:57Z"^^dt:dateTime ; dcterms:modified "2006-06-22T08:56:58-04:00"^^dt:dateTime . @prefix sioc: . sioc:id "a3942f6466da292f549e3f96994011eb" ; sioc:link ; sioc:content "\nEmail As A Platform It looks like more people are starting to realize that email is more than it seems. Especially given the drastic increase in storage size of web-based email applications, more people are realizing that email is basically a personal database. People simply store information in their email, from contact information that was emailed to them to schedule information to purchase tracking from emailed receipts. Lots of people email messages to themselves, realizing that email is basically the best "permanent" filing system they have. That's part of the reason why good email search is so important. Of course, what the article doesn't discuss is the next stage of this evolution. If you have a database of important information, the next step is to build useful applications on top of it. In other words, people are starting to realize that email, itself, is a platform for personal information management. \n[via Techdirt]\n \nYep! And this is where the Unified Storage vision comes into play. Many years ago the same issues emerged in the business application realm, and at the time the issue at hand was: separating the DBMS engine from the Application logic. This is what the SQL Access Group (SAG) addressed via the CLI that laid the foundation for ODBC, JDBC, and recent derivatives; OLE DB and ADO.NET. \n \nMost of us live inside our email applications and the need to integrate the content of emails, address books, notes, calendars with other data sources (Web Portal, Blogs, Wikis, CRM, ERP, and more) as part of our application interaction cycles and domain specific workflow is finally becoming obvious.  There is a need for separation of the application/service layer from the storage engine across each one of these functionality realms. XML, RDF, and Triple Stores (RDF / Semantic Data Stores) collectively provide a standards based framework for achieving this goal. On the other hand so does WinFS albeit total proprietary (by this I mean none standards compliant) at the current time.\n \nAs you can already see there are numerous applications (conventional or hosted) that address email, address books, bookmarking, notes, calendars, blogs, wikis, crm etc. specifically, but next to none that address the obvious need for transparent integration across each functionality realm - the ultimate goal.\n \nYes, you know what I am about to say! OpenLink Virtuoso is the platform for developing and/or implementing these next generation solutions. We have also decided to go one step further by developing a number of applications that demonstrate the vision (and ultimate reality); and each of these applications (and the inherent integration tapestry) will be the subject of a future Virtuoso Application specific post." ; atom:title "Email As A Platform" . @prefix ns10: . sioc:has_creator ns10:this ; sioc:has_container ; sioc:links_to , , , ; atom:source ; atom:author ns1:this ; atom:published "2005-02-10T17:01:57Z" ; atom:updated "2006-06-22T12:56:58Z" . @prefix opl: . opl:isDescribedUsing . ns10:this rdf:type sioc:User . @prefix rdf: . @prefix ns1: . @prefix foaf: . ns1:this rdf:type foaf:Person ; foaf:made . @prefix atom: . rdf:type atom:Feed . @prefix sioct: . rdf:type sioct:Weblog . @prefix rdfs: . rdfs:label "kidehen@openlinksw.com's BLOG [127] description" . @prefix sioc: . sioc:container_of ; atom:entry ; atom:contains . @prefix ns7: . ns7:this rdf:type sioc:User ; sioc:creator_of .