Re: ISSUE-91, ISSUE-92: Should the RDF API have a query() that is capable to send SPARQL requests to remote endpoints

Benjamin Adrian wrote:
> Hi,
> 
> Here are six reasons for adding an overloaded rdf.parse(SparqlEndpoint,
> query) method that returns a Graph object as result.

aside: there is no rdf.parse method to overload, DataParser is just an 
interface anybody can implement, unattached to any other interface in 
the API.

> 1. If you request data about a single subject and request the subject's
> URI for RDF data, Linked Data leaves it open to data providers what
> triples to return. For example DBpedia won't give you all triples it
> knowns about a subject, when requesting it's URI. By using SPARQL queries,
> you will receive all the triples you want to have.

A fair point, but I don't see that being a reason to add it to the API, 
rather just a use case where it can be more efficient to use a sparql 
query (which the API could handle the results from if CONSTRUCT or 
DESCRIBE) - so I agree useful (of course) but can't see why that should 
be required RDF API functionality?

> 2. In cases where a data provider publishes its RDF data just as a single
> RDF document, you have to parse the whole document on your own to get the
> 10 triples you are interested in. A SPARQL query allows you to define a
> pattern to just receive these 10 triples.

That's if the you know an endpoint aforehand for that contents of that 
document without looking at the document to find the endpoint ya? (else 
you've parsed it anyways). I agree, again useful, but requires all that 
out of band knowledge, and essentially a sparql interface. Further, the 
RDF API already allows filtering when you parse, and processing for 
async sax like parsers. Both of which are viable solutions to this use case.

> 3. I don't want to parse huge RDF data in Javascript within my browser.
> The Browser would just produce a message that a Javascript script runs too
> long and hence it would ask me to stop this script.

I agree that it perhaps wouldn't be optimal to parse huge RDF documents 
in the browser in a locking script. However, saying that, both Dan 
Brickley and myself have made RDF crawlers/scutters which ran in the 
browsers without locking at decent speeds and without having any 
noticable impact on the machine, so it certainly can be done. Further, 
the API can be implemented using WebWorkers in the browsers. further 
still, the API isn't just for browser usage, for instance my own 
implementation is for node.js or browser, and Gavin Carothers is in Python.

> 4. A SPARQL query is nothing more than a single HTTP request. I
> implemented hundreds of these requests by using JQuery and JSONP. Each of
> it gave me a feeling of having just created a painful hack. By providing a
> simple overloaded rdf.parse method, we would create a clean solution on
> this problem.

Okay, I fully agree that SPARQL support (both remote, and a local sparql 
implementation) would be most useful, but why overload the (non 
existent) .parse method when either a separate interface could be 
defined, or an entirely new set of interfaces depending on the level of 
support.

All we're talking about here is a simple function(endpoint, query) 
method somewhere on some interface. I see no reason to make the RDF API 
require SPARQL support either local or remote, and see it as being an 
extremely easy hit to define, as in it could simply be an example in a 
primer or non normative text or a note or suchlike, if we mention it all.

> 5. This method does not mean to support sparql in our RDF API. It just
> adds a standard way to send SPARQL queries to a remote endpoint and
> process the results directly in our API. This would just take me a single
> line of code.

I personally don't mind the method being added, but would /really/ want 
it to not be an overloading of DataParser.parse, and rather it be a 
different interface, or as mentioned earlier, covered later when we have 
a series of such convenience methods, possibly to create an end user 
focussed simple API, or possibly as a nice interface which extends or 
augments the RDFEnvironment with this functionality.

Would you be happy with that?

> 6. Whenever I built an RDF mashup, I was not interested to aggregate all
> existing  information about a set of subjects. In fact I am interested in
> adding just some data about these subjects. For example, give me the names
> and parties of all US presidents.
> 
> In my understanding of an RDF API that facilitates developing RDF
> applications in a browser, adding this query support stays within the
> scope of this API. :)

Is that the goal of this API though? certainly that was the goal of the 
RDFa API, and would be of generic end user API, or a linked data API, 
but the RDF API, this one?

General note: I'm aware of how I may be sounding here, but really I'm 
very positive towards all these suggestions and want them myself too, 
just not in this API, on this layer, in this phase - later (but 
hopefully soon) in a nice developer centric RDF/LinkedData API, that's 
if one is deemed needed and we don't just get the functionality in our 
libs anyway.

Best,

Nathan

Received on Thursday, 21 April 2011 22:43:20 UTC