RE: service description discovery

Hi Andy,
I believe OPTIONS can return 200 with content and make it linkable/
bookmarkable by using the Content-location header, for example:

OPTIONS /sparql/ HTTP/1.1
Host: endpoint.example:80


HTTP/1.1 200 OK
Allow: GET, HEAD, POST
Content-type: application/rdf+xml
Content-length: ...
Content-location: ./?description

<rdf:RDF>...


But I gotta add, while I'm a proponent of the use of OPTIONS, I'm being
purely theoretical here, with no implementation experience, and right
now no time to try things out. I can't say how supported the above would
be, though I feel it deserves to be supported and I also feel SPARQL can
practically push it. 8-)

Jacek



On Tue, 2009-09-15 at 10:14 +0000, Seaborne, Andy wrote:
> Another architectural point is whether the description is an Information Resource [1] and so linkable/bookmarkable.
> 
> HTTP OPTIONS (option 2) has a lot of attractions for the reverse proxy case but it isn't working with an Information Resource directly. It could be used to return (303? [3][2]) the URI where the description is.  (Is 303 from OPTIONS legal?  Handled in the wild?)
> 
> 	Andy
> 
> [1] http://www.w3.org/TR/webarch/
> [2] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039
> [3] http://www.w3.org/TR/cooluris/
> 
> > -----Original Message-----
> > From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> > request@w3.org] On Behalf Of Ivan Herman
> > Sent: 15 September 2009 10:07
> > To: Gregory Williams
> > Cc: Alexandre Passant; public-rdf-dawg@w3.org Group
> > Subject: Re: service description discovery
> > 
> > I think one of the problems we also had with option 7 is that if the
> > HTML content and the RDF content returned by the service is not
> > 'identical', than, well, this is not really kosher. Taking into account
> > that a widely implemented practice for SPARQ endpoints is to return an
> > HTML Form for an 'interactive' query, this may raise lots of eyebrows,
> > eg, by the TAG...
> > 
> > Ivan
> > 
> > Gregory Williams wrote:
> > > On Sep 14, 2009, at 5:21 AM, Alexandre Passant wrote:
> > >
> > >> On 11 Sep 2009, at 03:31, Gregory Williams wrote:
> > >>
> > >>> I don't believe we ever got a vote on option 8. Between the other 3,
> > >>> option 7 had the most +1 votes, as well as the highest +1:-1 ratio.
> > >>
> > >> You mean option 2 ?
> > >
> > > I didn't think so, but I suppose I could be wrong. I believe the
> > > preferences I tried to summarize were correct, but I also believe I got
> > > some of the vote counts wrong. This is all based on the chatlog at [1].
> > > At this point, I believe the proper counts are:
> > >
> > > option 1: link header that points to a URI where the service description
> > > can be downloaded
> > >     -1: 2 votes
> > >     0: 9 votes
> > >     +1: 0 votes
> > >
> > > option 2 - use the HTTP OPTION verb on the endpoint URI
> > >     -1: 8 votes
> > >     0: 3 votes
> > >     +1: 1 vote
> > >
> > > option 7 - standard query, using content negotiation to get the service
> > > description
> > >     -1: 5 votes
> > >     0: 1 vote
> > >     +1: 4 votes
> > >
> > > option 8 - new protocol operation (no strawpoll results yet)
> > >     no votes yet
> > >
> > > If you think I've misunderstood the strawpoll results, please to correct
> > > me.
> > >
> > >> It seems to me that the issues raised by Steve with option 8 happen is
> > >> really particular cases - any idea on how often that reverse proxy
> > >> setting happens ?
> > >>
> > >> In addition, all others from the list (besides option 2 ?) also got
> > >> issues:
> > >>
> > >> option 1: link header implies that there is an HTML page at the
> > >> endpoint URL which is not always the case
> > >> option 2: don't see any particular issue here, but I'm wondering how
> > >> easy is that, from a usual Web browser, to send that HTTP OPTION verb
> > >
> > >
> > > As mentioned by others, there's the caching issue to be concerned with.
> > > Also, and I realize this doesn't apply to everyone (depending on
> > > implementation and use cases), I would very much like to see a solution
> > > where I could use the service description URI in a FROM clause with an
> > > implementation that dereferences FROM URIs. This would allow querying of
> > > the service description with either the endpoint in question or with any
> > > other endpoint so long as the FROM URI could be dereferenced. This isn't
> > > possible with option 2 but is possible with options 1, 7, and 8
> > > (possibly involving an extra request to determine what the SD URI is).
> > >
> > > thanks,
> > > .greg
> > >
> > > [1] http://www.w3.org/2009/sparql/meeting/2009-08-18
> > >
> > >
> > 
> > --
> > 
> > Ivan Herman, W3C Semantic Web Activity Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > PGP Key: http://www.ivan-herman.net/pgpkey.html
> > FOAF: http://www.ivan-herman.net/foaf.rdf
>

Received on Tuesday, 15 September 2009 10:58:20 UTC