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.

A Plug-in Mechanism for N3/Turtle

A human readable syntax is helpful for the wide adoption of any language. Many newcomers to the OWL and semantic technology world are scared away by the rather cryptic RDF/XML serialization. This serialization also makes it difficult to copy-and paste fragments and to debug.

At one occasion during the OWL 1.1 workshop, I commented that the N3 syntax is much more readable and hand-codable than the other triple-based formats of OWL. For example, the snippet below shows a class definition of Capital, a subclass of City that has some Museums.

:Capital
   a       owl:Class ;
   rdfs:subClassOf :City ;
   rdfs:subClassOf
   [ a       owl:Restriction ;
      owl:onProperty :hasActivity ;
      owl:someValuesFrom :Museums
   ] .

I think this is still maintainable by hand, and I know of several people who use text editors like emacs for all their ontology work. However, if logical class expressions and blank node trees become more deeper, then even N3 becomes difficult to read:

:BudgetAccommodation
   a       owl:Class ;
   owl:equivalentClass
   [ a       owl:Class ;
     owl:intersectionOf (:Accommodation [ a  owl:Restriction ;
         owl:onProperty :rating ;
         owl:someValuesFrom
         [ a       owl:Class ;
           owl:oneOf (:OneStar :TwoStar)
         ]
      ])
   ] .

Some people in the OWL 1.1 field will work on a human-editable format for OWL class expressions, based on the Manchester OWL syntax. For example, the equivalent class above would be written as

Acommodation and (hasRating some {OneStarRating TwoStarRating})

This syntax is already supported by TopBraid Composer and Protege-OWL.

The idea I'd like to discuss in this entry is to define a plug-in mechanism for N3/Turtle, so that domain-specific custom serializations like the Manchester Syntax can be used inside of N3 documents. The following snippet shows the N3 file above with a Manchester Syntax N3 plug-in.

:BudgetAccommodation
   a       owl:Class ;
   owl:equivalentClass
   @manchesterSyntax("Acommodation and (rating some {OneStar TwoStar})") .

The same approach could be used to embed other RDF-based languages such as SWRL. Without this hack, an average SWRL rule would look like

:Def-hasUncle
      a       swrl:Imp ;
      swrl:body
              [ a       swrl:AtomList ;
                rdf:first
                        [ a       swrl:IndividualPropertyAtom ;
                          swrl:argument1 :x ;
                          swrl:argument2 :y ;
                          swrl:propertyPredicate
                                  :hasParent
                        ] ;
                rdf:rest
                        [ a       swrl:AtomList ;
                          rdf:first
                                  [ a       swrl:IndividualPropertyAtom ;
                                    swrl:argument1 :y ;
                                    swrl:argument2 :z ;
                                    swrl:propertyPredicate
                                            :hasBrother
                                  ] ;
                          rdf:rest ()
                        ]
              ] ;
      swrl:head
              [ a       swrl:AtomList ;
                rdf:first
                        [ a       swrl:IndividualPropertyAtom ;
                          swrl:argument1 :x ;
                          swrl:argument2 :z ;
                          swrl:propertyPredicate
                                  :hasUncle
                        ] ;
                rdf:rest ()
              ] .

but this could be shortened to

:Def-hasUncle
  @swrl("(?x hasParent ?y) (?y hasBrother ?z) -> (?x hasUncle ?z)") .

N3/Turtle parsers would be able to handle these specific extensions generically, if the N3 files would declare how to convert the domain-specific expressions into triples. For example, the N3 file could start with a declaration that points to a web service such as

@plugin manchesterSyntax: <http://man.uk/parser> .

where the Web service (or a local implementation of it) could take the string and the current subject and namespace prefixes as input, and return a stream of triples as output.

Such a plug-in mechanism for N3 would not only make N3 files much easier to maintain, but also significantly shorter. This way, this approach would IMHO be an attractive alternative to data exchange formats like DIG 2.0.

Theoretically this approach could also be used to embed SPARQL queries inside of N3 files, and to dynamically create triples depending on the context. There are certainly many use cases that I am currently missing - just brainstorming...

GRDDL Support in TopBraid Composer

This blog has been quiet for some time now, but we have not been idle. The new version 1.3.0 of TopBraid Composer introduces several new features and comes with a significantly cleaned-up core architecture. The new design sets the stage for a family of new tools and components in the TopBraid Suite, including AJAX based widgets for RDF/OWL editing, and a robust client-server architecture. But more on these components in the next weeks.

One of the new features in version 1.3 is support for GRDDL, an evolving W3C draft that allows developers to embed RDF into documents such as XHTML pages. TopBraid Composer can now read GRDDL documents and use them as RDF graphs. Comparable to Composer's RDFa support, GRDDL graphs can be imported into other RDF or OWL models and then used for querying, reasoning, visualization and all other services of the TopBraid platform. Acknowledgements to our newest team member, Gokhan Soydan for implementing the GRDDL support!

Another exciting new feature is Composer's support for AllegroGraph - a massively scalable RDF triple store. We will do another posting on this shortly.

I am in Athens, Georgia, this week, attending ISWC.