W3C home > Mailing lists > Public > public-rdf-wg@w3.org > January 2012

Re: mitigating cost of 303

From: Eric Prud'hommeaux <eric@w3.org>
Date: Wed, 4 Jan 2012 10:41:09 -0500
To: Sandro Hawke <sandro@w3.org>
Cc: David Wood <david@3roundstones.com>, Steve Harris <steve.harris@garlik.com>, "public-rdf-wg@w3.org" <public-rdf-wg@w3.org>
Message-ID: <20120104154108.GD5881@w3.org>
* Sandro Hawke <sandro@w3.org> [2012-01-04 09:38-0500]
> On Wed, 2012-01-04 at 08:59 -0500, David Wood wrote:
> > On Jan 3, 2012, at 20:59, Sandro Hawke wrote:
> > 
> > > On Thu, 2011-12-22 at 13:37 +0000, Steve Harris wrote:
> > >> FWIW I agree with him that a 303 is a very high cost to pay.
> > > 
> > > In confusion or in extra round-trips?
> > > 
> > > I have an engineering solution to the latter, which is that hosts be
> > > allowed to expose (via a .well-known URI) some of the rewrite rules they
> > > use.   Then, if I (as a client) find myself getting lots of redirects
> > > from a host, I could look for this redirect-info file, and if it
> > > appears, I can do the redirects in the client, without talking to the
> > > server.   
> > > 
> > > This wouldn't be only for RDF, but I'd expect only people doing 303 to
> > > care enough to set this up on their hosts or have their clients look for
> > > it.
> > > 
> > > The hardest engineering part, I think, is figuring out how to encode the
> > > rewrite rules.  
> > 
> > Weren't you the editor of RIF in RDF [1]?
> 
> *laugh*   
> 
> I was thinking something more like json:
> 
>         [ { verb: "GET", from: "/r/(.*)", to: "/page/$1", code: 303 },
>           { verb: "GET", from: "(/data/.*/[^.])", to: "$1.rdf", code:
>         303 } ]
>         
> The second rule assumes everything under /data has a form with no suffix
> (no dots in the last segment) that redirects to the same name with .rdf
> appended.
> 
> Doing it in RIF would certainly be an interesting exercise.  (I spent a
> few minutes sketching it now.)  I doubt it would appeal to the target
> audience of http server and client library implementers!

Could try to extend POWDER XML:

  <iriset>
    <includeregex>/r/(.*)</includeregex>
    <redir:path>/path/$1</redir:path>
  </iriset>

which, if you're a keener, has an RDF representation:

  <iriset_1> owl:equivalentClass [
    owl:intersectionOf (
      [
        owl:onProperty powders:matchesregex ;
        owl:hasValue "/r/(.*)"
      ]
      [
        owl:onProperty redir:path ;
        owl:hasValue "/path/$1"
      ] ) .

 - it's POWDER
 + POWDER was hard. no POWDER substitute will be easier.

Of course, a JSON representation of those semantics might be appealing.


>     -- Sandro
>  
> > Regards,
> > Dave
> > 
> > [1] http://www.w3.org/2005/rules/wiki/RIF_In_RDF
> > 
> > 
> > > Each server has its own fancy way of doing it.  Like
> > > which version of regexps, and how to extract from the pattern space;
> > > lots of solutions, but we'd need to pick one.   And, tool wise, one
> > > would eventually like the web servers to automatically serve this file
> > > based on the rewrite rules they are actually using.   :-)
> > > 
> > >   -- Sandro
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 

-- 
-ericP
Received on Wednesday, 4 January 2012 15:41:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:47 GMT