- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Wed, 31 Oct 2007 12:03:01 +0000
- To: public-owl-wg@w3.org
[I trust I can post this without getting accused of being anti-user, user-unknowing, narrowly technical, or whatever other dismissal de jour is in the air.] It is a truism of HCI that users vary, so if you are going to evaluate something it has to be with respect to specific users (or user types) and specific issues. So, it would be helpful if we could identify a bit better what users various documents are targeting. It's just not *feasible* to reach all the users we might want to reach, in the best way for them. For example, are we going to develop tutorials? I don't think that's a good use of WG time and effort. *Recognizing* and marketing and encouraging third party tutorials is sensible. Tweaking documents in small ways to accommodated tutorial writers is *quite* sensible (because we get a lot of bang for the buck). The two most important things we can do for users, which are most squarely in our mandate and solidly within our power, is to produce a language that maximally useful for them with specifications that support -- nay, encourage -- a strong, actively developed infrastructure (of tools, expertise, experience, community, and success). It's also important that user facing websites (which is really what we are talking about) are actively maintain ad infinitum. Ephemera should be clearly labeled as such (best if naturally so like blog posts). Pace contrevening evidence e.g., from server logs, I'd imagine that a "What is OWL?" document on xml.com: <http://xml.com/> is probably more valuable overall. It targets an influential market (i.e., web developers with some technical savvy) in a focused way. Plus, it could helps elide, a little, the perception that OWL is niche, or W3C top down wankery. Similarly, at OWLED 2007, a participant called not for more "basic" user documentation, but for "mid level" stuff, i.e., you've kinda learned the language, now what? E.g., things more similar to the SWBPD patterns stuff. Hence, the OWLED task force on "Education": <http://code.google.com/p/owl1-1/wiki/Education> Things like implementation lists: <http://code.google.com/p/owl1-1/wiki/Implementations> <http://www.cs.man.ac.uk/~sattler/reasoners.html> are really useful, but generally only if maintained. So, for many classes of user facing document, we need a post-WG sustainability strategy. OWLED and webont.org are two venues for this. I urge people not to forget that the WG is only one way to work toward the success of OWL, and that it is an instrument with limits and particular strengths. For example, adding a workable keys proposal to the language is, in my estimation, far more important than adding *any* user facing document. I base this on the fact that the users and "customers" that Matthew, Robert, and Alan influence don't seem to read any of the documents. They just ask Matthew, Robert, and Alan. They tell me that the lack of easy peasy keys is a huge barrier to adoption, or even to starting conversations about adoption. Extending the language is something the WG can, almost uniquely, do. (And note that speccing easy keys has not been trivial. Uli and I have spent more time that we expected trying to nail down all the details. And of course, no one cares about a *mere* spec...they need them *deployed*, which I am working on and constrained the specification.) Cheers, Bijan.
Received on Wednesday, 31 October 2007 12:03:30 UTC