Re: Address Bar URI

Dave Reynolds wrote:
> The problem, as I see it, is that developers start from the NIR but then
> use web browsers to find their way round the data and then cut paste the
> browser locations they find, thus ending up with IRs where they should
> have had NIRs. 

Agree, you put that very nicely Dave.

Perhaps Michael nailed it when he mentioned separation of concerns, one 
could suggest that this is what happens when the data-tier has knowledge 
of the presentation-tier (i.e. punting the user to a view of the data, 
rather than the data directly). That itself is quite possibly the 
product of using a web browser as a data browser.

I think it's fair to say that nothing is going to clean up the mess, so 
perhaps it's just a case of looking at tooling to sanity check our data.

Hugh's javascript would make a fine bookmarklet, click it and it changes 
the URI in the "address bar" to the NIR URI rather than the IR URI 
(assuming a 1-1 relation that is).

Further, surely it must be possible to create a tool which quickly 
sanity checked triples, almost like a semantic web version of Google's 
"did you mean?"

If you write:

  fbase:Italy owl:sameAs <http://dbpedia.org/page/Italy> .

Then any number of checks could be made, for example that the class of 
Country is distinct from the class of Document, perhaps even hooking in 
on the primaryTopic relation.

It's clear after all these years that people will publish data however 
they want, guidance will be ignored, and that humans make mistakes - so 
perhaps we should be relying on machine understanding of our data, to 
correct our very human mistakes. Wherever possible that is :)

Best,

Nathan

Received on Thursday, 20 October 2011 00:19:25 UTC