- From: Nathan <nathan@webr3.org>
- Date: Mon, 12 Apr 2010 01:56:07 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Kingsley Idehen <kidehen@openlinksw.com>, public-lod <public-lod@w3.org>
Melvin Carvalho wrote: > 2010/4/12 Kingsley Idehen <kidehen@openlinksw.com> > >> All, >> >> Edited, as I just realized some critical typo+errors that affect context. >> >> Hopefully, you understand what Nathan is articulating (ditto Giovanni). If >> not, simply step back and as yourself a basic question: What is Linked Data >> About? >> >> Is it about markup? Is it about Data Access? Is it about a never ending >> cycle of subjective commentary and cognitive dissonance that serves to >> alienate and fragment a community that desperately needs clarity and >> cohesion. >> >> Experience and history reveal the following to me: >> >> 1. Standards based data access is about to be inflected in a major way >> 2. The EAV (Entity-Attribute-Value) graph model is the new focal point of >> Data Access (covering CRUD operations). >> >> Microsoft, Google, and Apple grok the reality above in a myriad of ways via >> somewhat proprietary offerings (this community should really learn to look >> closer via objective context lenses). Note, "proprietary" is going to mean >> less and less since their initiatives are HTTP based i.e., it's all about >> hypermedia resources bearing EAV model data representations -- with varying >> degrees of fidelity. >> >> ** >> Players and EAV approaches: >> >> 1. Microsoft -- OData (EAV with Atom+Feed extension based data >> representation) >> >> 2. Google -- GData (EAV with Atom+Feed based data representation) >> >> 3. RDF based Linked Data -- (RDF variant of EAV plus a plethora of data >> representation formats that are pegged to RDF moniker) >> >> 4. Apple -- Core Data (the oldest of the lot from a very proprietary >> company, this is basically an EAV store that serves all Mac OS X apps, built >> using SQLite; until recently you couldn't extend its backend storage engine >> aspect) . >> ** >> >> Reality re. Business of Linked Data: >> >> "Data as a Service" (DaaS) is the first step i.e., entity oriented >> structured data substrate based on the EAV model. In a nutshell, when you >> have structured data place, data meshing replaces data mashing. Monikers >> aside, entrepreneurs, CTOs, and CIOs already grok this reality in their own >> realm specific ways. >> >> Microsoft in particular, already groks data access (they developed their >> chops eons ago via ODBC). In recent times, they've groked EAV model as >> mechanism for concrete Conceptual Model Level data access, and they are >> going unleash an avalanche of polished EAV based applications courtesy of >> their vast developer network. Of course, Google and Apple will follow suit, >> naturally. >> >> The LOD Community and broader Semantic Web Problem (IMHO): >> >> History is a very good and kind teacher, make it an integral part of what >> you do and the path forward becomes less error prone; a message that hasn't >> penetrated deep enough within this community, in my personal experience. >> >> ** >> Today, I see a community rife with cognitive dissonance and desires to >> define a non existent "absolute truth" with regards to what constitutes an >> "Application" or "Killer Application". Ironically, has there EVER been a >> point in history where the phrase: Killer Application, wasn't retrospective? >> Are we going to miraculously change this, now? >> >> ** >> >> Has there ever been a segment in the market place (post emergence of >> Client-Server partitioning) where if you didn't make both the Client and the >> Server, the conclusion was: we have nothing? >> >> We can continue postulating about what constitutes an application, but be >> rest assured, Microsoft, Google, Apple (in that order), are priming up for >> precise execution with regards to opportunities in the emerging EAV based >> Linked Data realm. They have: >> >> 1. Polished Clients >> 2. Vast User Networks >> 3. Vast Integrator Networks >> 4. Vast Developer Networks >> 5. Bottom-less cash troves >> 6. Very smart people. >> >> In my experience, combining the above has never resulted in failure, even >> if the deliverable contains little bits of impurity. >> >> Invest a little more time in understanding the history of our industry >> instead of trying to reinvent it wholesale. As Colin Powell articulated re. >> the IRAQ war: If You Break The Pot, You Own It! >> >> Folks, we are just part of an innovation continuum, nothing is new under >> the sun bar, context !! >> > > +1 > > Just to add maybe that CRUD is just one part of the equation, after that can > come aggregation, curation, self healing etc. > > Now I'm trying to work out whether what you've presented is good news or > bad. > > http://www.w3.org/2007/09/map/main.jpg > > Looking at the WWW Roadmap, are we all headed for the Sea of > Interoperability or to be sucked in to a Growing Desert Wasteland? > This may not make much sense and will probably sound like a random response, but.. AFAICT the linked data movement would need to tie in more with the REST community and then aim to be adopted by the internet of things / 4g movement and big players, that's what will make or break it ultimately, (imo). There are several blockers to adoption which I mentioned the other day on this list, however linked data / semantic web does have a few strengths in it's favour, generic http uri's, seamless interlinking between all resources, sparql (when positioned on the client side or edge). The approaches of the big three mentioned above all keep some focus on the silo approach with less data source interlinking, primarily because of the vested interests in keeping "search" alive and strong. Whereas a linked data adoption via the internet of things and some time for the web community at large to realise we don't need web-wide searching (or loose the "google-it" mentality if you prefer) would see linked-data come out tops. aside: a return to "web directories" may actually be a beneficial thing to linked data and the web at large.. regards!
Received on Monday, 12 April 2010 00:56:47 UTC