- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 26 Jul 2012 11:24:02 -0400
- To: public-lod@w3.org
- Message-ID: <50116112.2050202@openlinksw.com>
On 7/26/12 8:30 AM, Michael Brunnbauer wrote: > Hello Kingsley, > > On Thu, Jul 26, 2012 at 07:34:01AM -0400, Kingsley Idehen wrote: >> My answer: when you publish a document on the Web you don't necessarily >> do so with a single search engine / document indexer in mind. > Thats the theory. In practise, you have Google in mind. No, its part of the mind, in a very temporal way :-) > >> As I said it isn't about Google. Its just about publishing documents >> because you want the content available to others on the network. > "But the others don't speak Turtle" Remember, this is about one step at a time. The challenge that Turtle addresses is the need to deploy Linked Data modulo the challenges presented by the following: 1. Web Server Control 2. Domain Control 3. Denotation (Name) Ambiguity re. de-referencable URIs. A search engine might not initially do much with the Turtle content, but eventually it will pick up an HTML resource derived from said content. Such is the way of the Web. > >> The business case for Linked Data has always started by addressing the >> most basic business needs: >> 1. access to data across disparate data sources... >> 2. conceptual level virtualization of disparate data sources... >> 3. sophisticated integration at the conceptual level... >> 4. sophisticated data access policies... >> 5. effective dissemination... > This does not sound like SME business needs to me but maybe I have a wrong > picture of the number of disparate data sources or the level of sophistication > in SMEs. An SME has to access, transform, integrate, and disseminate data from a broad spectrum of data sources and formats. This has always been the case. The challenge, in these most exponential of times, is all about doing this in the most effective way, relative to competitors, market opportunities, and expectations of stakeholders (employees, shareholders, partners etc.). > >> In the past, there's been a tendency to juxtapose RDF and RDBMS >> technology in manners the infer mutual exclusivity. > And not without reason. Flawed. And you even espoused the very point in your comments. > If you write an application, you want to store and > retrieve your data via *one* (transactional) query language. Otherwise you get > inconsistent data and spaghetti code. It isn't about code. Its about data access, meshing or mashing, dissemination to the right places, on time. In all of this atomicity of transactions is but a tiny piece of the puzzle. Where is the Web's atomicity? As of my last check, it scales awfully fine with no end in sight. > >>> Every one has it's use cases. Some have more, some have less. >> But that doesn't answer my question. I wanted to know if any of the >> items above are useless, for instance. > And my answer was no ("Every one has it's use cases"). Linked Data simply makes all of those things better. Put differently, it enhances those items without mandating their discontinuation. > >>> The RDF/SPARQL/OWL stack has it's use cases and is here to stay. >> But we are talking about usecases at that level. We are discussing the >> issue of Linked Data. Those items (once again) are *distracting* >> implementation details. > I am not discussing the issue of linked data. I am discussing the > RDF/SPARQL/OWL technology stack. I think we are not getting anywhere. RDF, SPARQL, and OWL are exploitable implementations that aid the production and exploitation of Linked Data. Enterprises aren't interested in RDF, SPARQL, and OWL, just because. They are interested in the utility that manifests from increased and intelligent access to disparate data sources modulo any kind of platform lock-in. > > Regards, > > Michael Brunnbauer > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 26 July 2012 15:23:30 UTC