ISWC and OWL 1.1
I have spent last week at the International Semantic Web Conference (ISWC) and then the OWL 1.1 workshop in Athens, GA. At ISWC, we presented our TopBraid product line at a booth, and I was busy with demos instead of attending talks. I received overwhelmingly positive feedback on TopBraid Composer, and people regard it as a significant move forward compared to Protege. During my time at Stanford I did not hear so many complaints, and I guess this is because people seldom care to voice their criticism - users who are unhappy with a tool simply disappear and move elsewhere. This probably also explains why I have a hard time getting any negative responses about Composer these days. So please - if you have ever tried TopBraid Composer, don't forget to tell me about what you dislike about it!
The OWL 1.1 workshop was very interesting and encouraging, because there is a lot of energy behind the next steps for an OWL 1.1 standard. This standard will include some features that many users need, for example the ability to express numeric value ranges (e.g., age > 18). The schedule to finish 1.1 is tight, and we at TopQuadrant will do what we can to support this movement. In particular, TopBraid Composer will soon have support for several 1.1 features, and come with a corresponding version of the Pellet reasoner.
My main issue of concern is that the OWL 1.1 working group could hit a road block due to its tendency to move OWL away from its RDF foundation. While there will be an RDF exchange syntax, the focus of the specifications lies in an abstract syntax (supported by an XML schema and UML diagrams). This design puts the position of OWL in the Semantic Web stack into question and will very likely lead to resistance. Let's hope that a suitable compromise is found to satisfy each view point and not to delay the 1.1 process because of (philosophical?) battles among the "Semantic" camp and the "Web" camp.
Based on my background as a tool developer, my personal input into this discussion is that almost all semantic web applications and APIs are based on RDF triples, and that introducing another XML syntax for OWL could unnecessarily fragment this community and make it more difficult to link models on the web. While I agree that the layering of OWL on RDF has some drawbacks, the layering also means that a lot of RDF infrastructure is directly accessible to OWL tools. In my experience both at Stanford and here with TopQuadrant, the benefits of having an RDF foundation clearly outbalance any disadvantages.
posted by Holger Knublauch @ 5:06 PM
5 comments
5 Comments:
I've been researching ontology editing tools for a couple months but I'm pretty much a beginner at this. The only comment/criticism I have for Composer is that it doesn't make a clear distiction between partial and complete definitions. As a newbie I'm noticing that Protege makes this clear, but many other tools do not.
One reference I've been using to learn the art of ontology is "OWL Pizzas: Practical Experience of Teaching OWL-DL: Common Errors & Common Patterns" (you may be familiar :) Here you and your colleagues explain the importance of the distinction for classification. Am I missing something? Have I not explored Composer well enough?
The distinction between "partial" and "complete" definitions is one possible view on OWL, and Protege implements this view. Users that start learning OWL with Protege tutorials will likely find Protege more natural than other tools.
However, in TopBraid we adopted a different user interface convention because we wanted to make it easier for people who are learning OWL from other introductory material such as the official W3C documents. For these people it is easier to see subClassOf and equivalentClass links between classes than partial and complete definitions (yes, complete classes essentially have an owl:equivalentClass). The main benefit of our approach is that it is very consistent with the OWL/RDF syntax, and also provides users with a more uniform editing experience than Protege.
Thank you. I hadn't fully made the connection between sub/equivalent class and partial/complete definitions. Would you mind explaining the implications of each on querying?
I apologize for the elementary questions and I wouldn't be offended if you point me to a more appropriate forum.
The meaning of owl:equivalentClass etc is explained in the OWL guides, e.g. here. It is hard for me to explain the difference without understanding what you mean with querying. Query languages like SPARQL will by default not understand the meaning of OWL constructs anyway. A good place to get such things answered may be the Protege, Jena or Pellet mailing lists.
One of the issues with the OWL Pizzas tutorial (and with some areas of the Protege user interface) is the use of constructs like 'partial restriction'.
'Partial restriction' as a construct is not part of the RDF/OWL vocabulary.
As the result, someone who learns RDF/OWL from these materials would then need to reconcile what they have learned with the standard. I think this is what is hapenning for Jody.
In OWL, partial restriction will be implemented as a restriction defined using rdfs:subClassOf. Complete restriction will be implemented using owl:equivalentClass.
TopBraid Composer is showing these definitions as they are actually specified in OWL. Additionally, if a class definition includes any owl:equivalentClass statements, class icon is changed - an equivalence sign is shown in the circle.
If Jody is exploring how subClass and equivalentClass restrictions interact with classification, then a (somewhat simplistic answer) is as follows:
If a class C is defined using equivalentClass restriction on property P then an RDF resource that is in the domain of P, could be classified as a member of C.
If a class C is defined using subClass restriction on property P then classification of RDF resources that are in the domain of P is not possible. Having said this, it does not mean that subClass restrictions are not useful for classification. For example, if class C is defined using allValuesFrom subClass restriction on property P where all values should come from class D, then any RDF resource in the range of P, will be classified as a member of D.
Post a Comment
<< Home