Hi David,
David Huynh wrote:
Hi Mike,
Well put! It's an accurate account of what's going on. As I explicitly
said in my original post, this was more or less a tease and shameless
self-promotion :-), but hopefully beneficial, as there are, in my
opinion, some interesting ideas from this query editor that can be
adopted / adapted. In fact, if you watch the screencast again, there
might be hints of "data driving interfaces", albeit only for developers,
not end-users. What other major wins at no cost are you seeing?
OK; I'm game. This is a list Fred and I have not published before
for "major wins":
1. Context-specific autocompletion
2. Context-specific dropdown lists
3. Instance record previews
4. Class (concept) previews
5. Instance record details
6. Class (concept) details
7. CRUD actions on all items (depending on authorization/access
rights)
8. Label viewing/selection v IRIs
9. Item look-up/search (contextual, via label or IRIs)
10. Synonym/alias matching ("semsets") or lookup
11. Easy internationalization (viz labels)
12. Automatic inferencing
13. What's related lookup
14. More specific/more generic lookups
15. Local graph visualization
16. Full linkage navigation (linked data)
17. Contextual, directed work flows (query building, template
building/selection, analysis, etc)
18. Contextual tooltips/popups
19. Contextual help
20. Dataset-level access and scope.
I saw a few of the above in your system. I especially like your
syntax tolerance, interactive tree ("one-by-one"), and "inside
out" ideas. Very clever.
There are many reasons why we think RDF the superior choice for
all of these purposes [1].
In our own work, we also give great care to the separation of
instances and their records (ABox) from conceptual schema (TBox),
which, when using the same techniques above, also provides highly
useful contextuality and targeted selections. For example, as a
teaser, all instance types can be classified into discrete,
disjoint "supertypes" that greatly aid disambiguation or display
template selection [2].
These reasons are why we describe our stuff as "data-driven
applications". Generic tools incorporating the ideas above can
be contextually driven through simple swap outs of ontologies and
domains. Indeed, ontology(ies) are what *actually* drives the
system.
IMO, from a consumer perspective, Fred's query builder when at
Zitgist was the best I have seen [3]. That was two years ago,
and we never commercialized it, but have taken some of those
ideas forward with our current stuff.
We have no issue with JSON as a naive authoring environment or
for data exchange. Indeed, we view it as often superior to
straight RDF.
But, our internal, canonical representations are RDF as
structured and organized above because we get all of these
data-driven interface advantages "for free". We further can
avoid all of the SEO problems of client-side JSON, a concern of
mine going back to early work with the deep Web.
I'd be interested in your or others' similar ideas.
Mike
[1] http://www.mkbergman.com/?p=483
[2] For example, see references to BBN or Sekine in
http://en.wikipedia.org/wiki/Named_Entity_Recognition
[3] http://www.zitgist.com/products/query_builder.html
David
Mike Bergman 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
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 <[email protected]
<mailto:[email protected]>> 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
