Re: 15 Ways to Think About Data Quality (Just for a Start)

On 4/12/11 3:25 PM, glenn mcdonald wrote:
>
>     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 tried clicking your "OpenLink Data Explorer" link to do this, and 
> got a page with broken graphics and a frozen "loading.." indicator. 
> Tried again and got to a Data Explorer page that says "0 records (0 
> triples, 0 properties) match selected filters. Nothing to display. 
> Perhaps your filters are too restrictive?" So I'd say "something" is 
> preventing the beholder from achieving this.

Please post the URL in question so I can double check what's happening. 
Remember, I am sharing URLs across the Web, there are many factor in 
play re. time variant nature of resources. etc..

Anyway, give me a URL and I can look into what might be happening.

>
>     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
>
>
> I went to the Settings page to check this out, and found the 
> "owl:sameAs" toggle. Of course, it's unchecked, despite all those 
> sameAs relationships showing up, and when I check it they go away, so 
> you've wired the setting backwards. Nice job.

To you, I've wired the setting backwards i.e., I opted not to impose the 
overhead of owl:sameAs union expansion by default. Overhead in this case 
also includes what's ultimately your prime gripe: an unrepresentative 
graph since the union is comprised of attribute=value pairs from 
individuals that aren't the same.

Methinks, the defaults are fine. Worst that happens (without addition 
overhead) is you click a value exposed via a broken owl:sameAs relation. 
The system doesn't reason unless you ask it to do so explicitly.

Your world view != mine. Thus, don't try to impose *your* information 
expectations on *my* information projections. You can always make a 
different view. That's why loosely coupling information and data is vital.

>
>
>     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.
>
>
> These are great. I support HTTP access, multiple formats, and 
> URL-addressable queries/results/views.

But you have a "silo". The day you deliver Objects with IDs that resolve 
to their Representations via URLs is the day I'll drop the "silo" tag 
re. your data space :-)

>
>     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 :-)
>
>
>  Catchy.

Yes, catchy cos it will catch on, courtesy of the burgeoning Web of 
Linked Data.


-- 

Regards,

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