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
