Re: Simple Linked Data Publishing For Non Programmers

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

Received on Thursday, 26 July 2012 15:23:30 UTC