RE: service description discovery

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:16:26 UTC