We’ve also release an updated Pellet Reasoner Plug-in for Protégé 4 to work with Pellet 2.0.2.

Empire 0.6 will generate Java interfaces for classes described in an OWL ontology automatically based on domain & range constraints, cardinality restrictions, and usage of the classes in data (when there is ABox, i.e., assertional, data in your ontology). Implementations of these interfaces are generated at runtime. This is a key part of our semantic application platform move, which we sum up simply as: If ontology, then application. More about that in weeks to come.

Eventually, Empire will be a drop-in replacement for non-RDF JPA systems such as Hibernate and Toplink. We’re not quite there yet, but Empire can be used alongside a library like Hibernate to help ease the transition to SemWeb-based architecture or to supplement an existing JPA application with, say, Pelorus, our faceted navigation browser.

Empire 0.6 uses Guice to provide support for the JPA SPI framework; we can inject our implementations of EntityManager and EntityManagerFactory into Empire-managed contexts. We also use Guice to register the data base plugins; Empire currently supports 4Store, Sesame 2.3.0, and Jena. Which means it supports just about every conceivable RDF triple store.

Enjoy.

We’re happy to release Pellet Integrity Constraint Validator version 0.3, a prototype system that uses OWL ontologies as integrity constraints for RDF data. ICV automatically translates OWL axioms into SPARQL queries (while still doing OWL inference, by the way!), so that an OWL ontology can be used to validate RDF data integrity automatically.

This offers the best of at least three worlds: the logical rigor and expressiveness of OWL; the “loose typing” of RDF and Linked Open Data; and the performance and scalability of SPARQL engines.

What’s new in Pellet ICV 0.3? Glad you asked:

1. explanations of violations
2. choice of validator implementation: Jena or Pellet will execute auto-generated SPARQL queries
3. option to check all IC violations
4. more efficient auto-generated SPARQL queries (using NOT EXISTS statement instead of LET in ARQ queries)

As always, comments, questions, and feedback are welcomed.

The 2.0.1 release closes 16 tickets, all of which are detailed at the Trac page for this release. Pellet 2.0.1 is available for download.

We’ve also release an updated Pellet Reasoner Plug-in for Protégé 4 to work with Pellet 2.0.1.

A successful candidate will have a PhD in computer science (or related field) and significant experience with Description Logic, ontology modularity, automated reasoning, or other relevant specializations. The post-doc will work closely with leading practitioners in the area of automated reasoning on both theory and practice (i.e., software development) and should be comfortable realizing algorithmic ideas in Java.

The position is available immediately, for a duration of 18 months with a possibility to be extended an additional 18 months (extension to be determined at a later date). Competitive salary, good benefits package, etc. included.

See the UA job listing page for details about the application process. Please feel free to email with questions. (N.B.: the UA job description says “part-time” and “Washington, DC area”; but the position will be a full-time dual appointment and is available in DC or Boston.)

If you’re interested in scalable, efficient semantic reasoning for the enterprise, try PelletDb 1.0, which is available for a 30 day trial period.

To discuss licensing requirements, email us or pick up the phone: +1 202 408 8770. You should follow us on Twitter, too: @pelletdb.

During the past 13 months, we closed 199 tickets as part of the 2.0 release candidate cycle, including numerous enhancements and bug fixes. Please see CHANGES.txt in the distribution for a complete change log; some highlights include:

• full OWL 2 support (modulo a few bugs that will be fixed in the 2.1 release)
• supports domain & range axioms, class expressions, qualified cardinality restrictions, literal constants, annotations, and nested class expressions in SPARQL queries
• support for all SWRL builtins, including previously missing builtins (substring, tokenize, and optional precision parameters for roundHalfToEven)
• optimized support for OWL 2 EL reasoning; OWL 2 EL reasoner is autoselected based on data input
• supports automated ontology module extraction
• supports incremental classification
• supports fine-grained inference extraction
• enhanced SWRL rules performance
• OWLAPI v3 support
• lots of improvements, cleanups to Pellet’s command line tools
• updated to work with Jena 2.6.2 — Pellet is the only DL reasoner available from Jena
• supports explanations via Jena
• support autoselecting best SPARQL query engine based on input query
• user-defined timeouts for reasoning
• switch to dual license model to support commercial and open source projects

This release marks a change in Pellet development process: starting with 2.1, Pellet will be released according to a time-based development cycle. We will do four quarterly releases per year. We will make point releases between the quarterly releases, as necessary, to fix critical bugs only. Thus, the release schedule for the 2.x series will be 29 March 2010, 28 June 2010, 27 September 2010, 20 December 2010.

We believe this new development and release process will further accelerate the commercialization of Pellet, with no undue impact on its utility for either research or other non-commercial applications.

Finally, with the release of Pellet 2.0, we will no longer support previous versions via the pellet-users mailing list.

Inquiries about sales and licensing? inquiries@clarkparsia.com or +1 202 408 8770.

Today we’re releasing an extensive PelletDb whitepaper (PDF) that explains in detail what PelletDb is, how it works, who should use it, etc. It includes customer benefits, sample code, and a basic roadmap for future development. If you’re curious about how we’re fusing Pellet and Oracle, check out the whitepaper.

The PelletDb limited beta is on-track to begin 15 July, so please get in touch if you want to participate.

After some polishing based on feedback, we’re making the tutorial materials, including sample code, slides, and a bundled download of Pellet, available for use in learning (or teaching others) how to use Pellet, both interactively and programmatically.

Enjoy!

Pellet Reasoner Plug-in for Protégé 4 has also been updated. Existing users should be prompted for an automatic upgrade to plug-in version 0.9.3.

Please continue to send your bug reports to the Pellet users mailing list. As always, you can influence the future of Pellet by contacting us to start a support relationship.

I’ve been working on an internal project lately, and while we were having a code review the other day, we decided that adding some validation via integrity constraints would be useful.  The catch was that I’m using Sesame, in particular, Sesame 1.2.7 since that offers the best query performance of their whole line of software (at least it did the last time I checked).  And since I am using the older Sesame API, I’m without SPARQL support.  This makes it difficult for me to repurpose our IC prototype since it’s based on Jena and SPARQL.

So I worked on an implementation of our IC interface that was based on the Sesame API and used SeRQL.  This turned out to be vastly easier than I expected.  One of the workaround’s we used for the SPARQL-based implementation was the OPTIONAL/FILTER/!BOUND pattern because SPARQL does not provide a NOT keyword for encoding Negation as Failure.  As it turned out, I didn’t need to implement a workaround like this using SERQL. I was able to get by using the NOT & IN keywords with a subquery to get the same behavior. The resulting queries are very clear.  So with some code to translate the constraints into SERQL queries, and a Sail implementation backed by a Pellet KnowledgeBase, we get the same IC joy in Sesame projects as we do with Jena and SPARQL.

This is good fodder for the new SPARQL working group that we’re participating in (nominally, so far); I believe subqueries and negation are both being considered.  They would make great additions to the revised SPARQL.

We have also updated the Pellet Reasoner Plug-in for Protégé 4. Existing users with the RC5 based plug-in should be prompted for an automatic upgrade. All other Protégé 4 users should follow the installation directions as if the plug-in is a new install.

Many of the changes in this release were made in response to user identified problems, and several were prepared specifically for our support customers. Please continue to send your bug reports to the Pellet users mailing list and if you have a particular problem that you’d like to motivate us to fix, you can contact us to start a support relationship.

Simple Integrity Constraints & Reasoning

In this post I want to give a simple example to motivate the integration of OWL reasoning with integrity constraint checking. Consider the case encountered when instance data is expressed in terms of the most specific concepts in an ontology:

So, in this ontology there are three concepts: citizen, man, woman; and all citizens are men or women but not both. And, further, there is a property, Social Security Number.

The instance data is

So: there is a woman, Marge; and a man, Homer, who has a Social Security Number. In this example, how can we say that all citizens should have Social Security Numbers? Like this:

But without reasoner integration, this constraint won’t apply to either Marge or Homer, because the constraint refers to citizens, not to men or women. Which is as it should be since duplicating the constraint is not only inaccurate but error-prone (DRY, after all).

Since our integrity constraint checker uses OWL reasoning, however, it will infer that Marge and Homer are both citizens:

Thus, when it applies the integrity constraint (that citizens must have SSNs) it will produce a validation error: Marge is a citizen, which we know by reasoning, but the data does not contain Marge’s SSN.

Bad Workarounds

Integration with reasoning allows us to do better data modeling, since it prevents us from repeating the constraints for all of the most specific class types (men, women) when it’s simpler to put the constraint on a more general class (citizen). And this is more accurate data modeling, too, since the requirement for SSNs is not dependent on a person’s gender.

The obvious workaround, if you don’t have reasoning integrated with constraint checking, is to write integrity constraints in terms of the most specific concepts, which is almost always an unnecessary proliferation of constraints–violating DRY–and may be inaccurate modeling, too.

This workaround makes constraint authoring and maintenance much more difficult. By integrating with the reasoner, we support a more natural and scalable approach to integrity constraint specification, one that leverages the ontology by placing constraints appropriately high in the class hierarchy.

Preview Release

If you want to play with a preview release of our OWL-based Integrity Constraint validator, you can download it now. Note that it’s not licensed under open source terms. This version will likely be released open source in a future version of Pellet, but we’re not doing that today. Information about installation, use, and the forum for more information and bug reports (please!) are all included in the README.txt. Details of the evaluation license terms are in the LICENSE.txt.

Edited: 2009-06-18 to update version at download link.

It is relatively common for us to hear from clients that they want to use Pellet without it accessing the network. Sometimes they want to avoid network problems by caching locally; sometimes they’re conforming to local security policy constraints; often, people just like hacking on local copies before publishing their ontologies on the Web. Regardless of motivation, they need to avoid the network access used to fetch the contents of an ontology’s imports closures. In this post I outline how a user can setup a local ontology repository that will be used by Pellet’s Jena loader.

The most common use case is a user hand editing a collection of local ontologies which use HTTP URLs. Until the ontologies are ready to be published there is no content (or, even worse, outdated content) at those URLs. The problem is that it’s cumbersome to change all the URLs to file: URLs only to change them back when publishing.

Consider two simple ontologies, presented below using Turtle syntax. First,

We want to use Pellet to iteratively check the inferred class hierarchy as we develop the ontologies. To do this with the command line tools, we normally issue the following command

But if we try this as-is, we’ll get an error. We need Pellet to recognize that, while these ontologies are destined to be published on the Web, for now they are in local files named people.ttl and friend.ttl. To do this, we use a Jena LocationMapper configuration file. We can setup the file, named location-mapping.ttl, with the following Turtle content:

The only other change we need is to explicitly tell Pellet to use the Jena loader; it uses the OWLAPI loader by default. The command line looks like

With the location mapping configuration file in place, we no longer get a timeout but instead see the class hierarchy we expect, based on the content of the local files.

The second common use case is a user working with an ontology they’ve found on the Web and which has an arbitrarily large imports closure. This user wants to avoid network accesses to fetch ontologies. There are three steps to addressing this; first we need to identify all of the ontology URLs in the imports closure, then we need store them in our local repository; finally, we need to create an adequate mapping file.

To illustrate this example, we’ll use the LKIF-Core ontology. This ontology is interesting because it has a moderate number of ontologies in its imports closure. We could use a tool like Protégé 4 to identify the ontologies in the imports closure; but we’re going to assume that Pellet is the only ontology tool available. To find all the network resources fetched, we can take advantage of some debug logging available in Jena. Jena uses log4j, so we need to create a log4j configuration file, called lm-log4j.properties, to echo the interesting content to standard error.

Once created, we set the system property log4j.configuration to reference the file. If you’re using the shell script included with Pellet-2.0 RC5 or newer, you can do this with an environment variable as follows

Then proceed as before

There will be a lot of DEBUG messages, but it’s easy to narrow in on the useful details with a simple grep command, such as

After downloading each of these files and saving them locally, we can create a location mapping file as above, with one map entry per ontology. That said, the location mapping configuration file supports more sophisticated mapping, and this is a great time to take advantage of prefix based mapping. The following content in location-mapping.ttl should be sufficient:

With this in place and all the files in the working directory, if we rerun the previous command, grep doesn’t find any matches. To disable the debug output

Then proceed as before

We’ve used the location mapping configuration to completely avoid network access.

A few additional details are worth noting. First, Jena does some searching for the location mapping configuration file, but the easiest approach is to keep it in the working directory. Alternatively, it can be explicitly named using the LocationMap system property. This approach can be attractive if you work on multiple ontology projects and would like them to share a single local repository. E.g., you might use

Second, in Pellet 2.0 RC5 this functionality is only available if Pellet’s Jena loader is used. We’ve got a ticket open to duplicate the functionality in the OWLAPI loader and hope to have it in place before the final Pellet 2.0 release.

Feel free to comment on this functionality or any other aspect of Pellet’s behavior on the pellet-users mailing list. See you there.

Edited 2009-03-16 15:15 EDT to note:
There has been some public discussion, such as this thread on public-owl-wg@w3.org about tools using XML Catalogs to provide a standardized map description format similar to the one provided by the location mapper configuration file used here. We think that any mechanism that is sane and supported by OWL tools in an interoperable way is a good thing. Translation between the Jena format and XML Catalogs looks straight forward, so you needn’t worry about backwards compatibility issues if Pellet supports XML Catalogs in the future.