We’re happy to announce a post-doc position available immediately at Clark & Parsia, either in our Washington, DC, or Boston office. The full-time position is a dual appointment at University of Arizona and Clark & Parsia LLC to work on ontology modularity in Description Logics, with an eye toward OWL 2 DL modularity for concept reuse and reasoning performance. Funded by NSF, the practical applications of the work will be realized in the iPlant Collaborative’s cyberinfrastructure.
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.)
Two weeks ago at Semantic Technology 2009 conference Evren and Mike presented a 4 hour tutorial about building OWL-based applications with Pellet 2. About 50 people attended, which was a surprising turnout given that it was at the rump end of the conference, a notoriously difficult time slot.
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!
In anticipation of our Pellet tutorial at the Semantic Technology Conference next week, we’ve made a new release candidate for Pellet 2.0 available for download. Pellet 2.0 RC7 improves on previous releases by resolving several exception-causing bugs reported by users, improving the lint tool’s support for the OWL 2 specification, and enhancing the inference explanation command line tool. The release also includes an update to Jena 2.6. This change is mostly backwards compatible for users with older Jena versions, but users depending on SPARQL query will need Jena 2.6. All of these changes are described in a Pellet Trac report.
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.
We’ve made a new release candidate for Pellet 2.0 available for download. Pellet 2.0 RC6 improves on RC5 by resolving some correctness and exception generating bugs and by improving support for the RDF/XML serialization of the OWL 2 specification (which is now in its last call period). All of these changes are documented more fully in a Pellet Trac report.
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.
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
:; pellet classify http://example.org/FriendOntology
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
:; pellet classify --loader Jena http://example.org/FriendOntology
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
:; export pellet_java_args="-Dlog4j.configuration=file:lm-log4j.properties"
Then proceed as before
:; pellet consistency --loader Jena http://www.estrellaproject.org/lkif-core/lkif-core.owl
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
:; pellet consistency --loader Jena http://www.estrellaproject.org/lkif-core/lkif-core.owl 2>&1 | grep 'Not mapped'
What’s output should be something like the following, enumerating all of the URLs which are being retrieved: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
:; unset pellet_java_args
Then proceed as before
:; pellet consistency --loader Jena http://www.estrellaproject.org/lkif-core/lkif-core.owl
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
:; export pellet_java_args="-DLocationMap=file:///etc/my-repository.ttl"
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.
We’ve made a new release candidate for Pellet 2.0 available for download. Pellet 2.0 RC5 improves on RC4 by resolving some crash-inducing bugs, supporting the newest versions of the the OWLAPI and Jena, adding support for OWL 2 keys and improving performance for ontologies using DL-Safe SWRL rules. All of these changes are documented more fully in a Pellet Trac report.
We have also updated the Pellet Reasoner Plug-in for Protégé 4. The previous version of the plug-in did not include the configuration bits necessary for a transparent upgrade, so to use the RC5 based plug-in, all Protégé 4 users will need to 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. Please continue to send your bug reports to the Pellet users mailing list.
We’ve recently completed work on a prototype for distributed query answering across disconnected RDF data sources (or relational databases or web services). The system uses Pellet to reformulate a high-level SPARQL query — written against a data model expressed in OWL – into many subqueries. Reasoning happens during query reformulation, as does SWRL rule firing, and the distributed data sources simply answer the subqueries routed to them by Pellet, based on descriptions of the data sources and their relations. Pellet then combines the answers into the final query result for the user.
The query reformulation method is sound and complete for some subsets of OWL2 DL, while maintaining good data complexity for query answering (for the curious: LOGSPACE). Distributed query answering solves two main use cases: scalability and integration. In the former, we spread the data across many systems to achieve massive scale; in the latter, the data is already spread across many systems and the requirement is to query across it sensibly.
There is a touch point with the linked data effort, which meant that the new voiD vocabulary for describing datasets turns out to be very useful for describing the distributed data sources that we query over, including their interrelations. This kind of unanticipated and uncoordinated cooperation between different parts of the Semantic Web community is a bit of real evidence that standards-based approaches can pay big dividends. We neither knew nor participated in the voiD effort, and its proponents certainly didn’t participate in our distributed query answering system — but this stuff just works together very nicely.
