RE: Discovering service descriptions

> Option 1 - HTTP-Header

OK.

Extra round trip in some situations.  But "ASK {}" is usually cheap and it opens the connection so next time it's ready.

Variation: location is another SPARQL endpoint loaded with the description ready to be queried.  Descriptions might get quite large when including lots of detail about the data available.

> Option 2 - HTTP OPTIONS

OK.  Similar comments to the above.

Does this include content negotiation taking place?

> Option 3 - Well-known location

Don't want.  Don't like enforcing naming issues like this.

> Option 4 - DESCRIBE <sparql.endpoint.url>

Don't want.  It's in the query.

As well as affecting the info in the store, the service description is a property of the service, and not of the query engine.  A service associates the data to be queried with the query engine. The query engine might well be used across several service endpoints so would have to have more information than currently to handle in-query forms.  Making the mechanism part of the query engine(and query language) feels to me like a mismatch that will lead to trouble.

> Option 5 - Query

Don't want.  It's in the query.

> Option 6 - DESCRIBE_ENDPOINT

Don't want.  It's in the query.

> Option 7 - Conneg

OK.

----

Variant (a bit of a cross between 2 and 3): add a new request parameter to ask for the service description (including content negotiation).  Sort of like (2) but moves the handling firmly into the service code.

http://example/service?servicedescription


Not keen but can live with.  Option 7 seems better.



>  From what I've heard in conversations so far, I think that 2 - HTTP
> OPTIONS, 3 - Well-known location, and 5 - Query all lack strong support
> from anyone. Please correct me if I'm wrong.

I can live with option 2.

> 
> Of the remaining options, 1 - HTTP Header and 7 - Conneg both are
> "protocol-level" operations. They each seem to be somewhat specific to
> HTTP, though I'm guessing there'd be a moral equivalent for things like
> SOAP. They definitely lend themselves easily enough to equivalents via
> an API (myEngine.getServiceDescription() ? :-) ).
> 
> The other options, DESCRIBE <endpoint> and DESCRIBE_ENDPOINT, are
> "query-level" operations. Some people have expressed concerns that
> DESCRIBE <endpoint> (or its cousin, DESCRIBE <>) constrains what
> information the store can actually contain, and it also seems to me that
> it requires that the endpoint actually have a URI in the first place,
> and that the caller know that URI (not necessarily the case in an API
> environment, though there are non-standard ways to get at service
> descriptions in those cases, as above, I guess).
> 
> Any thoughts / opinions?
> 
> Lee


On SOAP (minor):

Adding a new request operation on an endpoint might be more SOAP-style: this could be done for HTTP e.g.

(so that's Option 8).

http://example/service?servicedescription.


It's very like "GET http://example/service" (option 7) returning a graph but might fit the SOAP world if we wanted one WSDL description for HTTP and SOAP.

On balance, I don't like distorting the HTTP mechanism to fit SOAP and prefer to develop them in parallel with the same style, but not using the same WSDL (if WSDL at all for HTTP) if we distort the design just to get that.

 Andy

Received on Monday, 10 August 2009 13:48:03 UTC