Stardog 1.0.1 released

[Kendall Clark]

Folks,

We're happy to announce Stardog 1.0.1 has been released at http://stardog.com/

The release notes are http://stardog.com/docs/RELEASE_NOTES.txt and tell the whole story:

* Stardog Server now serves Stardog documentation on HTTP

* HTTP Admin API is now available

* persistent namespace prefixes for simpler SPARQL queries

* access and audit logging

Cheers,
Kendall

[Rob Vesse]

Note: if you contemplate implementing a client of the HTTP API, it is not yet stable and a few parts of it will
          change in the next (1.0.2) release. When in doubt, ask on the support forum and we can guide you.
          (This means you, Rob Vesse and Ron Zettlemoyer!)

I'm not sure if I should be offended by this or not :P

I saw the mention in the email and did think that sounds interesting but as it stands I'm about to roll another release so we'll have stable Stardog 1.x support in an official release so I'll save this for a later release

Keep up the good work

Rob

-- --
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

[Kendall Clark]

On Tue, Jul 3, 2012 at 1:32 PM, Rob Vesse <rve...@dotnetrdf.org> wrote:

Note: if you contemplate implementing a client of the HTTP API, it is not yet stable and a few parts of it will
          change in the next (1.0.2) release. When in doubt, ask on the support forum and we can guide you.
          (This means you, Rob Vesse and Ron Zettlemoyer!)

I'm not sure if I should be offended by this or not :P

I saw the mention in the email and did think that sounds interesting but as it stands I'm about to roll another release so we'll have stable Stardog 1.x support in an official release so I'll save this for a later release

Offended? Definitely. :>

The issue is that while the client & server tools work for HTTP-based admin, the server-side API isn't finalized, i.e., there are some bits we're going to change in 1.0.2, so I didn't want anyone to implement a new client (say, C#?) against a server API that was going to change in any way.

Cheers,

Kendall 

[Ron Michael Zettlemoyer]

Did I overlook it, or will some future version let us create a new database via the HTTP admin API?   I could really use this very soon.

[Kendall Clark]

It's there now, actually; but we commented it out of the docs for 1.0.1 because that part of the API will change in 1.0.2—we had some internal discussions on release day about how PUT and POST are supposed to work and decided to make some changes in how we create resources like databases.

Isn't REST fundamentalism awesome?! :)

Cheers,

Kendall

PS: if yr curious I can tell you how it will work in 1.0.2.

On Wednesday, July 4, 2012, Ron Michael Zettlemoyer wrote:

Did I overlook it, or will some future version let us create a new database via the HTTP admin API?   I could really use this very soon.

-- --

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

--
Cheers,
Kendall

[Ron Michael Zettlemoyer]

I wouldn't mind knowing how to do it in 1.0.1 too.  :)  It's not for a tool that I'm going to share or anything like that, it's strictly for a prototype of an app that will need to create new databases on the fly.  So if I use the 1.0.1 version of the API and then have to change it a little when 1.0.2 it's not a big deal.

Speaking of which, is there anything I should keep in mind as far as performance if I'm going to be setting up a lot of small (50k-100k triples) databases?  It's for a web service where each database will store the data for a separate customer.  

[Kendall Clark]

On Thu, Jul 5, 2012 at 9:12 AM, Ron Michael Zettlemoyer <ron.zet...@fynydd.com> wrote:

I wouldn't mind knowing how to do it in 1.0.1 too.  :)  It's not for a tool that I'm going to share or anything like that, it's strictly for a prototype of an app that will need to create new databases on the fly.  So if I use the 1.0.1 version of the API and then have to change it a little when 1.0.2 it's not a big deal.

Put Wireshark between client and server and all will be revealed. :>

(Basically, from memory, you PUT a JSON file of database config options to the URL where you want the database to live, i.e., http://{server}:{port}/{dbName} ... that's an abuse of HTTP, which is why I didn't want to document it till we changed it. If you look at the source of the http://stardog.com/docs/network chapter, you'll see the format for the JSON payload.)

 

Speaking of which, is there anything I should keep in mind as far as performance if I'm going to be setting up a lot of small (50k-100k triples) databases?  It's for a web service where each database will store the data for a separate customer.  

If you aren't using Named Graphs, don't ask Stardog to build Named Graph indexes (this is controlled in database creation arguments). But that's not really an issue in re: small DBs. I don't think there's much that's specific to small databases.

Cheers,

Kendall

[Robert Butler]

Ron,

The database per user model is what I'm using as well. So far, I haven't run into any issues or differences with utilizing Stardog in this manner. That said, I haven't scaled it beyond a 100 or so accounts. We are currently working on an application that will need about 3,000+ accounts in the first few months. I'm using the "snarl" protocol to do database admin with my own Java logic sitting in front of it to control the automated creation process.

I'm curious, how many user databases are you going to create?

- Robert

Robert Butler

President
Pancake Technology, LLC

972.861.0525

P.O. Box 271416
Flower Mound, TX 75027

@roberttheiv

http://www.linkedin.com/in/roberttheiv

On Jul 5, 2012, at 8:12 AM, Ron Michael Zettlemoyer wrote:

I wouldn't mind knowing how to do it in 1.0.1 too.  :)  It's not for a tool that I'm going to share or anything like that, it's strictly for a prototype of an app that will need to create new databases on the fly.  So if I use the 1.0.1 version of the API and then have to change it a little when 1.0.2 it's not a big deal.

Speaking of which, is there anything I should keep in mind as far as performance if I'm going to be setting up a lot of small (50k-100k triples) databases?  It's for a web service where each database will store the data for a separate customer.  

[Kendall Clark]

FWIW, the smaller the payload, the bigger SNARL's speed advantage over HTTP. This may or may not matter; and it's certainly easier to implement an HTTP client for Stardog's HTTP API than to dive into ProtocolBuffers.

Cheers,
Kendall

[Ron Michael Zettlemoyer]

I remember you mentioning this earlier and was thinking about this (almost) all day yesterday. For this one project I'm constantly refreshing data in Stardog with data from some other 3rd party apps. I have to tediously keep checking for changes and deletions. Rather than do a huge bulk delete/insert of chunks of data, I do a lot of small reads & writes from & to Stardog -- mostly because this seemed the best way to keep the database running smoothly for the front end that is reading and visualizing the data.  So more efficient small transactions would be helpful for me.  I've been wondering how much effort it'd take to update dotNetRDF to use SNARL.

But right now I'm running Stardog on the same server as the front-end, so there's no network bottlenecks to worry about.  And I can do a full sync to two external data sources that generate about 40k of triples in 6 minutes, which is acceptable right now.  I may already be at the point where the limiting factor is the external sources, not Stardog.

[Ron Michael Zettlemoyer]

I'm not really sure yet how many users we might have.  We're still early on in prototyping and testing.  It's a very niche application that'll provide a dashboard and synchronization for companies that are using Asana for project management and Harvest for time sheets.  They are what my company uses internally so for the moment we're happy with it just solving our own itch.  But it wouldn't take much to roll it out for other companies to try.  So we plan to roll it out on a limited basis and see what interest there is for a product like this.