W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2005

Re: construct starting to feel like a separate interface

From: Kendall Clark <kendall@monkeyfist.com>
Date: Mon, 9 May 2005 10:31:46 -0400
To: Dan Connolly <connolly@w3.org>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20050509143146.GA24435@monkeyfist.com>

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:element ref="xrf:sparql"></xs:element>
                <xs:element ref="rdf:RDF"></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>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:47 UTC