[Mulgara-dev] Mulgara 2.0.7 - support for sparql?

[Agustina Martinez]

Hi,

> Example query URL:
http://localhost:8091/sparql/?query=prefix%20dc%3A%20%3Chttp%3A//purl.org/dc/elements/1.1/%3E%20construct%20%7B%20%3Fs%20dc%3Alocation%20%3Fo%20%7D%20from%20%3Chttp%3A//groups.tlrp.org/access/content/group/e0462675-d837-46dd-00b5-403deb2957b7/plant%2520distribution/mygraph.rdf%3E%20where%20%7B%3Fs%20dc%3Alocation%20%3Fo.%7D&format=rdfxml
> For this query, with independance of the specified format, I always
receive
> the results in rdf+xml. If I use n3 for example, the response is still
RDF.

Well, that query finishes with &format=rdfxml. This will always
override an "Accept" header.

I take it that you're saying that when you replace the final parameter
with &format=n3 then you still get RDF/XML in the result?

Yes, you are right, whatever format I use, except for JSON which is OK, I
always receive RDF.
I will try the SVN version, thanks Paul :)


2009/2/3 Paul Gearon <gearon at ieee.org>

> On Tue, Feb 3, 2009 at 3:28 PM, Agustina Martinez <amgcia at gmail.com>
> wrote:
> > Hi again Paul!
> >
> > Sorry for the delay. OK I wil attach two different example queries:
> >
> > - Simple construct query. At the moment I have noticed that only a simple
> > construct query works, i.e. construct with just one property inside. When
> > you try to use more than one property you always get the same error:
> "Cannot
> > construct graphs of X columns"
>
> OK, this isn't a formatting problem, this was another bug that I
> acknowledged last night (in which CONSTRUCT would only work on 3
> column results, and not 3*N). This is now fixed and in Subversion, so
> it will be in 2.0.9.
>
> Nothing is allowed in the Subversion trunk unless all tests are
> passing, so you are safe to get the latest version and use this.
> "Releases" are really just snapshots.
>
> > Example query URL:
> http://localhost:8091/sparql/?query=prefix%20dc%3A%20%3Chttp%3A//purl.org/dc/elements/1.1/%3E%20construct%20%7B%20%3Fs%20dc%3Alocation%20%3Fo%20%7D%20from%20%3Chttp%3A//groups.tlrp.org/access/content/group/e0462675-d837-46dd-00b5-403deb2957b7/plant%2520distribution/mygraph.rdf%3E%20where%20%7B%3Fs%20dc%3Alocation%20%3Fo.%7D&format=rdfxml
> > For this query, with independance of the specified format, I always
> receive
> > the results in rdf+xml. If I use n3 for example, the response is still
> RDF.
>
> Well, that query finishes with &format=rdfxml. This will always
> override an "Accept" header.
>
> I take it that you're saying that when you replace the final parameter
> with &format=n3 then you still get RDF/XML in the result?
>
> Incidentally, spaces in your parameters are usually represented as +
> and not %20. I'm pretty sure that it still decodes the same way, but
> it's unusual to see this.
>
> > - Select query, very simple just to receive all the triples of a graph.
> In
> > this case the only formats working are XML and JSON, when I use n3 or
> RDF, I
> > always receive as output SPARQL XML.
> >
> > Example query: http://localhost:8091/sparql/?query=select %3Fs %3Fp %3Fo
> > from <rmi%3A//localhost/server1%23> where {%3Fs %3Fp %3Fo}&format=rdfxml.
>
> Yes, that is correct and intentional. If you want a graph, then change
> the SELECT to CONSTRUCT.
>
> At the moment the format is always overridden if you choose a graph
> format (rdfxml or n3) for a SELECT query. If you've asked for a graph
> from a SELECT then I could check to see if you have a multiple of 3
> columns and treat the result like a result from a CONSTRUCT query....
> but I believe that would break the SPARQL protocol. I definitely don't
> want to do that, especially when the solution you need is so trivial
> (change SELECT to CONSTRUCT, and wrap the selected variables in
> braces).
>
> So your first bug is fixed, the second I need clarification on, and
> third isn't a bug.
>
> Paul
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20090203/5b66f4d9/attachment.htm>