You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Brandon Sara <br...@collectivemedicaltech.com> on 2021/04/07 03:18:27 UTC

ARQ vs plain HTTP, is one better than the other?

I have a fuseki server that i communicate with remotely. I can use ARQ to
create and send the query via RDFConnection and use ARQ to handling
iterating over the results. I could also just submit an HTTP request and
use something like Jackson to map the resulting JSON-LD to my POJOs. Are
there any advantages to one of these methods over the other (apart from the
APIs that ARQ provides and the ease of using a jackson object mapper)? Is
one method recommended to be used in this situation over the other?
(Perhaps ARQ isn't even intended to be used in this way)

Thanks.

-- 


*NOTICES*:

 

1.  **No PHI in Email**.  Collective Medical policy 
prohibits sending protected health information by email, which may violate 
applicable law. If sending PHI is necessary, please contact me for secure 
delivery instructions.

 

2.  **Confidentiality**.  This message and any 
attachments may be confidential and proprietary. If you received this in 
error, please contact me immediately and delete this message.  



Re: ARQ vs plain HTTP, is one better than the other?

Posted by Andy Seaborne <an...@apache.org>.

On 07/04/2021 04:18, Brandon Sara wrote:
> I have a fuseki server that i communicate with remotely. I can use ARQ to
> create and send the query via RDFConnection and use ARQ to handling
> iterating over the results. I could also just submit an HTTP request and
> use something like Jackson to map the resulting JSON-LD to my POJOs. Are
> there any advantages to one of these methods over the other (apart from the
> APIs that ARQ provides and the ease of using a jackson object mapper)? Is
> one method recommended to be used in this situation over the other?
> (Perhaps ARQ isn't even intended to be used in this way)

RDFConnection gives a Jena/Java API; Models, ways to handled SPARQL 
results. It is not an application object mapper.  So these seem to me to 
be two different use cases; use which works for you.

(which could be autogenerated from say SHACL)

RDFConnectionRemote uses standardises SPARQL protocols and works with 
any SPARQL-compliant server.

There is a special for Fuseki - same API - which uses binary encoding. 
Functionally the same; a bit more efficient.


HttpOp has operations to do the protocol part and hand back a stream 
that can be fed into Jackson or anything else. It is intended to be 
easier to use for common cases for semweb applications than dealing with 
the JDK or Apache HttpClient HTTP APIs directly.

Now we are on Java11, the HTTP networking in Jena can be 
evolved/upgraded. Java11 HTTP is a complete replacement with HTTP/2 
support, async I/O and a beautiful API.

But. JSON-LD generated from RDF without framing can be a bit uck and 
unpredictable as the data changes.

     Andy

> 
> Thanks.
>