Re: SPARQL Query Results XML Format

On 18/09/2007, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

> Here is a specific proposal based on  doing queries against
> Ingenuity's knowledge base, very similar in spirit to SPARQL.
>
> <head>
>    <query>SPARQL select ... </where>
>    <endpoint>http://ashby.csail.mit.edu/sparql/</endpoint>
>    <queryparameters>foo=bar&amp;maxresults=10</queryparameters>
>    <when>time when the query was executed</when>
>    <meta> what the "link" would retrieve, possibly enclosed as PC
> data if there are validation issues</meta>
>    ...
>
> Proposal is that all would be optional, so as not to scare people away.

Doesn't sounds unreasonable, the persistence of per-query data at the
end of @link could certainly cause problems in practice. But I wonder
if the same ends could be achieved with lower impact.

> It was not clear to me whether additional xml elements other than the
> ones currently specified can be specified in the body of a sparql
> result. I would [...?]

The SPARQL results format has an XML namespace, so might it make sense
to use foreign-namespace data at least for now, at least until there's
some practical experience? (I assume the spec won't preclude this).

While your proposed elements might be encoded this way, an alternative
could be something like:

<x:metadata x:type="application/rdf+xml" xmlns:x="..." xmlns:rdf="...">
    <rdf:Description rdf:about="">
        ...
   </rdf:Description>
</x:metadata>

- making it easy to draw on existing vocabs and making the metadata
easy to work with.

> At a minimum, allowing the metadata to be embedded in the XML would
> be a good idea. If the current spec precludes additional elements in
> the result XML, then relaxing that would be the first step.  Next in
> priority would be to standardize the element for the query.

Ok, while I suspect there's already a lot can be done using foreign
namespace data, I might as well make a concrete (but speculative)
suggestion:

  * a new element in the SPARQL results namespace to be added,
<metadata>, which MAY appear as a child of <head>
  * a type attribute which MAY appear on that element, the contents of
which SHOULD be an IANA media type (if omitted the contained block
MUST be interpreted as RDF/XML, without the enclosing <rdf:RDF>)

Then
> standardize some attributes like dates and times. Then allow an
> element with vendor specific information.

dc:date, http:HeaderElement etc.

> Lee has pointed out http://lists.w3.org/Archives/Public/public-rdf-
> dawg-comments/2005Jun/0028.html which spurred the addition of the
> link element.
> The problem with this is that, as I point out, it is unlikely that
> implementations would choose to provide long lived metadata which
> would accumulate on a server. This information is such that it is
> known at the time of query and would most effectively be communicated
> in the body of the query results.

Makes sense to me.

Cheers,
Danny.

-- 

http://dannyayers.com

Received on Tuesday, 18 September 2007 09:33:54 UTC