On 4/12/11 1:52 PM, glenn mcdonald wrote:
You continue to imply that seeing subjectively imperfect data
projected via a data oriented tool is problematic re., your "total
data experience" world view.
I continue to think it's hilarious that you consider it "subjectively
imperfect" that your dataset says Michael Jackson and Michael Rodrick
are the same person. What would constitute "objectively imperfect" to you?
So yes, I think you should feel a little embarrassed about
broadcasting links to a demo in which the very first piece of data one
sees is obviously wrong. You've got billions of entities in dbpedia,
and the technology doesn't care which one you pick, so surely you
could pick one where the errors aren't as prominent. The fact that you
didn't, and don't seem to care, sends a message about your attitude
towards data.
Simple exercise.
Assumptions:
1. an individual (neither you or I) stumbles across one of my demonstrations
2. your characterization of the demo producer (me) is 100% accurate
3. data beholder or consumer seeks to look at the data differently
modulo my "data quality ambivalence" .
Nothing about the DBMS hosting the datasets (where each has a Named
Graph IRI) prevents the beholder or consumer from achieving the
following via the available data access endpoints:
1. Accessing and altering the source query or SPARQL protocol URL -- I
seldom publish a demo where all routes to actual query and data sources
isn't machine and/or human discernible (note the use of footers, <link/>
in <head/> and HTTP response headers in this regard)
2. Adding or removing pragmas re. inference context (owl:sameAs
expansion, invocation of fuzzy InverseFunctionalProperty rules, or
combination of both) as part of the view alteration quest outlined above
3. Viewing original or actual query results via alternative tools that
can process HTTP response payloads -- remember nothing about SPARQL
mandates RDF as sole query results format across SELECT, DESCRIBE, or
CONSTRUCT queries
4. Sharing new query, new result set, new data presentation etc.. via a
URL as part of an evolving conversation about the data in question.
What I outline above lies at the very core of every demo I produce and
the very core of Virtuoso's architecture. The problem in our eyes (at
OpenLink) boils down to dealing with data quality subjectivity at
InterWeb scales, amongst other matters outside the realm of this
particular conversation.
Hopefully, you know, we've already done this entire loop in ODBC, JDBC,
OLE-DB, ADO.NET land eons ago. The limitations inherent in the
aforementioned realms heavily influenced Virtuoso's architecture and as
a result every single demo URL that I share. Note, there is a little
more to every URL I publish. I am most interested in helping people
appreciate URIs as immensely flexible Data Conductors since (in my world
view) Data == New Electricity.
Remember, I do espouse to the mantra: Data is like Wine while
Application code is like Fish. A Good (Cool) URL or URI should be able
to stand the test of time :-)
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
