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