Hi David,
yes this is a known issue. The underlying problem is that in SPARQL
1.0 there was not clean mechanism to specify a SPARQL end point. This
was left out of the query syntax. However, in many cases it is highly
desirable to be able to write this inside of a query, e.g. in SPIN
rules or other queries that are stored in the model. For these
reasons, I have re-purposed the FROM keyword. However, this is also
not really the correct solution, and some SPARQL end points complain
about this (although they could also just ignore this).
Now, with the upcoming TBC 3.2 the situation is different because
Jena's ARQ engine now has a much cleaner mechanism to specify the
SPARQL end point, using the SERVICE keyword
http://jena.sourceforge.net/ARQ/service.html
For the next TBC release, I have deactivated the FROM work-around and
instead users will be able to use SERVICE (even to mix-and-match
remote queries with other queries - an extremely cool feature, thanks
for Andy Seaborne).
Until then, I am sorry to say there is no work-around.
Holger
On Oct 8, 2009, at 7:57 AM, David Park wrote:
>
> Ok. Great demo on how to use dbpedia as a public sparql endpoint. From
> within TBC, I can
> SELECT *
> FROM <http://dbpedia.org/sparql>
> WHERE {
> <http://dbpedia.org/resource/Washington_Metropolitan_Area> ?p ?o .
> }
>
> Yet when I attempt to many of the other endpoints published in
> http://esw.w3.org/topic/SparqlEndpoints and
> http://www.freebase.com/view/user/bio2rdf/public/sparql , I have no
> success.
>
> I know that some of those endpoints are down or are not returning any
> data, but the ones hosted using D2RQ/Joseki are of interest to me, and
> I've found that any attempt to query one of these sparql endpoints
> results in the message:
> HTTP 400: This service does not allow the dataset to be specified in
> the query
>
> Once I started poking around in Joseki, I discovered that the default
> processor does not allow the user to specify a named graph, whether
> using "FROM" or "FROM NAMED" clauses.
>
> If I have diagnosed this correctly, what is happening is that TBC is
> taking a query such as:
> SELECT ?s ?p ?o
> FROM <http://www4.wiwiss.fu-berlin.de/dailymed/sparql>
> WHERE {
> ?s dailymed:name "cortisone" .
> ?s ?p ?o .
> }
> ORDER BY ?s
>
> And shipping it off, in toto, to the sparql endpoint
> http://www4.wiwiss.fu-berlin.de/dailymed/sparql
>
> Since the SPARQL protocol allows for specifying a named graph using
> the FROM clause, I can understand why TBC would pass this through,
> since the protocol allows for naming graphs, so here are some
> questions:
>
> 1) Is the use of a SPARQL endpoint as a named graph in a FROM clause
> compliant with the W3C recommendation
> http://www.w3.org/TR/rdf-sparql-protocol/?
>
> 2) If so, then since the protocol allows for specifying named graphs,
> and a given SPARQL endpoint could be hosting multiple graphs (not the
> current Joseki implementation, but an OpenVirtuoso implementation,
> perhaps) Wouldn't it be more practical, if TBC wants to allow the user
> to specify the endpoint in the FROM clause to identify the SPARQL
> endpoint then strip it out from the FROM clause?
>
> 3) If not, then shouldn't the TBC SPARQL query widget allow the user
> to specify an endpoint via some other means than the FROM clause?
>
> I am currently on an assignment to assess the usefulness of Semantic
> Web tools. One of the things the company I am on assignment to is
> really excited about is the ability to discover "external information"
> as it relates to their internal information. Since the majority of
> public endpoints currently rely on the D2R/Joseki implementation,
> wouldn't it be in TopQuadrant's best interest to have a means whereby
> one might query these endpoints from within the tool, to demonstrate
> its usefulness outside of the academic graph one might be using
> locally?
>
> Since I cannot do this with TBC, I have to instead rely on custom
> development using Jena or god forbid Python in order to fit this bill.
> I was hoping to show how some quick and dirty SPARQLMotion components
> could snag some awesome data from linkedct, dailymed, drugbank and
> diseasome.
>
> Thanks for your consideration.
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TopBraid Composer Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---
