Re: construct starting to feel like a separate interface

On Fri, May 06, 2005 at 01:05:49PM -0500, Dan Connolly wrote:
> 
> I'm working on sparcli.py , playing with various
> services out there; one of the options is...
> 
>     elif '--sparqlette' in sys.argv:
>         BG='data'
>         svcAddr =
> 'http://www.wasab.dk/morten/2005/04/sparqlette/?format=xml&'
> 
> i.e. I'm trying to look at the SPARQL interface as something
> that doesn't have a format= param, but sparqlette has
> a format param, so I'm trying to "hide" it in the service
> address.
> 
> That works for SELECT and ASK, but not for CONSTRUCT.
> 
> I'm starting to wonder if ?query=... should be
> separated into ?select=... and ?construct=... or
> something.

Another reason to move CONSTRUCT into a separate interface is
simplification of outputs. That is, the type of the Out Message of
SparqlQuery.query and SparqlQuery.queryx (as of the latest published
draft -- these interfaces are changing per our last telecon) looks
like this:

    <xs:element name="query-result">
        <xs:complexType>
            <xs:choice>
                <xs:element ref="xrf:sparql"></xs:element>
                <xs:element ref="rdf:RDF"></xs:element>
            </xs:choice>
        </xs:complexType>
    </xs:element>

I believe that by moving CONSTRUCT to a separate interface (well, I
would move it into two separate interfaces: SparqlConstruct and
SparqlConstructX), the "query-result" type would become:

    <xs:element name="query-result">
        <xs:element ref="xrf:sparql"></xs:element>
    </xs:element>

Which is considerably simpler and, well, more elegant, IMO. It's also
symmetrical with the interface specialization on In Message (string
versus XML forms of the query language).

I'm convinced enough to produce a draft with CONSTRUCT separated from
other query forms.

Kendall Clark

Received on Monday, 9 May 2005 14:32:53 UTC