W3C home > Mailing lists > Public > public-lod@w3.org > April 2009

Re: "humane" query editors for the data web?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 22 Apr 2009 23:36:20 -0400
To: Mike Bergman <mike@mkbergman.com>
CC: <public-lod@w3.org>
Message-ID: <C6155A74.10493%kidehen@openlinksw.com>

On 4/22/09 10:24 PM, "Mike Bergman" <mike@mkbergman.com> wrote:

> This has been a classic case of Cool Hand Luke and a failure to
> communicate.  Indeed, it happens all of the time in this forum.
> David comes from a perspective of usability and user interfaces,
> granted with a JS bias.  Most all of us have recognized his
> genius for quite some time, and he is a leading innovator in such
> data presentation.
> Kingsley has been a passionate advocate for data connectivity and
> overcoming all things "silo".  Middleware is his game (and OL's).
>   Data and manipulating data is his perspective, and we know the
> superior infrastructure that his personal and then corporate
> commitments to these issues have brought.
> Benjamin notes today the difference in perspective.  Does it
> begin with the user experience, or does it begin with the data?
> The answer, of course, is Yes.
> David with JSON and MQL and other things FB might be criticized.
>   As he knows, I have done so personally offline and directly.
> Kingsley might be criticized for facile hand-waving at UI and
> usability questions; he, too, knows I have made those points
> privately.
> I truly don't know what our "community" really is or, if indeed,
> we even have one.  But I do know this:
> All of us work on these issues because we believe in them and
> have passion.  So, I have a simple suggestion:
> Keep looking outward.  We need to talk and speak to the
> "unaffiliated".  In that regard, David has the upper hand because
> presentation and flash will always be easier to understand for
> the non-cognescenti.  But, David, you know this too:  your job is
> easier if the nature of the data and its structure drives your
> display.
> There are HUGE, HUGE advantages of data driving interfaces and
> usability that neither of you are discussing.  Let's next turn
> our attention there and gain some major wins at no cost.
> Mike


First part of this response is to the LOD community in general:

There is a fundamental point that permeates all my communications about UI
and Data Access, and the more recent realm of Linked Data. It simply comes
down to this:

Data Presentation, Data Representation, Data Access, and Data Storage are
all distinct items. Each of these realms is a domain of expertise in its own

What Linked Data really and truly addresses is the ability to abstract
these distinct realms via HTTP based URIs that deliver the "*"
(reference/name) and "&" (address/location) of the 'C' programming language
(simple anecdote) in a manner that truly transcends platforms due to the
Web's ubiquity.

I've already completed one iteration of the standards compliant data access
and application binding via ODBC, JDBC, OLE-DB, and ADO.NET etc.. but these
approaches all suffered from the pain of data access specific protocols and
representations (XDR hell) albeit encapsulated in the Driver implementation
work. Even worse, ODBC/JDBC/OLE-DB/ADO.NET compliant applications all
suffered from presentation layer specificity (each App has their own prior
to the emergence of HTML and XML+XSLT+CSS), so you had to buy a Report
Writer package (or similar desktop productivity tool) to get decent
presentation from your DBMS independent data access driver etc..

The point I am trying to make above is this: ODBC Drivers development and
ODBC compliant application development were/are distinct activities with
distinct specializations. And although these platform specific and DBMS
model specific APIs have issues (as outlined above), the do unveil a very
important virtue that the Linked Data community can only benefit from i.e.,
know your area of expertise, and maximize it by channeling your effort to
the relevant side of a  critical standard.

Taking OpenLink as an example, we can truly do many things, but our
strategic focus is data access middleware and data management. That's what
the company has been equipped to do very well since  inception. What we
aren't really equipped to do, but have been forced into, as part of an
effort to contribute to Linked Data Web bootstrap, is full blown UI
development.  ODE, iSPARQL, OAT, and the rudimentary UI around the very
powerful ODS platform are current examples.

What I would like to see more of in this community, is the coalescing of
talent around areas of core competence. This is how we will truly produce
coherent game changing output.
We have a standard, its called: Linked Data, much simpler than ODBC, JDBC,
etc.. And a zillion times more powerful, so lets not impede outbound
progress by a bizarre inability work together coherently, all we have to do
is work either side of the standard (as stated already).

For those who think real collaboration isn't possible in this realm, along
the lines I espouse, do note this fact: there isn't a single company on this
planet that could digest a modicum of the potential of Linked Data (we are
dealing with a fractal space), so we aren't in a zero sum competitive
marketplace, the cake is simply too BIG! Thus, co-opetition (as articulate
by Ray Noorda eons ago) and symbiosis are going to be the defining hallmarks
of all Linked Data oriented markeplaces as we move forward.


Thanks for your comments, you've provide a nice outlet for me to express
some of my pressing concerns re. our community --- I do believe we have one



Kingsley Idehen          Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

> David Huynh wrote:
>> Kingsley,
>> Thanks for the resources and the detailed explanation! Looks like all
>> the pieces are there!
>> David
>> Kingsley Idehen wrote:
>>> David Huynh wrote:
>>>> Thanks for the link, Juan.
>>>> Just curious, even if I know SPARQL, how do I (as a new user) know
>>>> which properties and types there are in the data? And what URIs to
>>>> use for what?
>>> David,
>>> Not speaking for Jaun, but seeking to answer the question you posed.
>>> Our iSPARQL interface takes the view that:
>>> 1. You lookup vocabularies and ontologies of interest before
>>> constructing triple patterns since the terms need to come from somewhere
>>> 2. You then you use the ontology/vocabulary tree to drag and drop
>>> classes over Subject  and Object nodes
>>> 3. Do the same thing re. properties by selecting them and dropping
>>> them over the connectors (predicates)
>>> 4. Repeat the above until you've completely painted an SPO graph of
>>> what you seek.
>>> BTW - the pattern in steps 2-4 above originated from RDF Author, and
>>> we simply adopted it for SPARQL (following a skype session I had with
>>> Danbri years ago re. the need for SPARQL QBE). Note: RDF Author
>>> allowed you to write Triples directly into RDF information resources
>>> via their URLs. Which means the same UI works fine for SPARUL (writing
>>> to Quad Store via its internal Graph IRI or Web Information Resource
>>> URL).
>>> Links:
>>> 1.  http://rdfweb.org/people/damian/RDFAuthor/Tutorial/ -- RDF Author
>>> Kingsley
>>>> David
>>>> Juan Sequeda wrote:
>>>>> You may want to check out a tool that we are working on: SQUIN
>>>>> http://squin.informatik.hu-berlin.de/SQUIN/
>>>>> Juan Sequeda, Ph.D Student
>>>>> Dept. of Computer Sciences
>>>>> The University of Texas at Austin
>>>>> www.juansequeda.com <http://www.juansequeda.com>
>>>>> www.semanticwebaustin.org <http://www.semanticwebaustin.org>
>>>>> On Wed, Apr 22, 2009 at 9:18 PM, David Huynh <dfhuynh@alum.mit.edu
>>>>> <mailto:dfhuynh@alum.mit.edu>> wrote:
>>>>>     Hi all,
>>>>>     Admittedly this is somewhat of a tease and shameless
>>>>>     self-promotion :-) but I think there are a few interesting
>>>>>     concepts in the query editor for Freebase that I've been working
>>>>>     on that can be very useful for querying and consuming LOD data
>>>>> sets:
>>>>>       http://www.freebase.com/app/queryeditor/about
>>>>>     Or maybe I missed it totally--is there anything similar for
>>>>>     writing SPARQL queries over LOD?
>>>>>     Cheers,
>>>>>     David
Received on Thursday, 23 April 2009 03:37:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:20:46 UTC