RE: HTTP behaviour for SKOS Concepts

Hi Dan,

Hip hip ...

> hurrah :)

:)

> The text looks good to me. +1 on including it.  I'm not sure the
> SPARQL mention is needed there, it may be more likely that
> the info resource will contain within it description of relevant
> SPARQL endpoints. Do we have enough experience of this bit
> to feel confident encouraging the redirect to be the SPARQL endpoint?

I don't know about experience, but why not?  Otherwise, for hash namespaces,  how does the machine discover a service to query without first downloading the whole lot?

Cheers,

Al.




> 
> Dan
> 
> >How about something like:
> >
> >---
> >
> >    * You MAY use an HTTP URI of any form to name a resource 
> of type skos:Concept.
> >
> >    * If you use an HTTP URI of the form /http:[^#]*$/ (a 
> 'slash URI', e.g. http://slash.example.com/concepts/love) to 
> name a resource of type skos:Concept, then an HTTP GET 
> request SHOULD return a 303 see other (redirect) response 
> code. The agent SHOULD be redirected to an information 
> resource that describes the original resource, that by 
> default returns a response with content type 
> 'application/rdf+xml', that MAY support content negotiation, 
> and that MAY support the SPARQL HTTP protocol.
> >    
> >	* If you use an HTTP URI of the form 
> /http:[^#]+#[^#]+$/ (a 'hash URI', e.g. 
http://hash.example.com/concepts#love) to name a resource of type skos:Concept, then the resource denoted by the URI before the hash (the primary resource, e.g. http://hash.example.com/concepts) SHOULD be an information resource that describes all associated secondary resources, SHOULD respond to an HTTP GET request with a 200 response code, SHOULD return a response with content-type 'application/rdf+xml' by default, MUST NOT support content negotiation, and MAY support the SPARQL HTTP protocol.
>
>---
>
>??
>
>See also AWWW [2].
>
>Cheers,
>
>Al.
>
>[1] http://www.w3.org/TR/swbp-skos-core-guide/#securis
>[2] http://www.w3.org/TR/webarch/
>  
>

Received on Tuesday, 21 June 2005 16:14:49 UTC