W3C home > Mailing lists > Public > public-lod@w3.org > October 2011

Re: Address Bar URI

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 14 Oct 2011 13:59:56 -0400
Message-ID: <4E98789C.1050008@openlinksw.com>
To: public-lod@w3.org
On 10/14/11 1:38 PM, Rob Styles wrote:
> This redirection and the resulting address of a web page, rather than 
> the name of the real-world thing originally requested, is one of the 
> reasons I believe the IR/NIR distinction is problematic in practice.
>
> If we overturned httpRange-14 and allowed a non-information resource 
> (i.e. a URI naming a real world thing) to return a 200 OK and a 
> representation of itself then your client-side address bar 
> manipulation would be unnecessary.

I don't think over turning httpRange-14 is the solution. The problem 
with httpRange-14 is that it has chosen to explain data objects 
(resources), identifiers (e.g., names and addresses), and indirection 
(implicit or explicit) in an esoteric way.

>
> In practical experience training and mentoring many developers and 
> data hackers new to Linked Data this is one of the most problematic areas.

Yes!

I encourage you to negate httpRange-14, and build on existing anecdotes 
(you have some of that material already) re. history, use, and 
characteristics of identifiers.

As you know, It just so happens that URI abstraction enables some really 
powerful stuff (e.g., Linked Data) to happen re., data representation, 
access, integration, and management, when combined with EAV/SPO based 
structured data.

Kingsley
>
> rob
>
> Rob Styles
> Senior Technical Consultant
> http://consulting.talis.com/rob-styles
>
>
>
>
>
> On 14 October 2011 17:03, Hugh Glaser <hg@ecs.soton.ac.uk 
> <mailto:hg@ecs.soton.ac.uk>> wrote:
>
>     Thanks, yes.
>     It is client side JS, not a complicated server-side.
>     It won't work for the purposes I describe if the Linked Data
>     publisher has chosen (or had to) have the document on a different
>     domain, but for all the cases I can quickly think of it does.
>
>     Of course it won't work if window.history.replaceState is not
>     available, but that can be tested for (Ian says).
>     It is a bit undesirable that the "old" way, as it will become (!)
>     should persist for the old browsers, but that is the Way of the Web.
>     Best
>
>     On 14 Oct 2011, at 16:40, David Wood wrote:
>
>     > Hi Hugh,
>     >
>     > Sorry, I think we are talking about different ways of
>     accomplishing the same thing.  You seem to be suggesting that the
>     user's browser rewrite the URL in the address bar to match the URI
>     you want to see.  This is completely client-side approach.  As you
>     said, you can do that if you don't change the domain or protocol
>     (because if you did, it would be a security nightmare).  That
>     seems fine to me.
>     >
>     > Another way to do this is to have the server rewrite the URI,
>     using redirection and/or server-side URL rewriting.  That's where
>     my earlier comments came in: A server needs to have enough
>     knowledge to re-write a URL properly after a redirection.
>     >
>     > Your browser tests tested your client-side scenario, but the
>     server-side scenario is more complicated.
>     >
>     > I hope that helps.
>     >
>     > Regards,
>     > Dave
>     >
>     >
>     >
>     >
>     > On Oct 14, 2011, at 11:27, Hugh Glaser wrote:
>     >
>     >> Thanks.
>     >> I have just tried it on my mac with
>     >> Firefox, Chrome, Safair, Flock and Opera.
>     >> All seem to do it fine, although obviously I am running the
>     latest versions.
>     >> Ian Millard has modded rkbexplorer.com
>     <http://rkbexplorer.com>, so you can try:
>     >> http://southampton.rkbexplorer.com/id/person-04860
>     >> It goes to
>     http://southampton.rkbexplorer.com/description/person-04860
>     >> and then shows
>     >> http://southampton.rkbexplorer.com/id/person-04860
>     >> again.
>     >> (You do need to wait until the page has finished loading.)
>     >> I don't know what the failure mode is on older browsers or
>     buggy ones.
>     >>
>     >> But for these it looks good to me.
>     >> But as you say, if there is other stuff going on too, things
>     may break.
>     >> Best
>     >> Hugh
>     >>
>     >> On 14 Oct 2011, at 16:11, David Wood wrote:
>     >>
>     >>> Hi Hugh,
>     >>>
>     >>> I like what you are saying and agree that this approach would
>     be a real boon to the LOD community.  Practical problems with
>     using it are likely to be with subtleties of browser implementation.
>     >>>
>     >>> For example, Firefox resets all headers on redirect, including
>     the Accept: header which causes us difficulty with PURL redirects.
>      This is a known issue in Firefox and has been unfixed for four years:
>     >>> https://bugzilla.mozilla.org/show_bug.cgi?id=401564
>     >>> The test page can be found here:
>     >>> http://tc.labs.opera.com/apis/XMLHttpRequest/send-redirect.htm
>     >>>
>     >>> I recall a similar bug report on Firefox where Mozilla
>     developers were discussing how the address bar contents should be
>     modified, and there was violent disagreement.  Unfortunately, I
>     can't put my hands on that URL at the moment, but I think you get
>     my point: Each browser vendor will decide to handle these things
>     differently in the absence of a standard (or in the presence of
>     cross-site abuse concerns).
>     >>>
>     >>> The best way to proceed is probably to try it and test all
>     major browsers.
>     >>>
>     >>> Regards,
>     >>> Dave
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> On Oct 14, 2011, at 10:22, Hugh Glaser wrote:
>     >>>
>     >>>> Excellent, hopefully that is out of the way.
>     >>>> Does anyone want to express an opinion on the original
>     question, which boils down to:
>     >>>>
>     >>>> "Is there a problem if going to URI
>     http://www.myexperiment.org/workflows/158 (say, by clicking) in a
>     browser then shows http://www.myexperiment.org/workflows/158 in
>     the address bar for the page it displays?"
>     >>>>
>     >>>> I suggest not.
>     >>>>
>     >>>> It does bring one further question (at least):
>     >>>> What do you display if someone goes to
>     http://www.myexperiment.org/workflows/158.html?
>     >>>> Possibly more controversial, as I suspect that the pragmatic
>     answer is to display
>     >>>> http://www.myexperiment.org/workflows/158
>     >>>>
>     >>>> Best
>     >>>> Hugh
>     >>>>
>     >>>>
>     >>>> On 14 Oct 2011, at 14:23, Ian Davis wrote:
>     >>>>
>     >>>>> On Fri, Oct 14, 2011 at 2:15 PM, Kingsley Idehen
>     <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>     >>>>>
>     >>>>>
>     >>>>> Yes, opaque technology to you. Luckily, not for the rest of
>     the computing universe.
>     >>>>>
>     >>>>> The large number of off-list messages supporting my view
>     seems to provide evidence to the contrary.
>     >>>>>
>     >>>>> Apologies to the list for this off-topic conversation. I
>     won't prolong it.
>     >>>>>
>     >>>>> Ian
>     >>>>
>     >>>> --
>     >>>> Hugh Glaser,
>     >>>>           Web and Internet Science
>     >>>>           Electronics and Computer Science,
>     >>>>           University of Southampton,
>     >>>>           Southampton SO17 1BJ
>     >>>> Work: +44 23 8059 3670 <tel:%2B44%2023%208059%203670>, Fax:
>     +44 23 8059 3045 <tel:%2B44%2023%208059%203045>
>     >>>> Mobile: +44 75 9533 4155 <tel:%2B44%2075%209533%204155> ,
>     Home: +44 23 8061 5652 <tel:%2B44%2023%208061%205652>
>     >>>> http://www.ecs.soton.ac.uk/~hg/
>     <http://www.ecs.soton.ac.uk/%7Ehg/>
>     >>>>
>     >>>>
>     >>>>
>     >>>
>     >>
>     >> --
>     >> Hugh Glaser,
>     >>             Web and Internet Science
>     >>             Electronics and Computer Science,
>     >>             University of Southampton,
>     >>             Southampton SO17 1BJ
>     >> Work: +44 23 8059 3670 <tel:%2B44%2023%208059%203670>, Fax: +44
>     23 8059 3045 <tel:%2B44%2023%208059%203045>
>     >> Mobile: +44 75 9533 4155 <tel:%2B44%2075%209533%204155> , Home:
>     +44 23 8061 5652 <tel:%2B44%2023%208061%205652>
>     >> http://www.ecs.soton.ac.uk/~hg/ <http://www.ecs.soton.ac.uk/%7Ehg/>
>     >>
>     >>
>     >>
>     >
>
>     --
>     Hugh Glaser,
>                  Web and Internet Science
>                  Electronics and Computer Science,
>                  University of Southampton,
>                  Southampton SO17 1BJ
>     Work: +44 23 8059 3670 <tel:%2B44%2023%208059%203670>, Fax: +44 23
>     8059 3045 <tel:%2B44%2023%208059%203045>
>     Mobile: +44 75 9533 4155 <tel:%2B44%2075%209533%204155> , Home:
>     +44 23 8061 5652 <tel:%2B44%2023%208061%205652>
>     http://www.ecs.soton.ac.uk/~hg/ <http://www.ecs.soton.ac.uk/%7Ehg/>
>
>
>
>


-- 

Regards,

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






Received on Friday, 14 October 2011 18:00:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:21:17 UTC