A Proposed Draft Charter for a NextWebOnt Working Group
by Bijan Parsia
At OWLED 2006, the attendees decided that we should try for a working group to standardize the OWL 1.1 documents as a set of W3C recommendations. The next step in producing a working group is to produce a working group charter. Since, I started a very sketchy charter draft for discussion at OWLED, it seemed to make sense to flesh it out as a starting point. I’ve started a discussion thread on public-owl-dev about it.
I tried to write a (draft of a proposal for a) charter that is sufficiently scoped so that the working group is constrained to a relatively small, predictable addition to OWL. I personally want this for several reasons:
- As an implementor, expert, and tool guy, I hear a lot of “we need qualified number restrictions”, “Should I use OWL Lite?”, and “Why can’t I use the Dublin Core ontology with OWL DL?” Of course, I also hear, “How about rule support?”, “Database integration!”, and “How about nonmonotonic inheritance?” (Ok, the last not so often :)). The difference for me between the former and the latter is the former are more semantically and implementationally uncontroversial (though, punning and annotations are possibly dodgy semantically), and I know enough high profile, high value users who would, in fact, use the particular variants that we can easily build consensus and implementations around. So, I would like to implement support for them in an interoperable and standardized way.
- While people have mentioned worries about disturbing the OWL and Semantic Web ecology by somehow sending the message that “OWL is broken” or “Wait for the new and better OWL before adopting”, I think there is a converse worry: that OWL should appear to be stagnant, and/or that persisting missing functionality (esp. QCRs and Datatypes) will drive important users away from OWL. Clearly, neither consideration is conclusive since they are both predicated on rather tenuously based predictions. However, I hope that this working group will balance the concerns. By being scoped and incremental and fast, I hope it can avoid any untoward destabilization. Old OWL will still be good OWL. Having major tool builders on board also helps a lot. (I think we’ll get some new vendors too, esp. given the tractable fragments document.)
- I dearly hope this is not the last increment/addendum/change to OWL. I hope this group can set the bar for useful, careful additions to be quite low. At the moment, afaict, there’s no (other) plan or intention for adding to OWL. Given the wealth of interesting and useful extensions being developed, the postponed issues, and the partially met or unmet goals of WebOnt (not to mention the goals they left out!), it seems clear that just punting is a non-starter. I’d like there to be a clear way forward. Personally, I’d like to repeat what we did for this: At an OWLED, discuss what’s the next sensible de facto standard. Once that is realized, form a working group to make the de facto all de jure.
- Some things can be and perhaps properly are handled by other groups, such as the RIF (for rules; though really, the RIF is about interchange of rules and what some OWL users want is an OWL rules language, which might then have a corresponding RIF dialect), or the DAWG (for conjunctive query). But other things really seem to require attention on OWL itself (such as QCRs, axiom annotations, and the like).
- I would like OWL to be a bit more XML friendly, on the one hand, and human reader friendly, on the other. I think these can help adoption a lot by reaching into new user communities.
- Logic based KR has a lot to offer that OWL or OWL DL (and, by extension, OWL 1.1) doesn’t offer. There are competitors, both standardized or standardizing (e.g., Common Logic) or not (F-Logic), that are worthy of respect and investigation. There are choices running fairly deep in OWL (and OWL DL) that make synthesis with these other languages, at least as they are commonly implemented and deployed, fairly nontrivial. In fact, there is ongoing research on this. I don’t want this working group to address any such issues, mostly because I don’t, at the moment, as a tool developer, see how to support what I imagine the resulting specs to be in any reasonable time frame for a reasonable (and likely) level of investment. Heck, I don’t see how to specify such in a reasonable time frame for a reasonable level of investment.
- I would like the working group to finish in short order. So, I’m trying to make the charter such that the working group doesn’t go off into the weeds (my experiences with WSDL and DAWG loom; even WebOnt and RDF Core are cautionary). On the other hand, I’ve been on the short end of a charter fight where, really, we could just fix something or add something really useful, but “the charter doesn’t allow it”, while not typically actually a show stopper, makes it all very unpleasant and tedious. I would like the charter to be helpful to the group, not annoying to it, and helpful to reaching completion in a short time frame.
These were the sort of thing running through my head as I tried to craft a charter.
There’s a streamline version of these considerations prepended to the draft. I felt compelled to write out these thoughts to help avoid confusion about the “status” of this draft. It has no official status with anyone. I wrote most of it. Ian reworked large chunks. I think it reasonably reflects the understanding of the attendees at OWLED 2006. And, I think it’s a reasonable charter. I could live with this. If you have radically different goals, then you may not be able to live with it. Tant pis. Come to OWLED and influence the next one!