1. We increased coverage to include several new products
2. We decreased prices across all four support levels

We’re expanding of our commercial support plans to include more C&P products, as well as some open source semweb pieces, too:

• Pellet, including support of Pellet apps using Jena and OWLAPI libraries
• Owlgres
• OwlSight
• JSpace
• Protege4

We’ve also gotten feedback from customers and potential customers that the price of our support offerings wasn’t in line with expectations. So we’ve adjusted the price of all four support levels significantly by doubling the number of support hours per level, which more closely mirrors what appears to be a reasonable average for complex open source project support plans.

We’re especially happy to being offering support not only for our reasoners (Pellet and Owlgres) and browsers (OwlSight and JSpace), but also for Protege4. We think its the best open source OWL ontology development environment available. We’ll be offering some commercial plugins for Protege4 in Q3 of this year.

Downloads and documentation can be found at the Owlgres site. For bug reports, feel free to open a ticket on our issue tracking site for Owlgres, which also summarizes the first steps with Owlgres on the Wiki page. There’s a mailing list for discussion and support.

Owlgres is dual-licensed; for open source projects, it’s available under the AGPL v.3. For commercial projects, commercial support licenses are available.

We’d love feedback on Owlgres and encourage people to try it out, play with it, and report bugs, issues, and ideas.

But the real reason is that I wanted to make it easier for our readers to comment on what we’re saying and doing.

So: cry havoc and let slip the dogs of spam, I suppose.

If you have not already taken a look at OwlSight, cruise on over to the OwlSight page and take it for a spin. For those not already in the know, OwlSight is a lightweight browser-based ontology browser utilizing both GWT (and GWT-Ext) and Pellet as its core technologies. Until next time, stay classy cyberspace.

Most of the changes in this release were made to address issues reported by end users – keep up the good work, and we’ll try to keep pace with fixes. You can visit the Pellet trac report listing the resolved issues for full details.

It’s worth noting how this release came about. We had planned for 1.5.1 to be the final release in the 1.5 series. Moody’s contacted us because they had identified a bug that was blocking the critical path of an internal project. We were able to resolve the issue, and they were motivated to have the fix made public in a release that would be a drop-in upgrade of 1.5.1. This is an example of how commercial support can be a multiplier on the value of open source development.

There’s another point to make from this example as well. Often on pellet-users we get help requests from people that are reluctant to make the data they’re working with public. This leads to frustration on both sides – we can’t reproduce the bug without the data and they don’t get a fix. This release demonstrates that this problem is manageable, but it requires these users to contact us and consider the commercial support options.

We expect to rev the public releases of Pronto and OwlSight in the next week to pull in these changes.

Update 18:00 EDT: I’ve sent a release announcement to the mailing list that contains a bit more detail on the specific changes since 1.5.1.

1. I’ve never been happier or more productive with email since I switched to a combination of sup, offlineimap, screen, and Emacs.
2. For programming, which I do less and less these days—to the great delight of coworkers on at least two continents!—it’s git, ditz, gvim, and Emacs. Build tools are enjoying a flowering lately, so I’ve been looking at zc.buildout and Paver. I read the Vellum docs last night; way, way too much of the wrong sort of attitude.
3. For building real docs, LaTex, of course, and rubber.
4. For music, mpd and ncmpc. Very nice solutions, these.
5. For shell, fish and the most pager. Nice.
6. For monitoring, htop. Love the htop!
7. For news reading, I tried to love snownews, but failed; right now I’m using Liferea. I want to eval Raggle and TheYoke.
8. I’ve been mulling a switch in Gnome to a tiling window manager like xmonad, awesome, dwm, ion, or Ratpoison. The problem here is too much choice. I wish the LazyWeb would just tell me which one of these is best with Gnome.
9. Oh, I forgot: for IM and IRC, finch and irssi, respectively.
10. And for Twitter, I have to decide whether I want to tweet more from Emacs or vim. Each has a simple, embedded Twitter client.
11. For todo list management, trying to choose between Dev Todo and git-todo-py, leaning toward the latter.
12. Related: I’ve been gradually moving some work from Emacs to gvim; I’ve never really made a serious attempt to live in vi, and I’m really enjoying it. For example, making 12 pt Consolas the default font in gvim took one simple line of configuration that I found in less than 1 minute of googling. Sweet.

Just about the only GUI programs I still use regularly are Firefox and Emacs; although, Firefox has really been infuriating lately because it leaks so much damn memory. I’ve switched to the 3 beta series to see if memory consumption improves.

This command line rebirth is probably just one of those phases necessary to sustaining my interest in using computers all day, every day, especially since I really, really hate them. But it’s also the case that as I get older, with a baby at home, and many more things to do each day than hours to do them in, I want to maximize my productivity.

Anyone else trending this way?

1. 28 April, Boston, BioIT World Conference’s “Harnessing the Semantic Web for Your Organization” workshop . Mike Smith is giving a talk with our NCI customers about how HCLS and other bio orgs can start to take advantage of semantic web stuff.
2. 19 to 21 May, San Jose, Semantic Technology Conference (Bad URL that will break for the 2009 conference; ironic, that!). Evren Sirin, Mike Smith, Pavel Klinov, and I will be giving three talks—Pellet, Pronto, and XACML-DL Policy Analysis. Actually, I’ll be there trying to act “managerial”; I leave the talk-giving to the smart guys.
3. 2 to 4 June, Palisades, NY, POLICY 2008. Markus Stocker and I will be giving a demo talk of XACML-DL, our XACML policy analysis tool.

Upcoming we’re targeting a conference about Ontologies and Model-Driven Architectures (MDA)— which is what OMG is doing now that CORBA is dead-dead-dead—that’s sometime in the fall in Toulouse, which is nice.

One of our new customers—who’s sponsoring a pending Pellet maintenance release, version 1.5.2, that should be out ver soon—is using Pellet to drive a pretty complex code-generation process, and that’s an area where we think Pellet has a huge upside. And we’ve found giving talks and papers with customers as partners is a good pattern.

If you’re planning on attending any of these conferences, shoot me an email as we’d love to chat with users, friends, fans, and interested bystanders.

In this post I’d like to underline the usefulness of the selectivity optimizer using a short and concrete example from DBpedia. We query over roughly 24 million triples (in Owlgres metrics 2,198,649 concept assertions and 21,503,343 data role assertions). The query asks for instances of Book and looks like this:


PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX yago: <http://dbpedia.org/class/yago/>
PREFIX dbpedia: <http://dbpedia.org/property/>

SELECT ?name WHERE {
?s rdf:type yago:Book106410904 .
?s dbpedia:name ?name .
}

Without the optimizer, the query runs in 61,743 ms and with the optimizer in 14,336 ms.

Why? The TBox contains totally 58,108 concepts and 53,898 of them have no asserted instances (that’s around 93%). This isn’t very surprising since typically individuals are asserted in the leaf concepts of taxonomies.

But it makes a lot of sense to consider this during the query reformulation process in DL-Lite. In fact, without the selectivity optimization, the reformulated set size is 83, i.e. the algorithm reformulates the original conjunctive query into a set of 83 conjunctive queries.

By using some basic statistics (I’m not talking about complicated maths here!) and a trivial procedure to eliminate conjunctive queries that have a known zero selectivity, we can reduce the reformulated set of conjunctive queries from 83 to 16. This makes everybody happy, including Postgres, which returns the result set 4.3 times faster (not huge, yes, but worth the effort). Note that there is no caching here. If caching is involved, the query takes approximately the same time (with and without selectivity optimization, it takes roughly 3 seconds).

I’ll be at WWW2008 this week and I’m happy to chat about DL-Lite with interested people and demo Owlgres on DBpedia. I’ll have a talk on SPARQL Basic Graph Pattern Optimization Using Selectivity Estimation on Thursday, probably the easiest way to spot me. The talk is about some previous work that started in 2006 at the University of Zurich as a diploma thesis and was refined in 2007 at HP Labs with the implementation of the query optimizer for ARQ, the Jena SPARQL query engine.

• URL escaping of parameters passed into OwlSight
• Rendering of datatype values for Individuals has been fixed
• If an error occurs while generating an explanation, control is properly returned to the main application window.

If you are interested in learning more about OwlSight, please head over to the OwlSight page on owldl.com.

In the weeks since that announcement, I’ve gone on to further extend the functionality of OwlSight. The main items of interest are:

• Support for viewing annotations
• Support for Individuals
• GRDDL based ontology repository support
• Enhanced the Property view, adding domains, ranges and inverse property information
• Storage of your ontology repository in a browser cookie so its loaded each time you run OwlSight
• Improved explanation rendering
• OwlSight handles URL parameters; links to ontologies or repositories can be passed in and loaded on startup.

You can find some more details information about our ontology repository work here and there is now a very simple, and probably incomplete, OwlSight readme.

Make your own ontology repository. Link to OwlSight from your web pages, and use it to show off your favorite ontologies. Until next time, stay classy Cyberspace.

• An XML syntax which is very close to the functional syntax and much better suited than RDF/XML for XML-oriented toolchains
• A set of 3 “profiles” of OWL (this is the new name for the tractable fragments)
• A Primer

I’m very happy with all of these. Back when we were first preparing the OWL 1.1 documents, I pushed hard for an XML syntax and a new “rational” set of species and I’m glad to see the WG take them up. I’m especially pleased with the Primer as one might expect, being an author! But also I think it has the potential to make OWL much more accessible to people.

One feature I really l like about the primer is that the syntax of the examples is configurable to your favorite syntax. I’ve wanted something like that for years now. I have several more ideas for nice user configuration of the primer, and even more for the content.

While it is in a very first draft state, it’s already had some good effect. My pal Michel Dumontier took one look at an earlier draft and immediately ripped it off for a set of slides for his class. You can’t pay for that kind of love, folks!

I’ll have more to say about the profiles (EL++, DL Lite, and OWL-R) later, though I’ve done some preliminary work on primer text about them.

I’m hoping we’ll publish new drafts of the core trio in the next month or so that will show the new features and design changes we’ve added since publishing them as FPWD. The WG seems to be clicking along nicely; the F2F was highly productive.

While we aren’t fetishists of that sort, we build our systems and technology to work with, use, make advantage of, and otherwise co-exist with “the Web” when and where that makes sense, which is very often. As more evidence of that fact, consider OwlSight, which is an OWL ontology browser that runs on Web browsers, delivering a realistic and useful “rich Internet application for the Semantic Web”—enough buzz words there?

OwlSight is a GWT-Ext application, which is turning into a pretty damn good development platform for us.

Further, we’ve recently been working on GRDDL support in OwlSight; where by “we” I mean “Mike Grove,” and by “recently” I mean “during the OWLWG meetings” this week last week.

By “GRDDL support in OwlSight,” I mean that we’ve defined a trivially simple RDF vocabulary that describes collections of OWL ontologies—that is, ontology repositories—published on the Web. We use the RDFa GRDDL transform to extract this RDF from Web pages, and then OwlSight builds a user interface for browsing these OWL ontology collections on-the-fly, both as a collection and as individual ontologies.

At some point we may do the slightly harder thing: visualizing ontology repositories, both according to how they relate to each other by way of, say, owl:imports, as well as how they are structured according to something like our locality-based ontology modularization stuff. (By which I mean: we have code that is able to tear OWL DL ontologies apart, in a logic and semantics-respecting way, in very reasonable running time. If you do anything at all seriously with ontologies, you’ll know how useful this is…)

So what does all this mean?

It means that OwlSight with GRDDL is very Web-friendly: anyone on the Web can publish an OWL ontology repository on the Web, embed some information about that repository into a Web page using RDFa (or any other GRDDL transform, for that matter); and then point OwlSight at that repository and get some joy.

Even I—no Web fetishist at all—find that quite nice. Sometimes Linked Data means Linked Ontologies. Wouldn’t it be nice if the OWL DL Haters would keep that in mind?

I’m excited by that decision in part because I think it will give the Semantic Web community and other groups of users, too, a new opportunity and reason to take a new, fresh look at OWL.

Tomorrow (4 April) is the last day; tonight is the traditional Working Group Dinner, which I’m especially looking forward to, since it’s being held at Dogfish Head Pub.

And, after a long day of spec-making, Beer is a Good Thing.

In addition to including support for probabilistic ontologies, the new version of also has an entirely new look and feel. We used GWT-Ext to build the new UI components, with very pleasing results. We’ve also fixed a number of bugs, and made some other modest improvements. But if you are interested in Pronto, or you are just interested in a lightweight, browser-based ontology browser, you should give the latest version of OwlSight a try.

To get started, there are two new bookmarks included with OwlSight, both of which illustrate probabilistic reasoning in the context of OWL DL reasoning. Choose the Penguin Bird or BRC bookmarks to load and browse a probabilistic ontology.

More practically, this means for instance that (after tweaking a bit the data) one can load the DBpedia Wikipedia infoboxes and their classification into PostgreSQL as ABox and TBox respectively and then query along the YAGO class hierarchy. For example, DBpedia explicitly states “The Lord of the Rings” as an instance of Book and a corresponding query returns the correct result set. But although Book is a subclass of Publication the result set of a query that asks for a Publication with name “The Lord of the Rings” is empty. Not in OwlGres. Somehow sweet, isn’t it?

The main parts of Owlgres were already implemented before I joined C&P in February. Though, Owlgres suffered from some query performance problems. So my task was to look at how we could possibly optimize the overall query performance.

In a nutshell, DL-Lite query answering includes a reformulation step that encodes the TBox knowledge into the DL-Lite ABox query. This reformulation typically expands a query into a set of (reformulated) queries that are subsequently translated into SQL queries. The overall result set is the UNION of the intermediate result sets for each of the queries in the reformulated set. A good starting point for optimization is, hence, to look at the size of the reformulated set. Is it minimal?

Let’s take a look at a real world case. For instance the LUBM query 9. The query can be seen as the following DL-Lite ABox query

{ Student(?X), Faculty(?Y), Course(?Z), advisor(?X, ?Y), teacherOf(?Y, ?Z), takesCourse(?X, ?Z) }

The PerfectRef reformulation algorithm described by Calvanese et al. returns a reformulated set of queries of size 726 for the LUBM query 9 and, hence, Owlgres executes 726 SQL queries on PostgreSQL to get the result set. The question is, can this set be reduced? The answer? Yes.

One thing that we quickly notice is that a significant number of queries have an empty result set. Further, many queries have result sets that are subsets of other queries. For instance, the result set of the second query in the following example is a subset of the first:

{{ advisor(?X,?Y), teacherOf(?Y,?Z) }, { advisor(?X,?Y), teacherOf(?Y,?Z), Faculty(?Y) }}

Thus, we can drop the second query as it doesn’t add any value to the overall result set. We found that a domain/range simplification practically eliminates such subset queries. Essentially, for each reformulated query we drop query atoms that are redundant constraints. For instance, in the second query above, the Faculty(?Y) query atom is redundant as the domain of the object property teacherOf is specified to be a class of type Faculty in the LUBM TBox. By removing the Faculty(?Y) query atom in the query above the two queries are equal and, hence, we reduce the set by one. So, domain/range simplification is the first optimization.

A DL-Lite ABox query is a set of query atoms which is executed as a conjunctive query. If one of the atoms has zero selectivity, the entire query has zero selectivity. It is, hence, useful to know if query atoms have a zero selectivity as this information allows us to safely drop queries from the reformulated set. This is our second optimization. During the ABox loading process, we gather statistics about the frequency of TBox names (concepts, roles). Whenever a TBox name with zero selectivity is used in a (reformulated) query we drop the query from the resulting set.

To come back to our example LUBM query 9, by applying the optimizations described above we reduce the initial reformulated set of 726 queries to just 2 queries. Pretty amazing, isn’t it? Needless to say, PostgreSQL is happy about this too. Finally, we create a single SQL query of the optimized reformulated set by creating an SQL UNION of the queries in the set. Thus, instead of 726 single queries we execute just one.

It’s time for a couple figures. We expect faster queries, but how much faster are they? We tested the 14 LUBM queries on the University0 dataset (i.e. roughly 100k triples). The timings below are in milliseconds. We first show the timing for the non optimized reformulated set and then the timing for the optimized set.

For instance, the LUBM query 9 takes 18 seconds to be executed without the optimizations and 0.1 seconds with the optimizations. The average difference between the optimized and unoptimized queries is 1,914.43 milliseconds.

We’re going to be demoing Owlgres publicly for the first time at OWLED 2008 in DC in two weeks; if you’re attending OWLED, we’d love to show Owlgres to you. We’ll be saying more in future posts about the kinds of reasoning problems Owlgres and DL-Lite are especially suited for.