Why did Clark&Parsia create SNARL (instead of just contributing extensions to Sesame)?

[pat.mc...@gmail.com]

I can't seem to find a definitive explanation for *why* SNARL was developed!? 

Obviously it builds directly on top of Sesame, so why didn't Clark&Parsia just work with native Sesame and contribute things like SNARL's 'Getter's to the Sesame codebase rather than go off and define a proprietary API by themselves?

Maybe I'm missing something obvious, but I've only just begun looking at StarDog. I was originally trying to decide between using Sesame or Jena, or attempting to abstract away from both in case I switch later (which is how I came across SNARL in fact!!).

Any pointers would be appreciated, thanks!

Pat.

 

[Mike Grove]

On Wed, Jul 24, 2013 at 8:53 AM, <pat.mc...@gmail.com> wrote:

I can't seem to find a definitive explanation for *why* SNARL was developed!? 

It's unclear whether you're referring to the SNARL API or the SNARL protocol, I think you're referring to the API, but I'll address both.

The SNARL protocol was created because we wanted a binary protocol alternative to HTTP which in some use cases, provides lower latency.

We created the SNARL API because we wanted an API that was built *for* Stardog.  We have a lot of functionality that is not covered by the Sesame (or Jena) APIs such as search, reasoning, and ICV that required API support.  Had we decided to extend another API, we still would have needed to create a lot of new interfaces to support our needs.  We also needed an API we controlled; we can't really be hand-cuffed by someone else's release cycle when we need to make changes to 'our' parts of their API.

 

Obviously it builds directly on top of Sesame,

We do provide custom implementations of their Model API (Graph, Statement, Literal, etc) and their query result sets (TupleQueryResult & GraphQueryResult) because there's no need to reinvent the wheel for that stuff and what they have is fine for our needs, but I don't think it's correct to say we build on top of Sesame.

so why didn't Clark&Parsia just work with native Sesame and contribute things like SNARL's 'Getter's to the Sesame codebase rather than go off and define a proprietary API by themselves?

I've explain our motivated for creating an API for *our* product.

We have also contributed significants amount of code back to the Sesame codebase; useful non-Stardog bits of functionality that started out in our open-source Sesame utility library.

 

Maybe I'm missing something obvious, but I've only just begun looking at StarDog. I was originally trying to decide between using Sesame or Jena, or attempting to abstract away from both in case I switch later (which is how I came across SNARL in fact!!).

If you don't like the SNARL API, Stardog provides implementations of the end-user APIs for both Sesame and Jena, so you can use Stardog as a drop in replacement in any existing Sesame or Jena based application.

Cheers,

Mike

 

Any pointers would be appreciated, thanks!

Pat.

 

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en
 
 

[pat.mc...@gmail.com]

Great stuff Mike - thanks for the (very fast!) feedback.

I'd suggest a short paragraph in the StarDog documentation though, just reiterating what you say above. It's just that when I came across 'yet another' acronym such as SNARL (when I'm already having to digest RDF, RDFS, OWL, DC, FOAF, SPARQL, SerQL, Sesame, JENA, models, graphs, resources, etc., etc.) it would have been useful to know exactly why this one exists amongst that pantheon of acronyms and APIs (and sorry, yes, my question was about SNARL the API).

Thanks again,

Pat.

[Kendall Clark]

Pat,

Thanks for the feedback.

I think this API thing is pretty simple: we support the 2 main Java APIs and added a third because Stardog supports features that other RDF databases don't support.

So you can use Java, Sesame, or SNARL as you need. And since we support Sesame & Java, you can drop Stardog behind an existing app w/ very little perturbation.

We thought and still think of this as the realizable idea. Sure it would be nice if there were only one API, but that's not the case and isn't ever going to happen.

Cheers,

Kendall

--

[Rich Visotcky]

Mike and Kendall,

Great points on having an API that you control on the product you own.  Never really realized that before, even though I was using the SNARL endpoint for administrative tasks (a prime example) that I hadn't noticed in some of the other APIs.  What really drew me to it from a tech standpoint was the use of protobuf (https://code.google.com/p/protobuf/) as a backing for the binary representation and communication, which I've found to be far more efficient than the HTTP endpoints even with compression.  Can come in very, very handy when you're pulling millions of triples, and works wonderfully when you're looking to reduce bandwidth usage in cloud-hosted scenarios where every byte counts on your bill.

[Kendall Clark]

Rich,

Thanks for the comments. Yeah, we specifically did SNARL *the protocol* for cases where latency really matters. And we've generally found it to be faster than HTTP in many cases.

Cheers,

Kendall