Thinking Clearly .

This is not a post expressing my long standing and ongoing concerns (yes they are both “long standing” and “ongoing”...they stand on a very long conveyer belt, ok?) with both the fundamental presumption of the Technical Architecture Group and the things they actually do. I’m not going to explain the fallacy of Argumentum ad Architectural-Blather-I’ve-Pulled-Out-From-My-Ass-Compartment. No, this post is all about coping. Specifically, coping with argumentum ad ABIPOFMAC.

My current thought is to replace the annoying terms and phrases with a harmless or comforting word associated with a pleasant image or thought. The word doesn’t have to be precise: I’ve selected “puppies” (and I’m not a dog person!) So instead of the “Technical Architecture Group”, I see “Technical Puppies Group” or, the “Pile o’ Puppies” (POP). I applied this technique to a recent post by a POP member to the HTML Working Group’s list. Here are some key excerpts:

Puppies of the POP believe that the ping attribute as proposed in HTML5 may have a deep impact on the puppies of the Web itself. Accordingly, the purpose of this bark is to invite the wider puppy community to discuss these piddling issues on on[sic] puppy mailing list www-POP@w3.org (archives at [5])—the issues ruffed appear to have bones beyond HTML5[ed. e.g., like on THE WEB ITSELF!!!], which is why we would like to broaden the laps, and at the same time to focus on the wider puppy questions of how HTTP, HTML and puppies cuddle. We also note that to serve as an umbrella for its own licking of these questions, the POP has re-opened its sniffles “whenToUsePuppies-7” [6].

Note: our puppies here is specifically to involve the Web Puppy community in the discussion of these puppies. ...
Noah Mendelsohn
For: the W3C Pile o’ Puppies

Ok, it’s better but not really great. But, really, there’s only so much one can do with a paragraph that includes, with all seriousness, the phrase, “may have a deep impact on the architecture of the Web itself”. The Web….itself. When you read those stirring words themselves, your choice itself is stark: either you hear solemn music itself welling up in the background itself and prepare yourself itself [sic] to ponder Serious Matters (themselves)...or you hear puppies piddling.

Embracing the piddling, my friends.

No puppies were harmed or even encountered in the making of this post.

Whatever you do, do NOT try the old “in bed” trick. Unless I don’t like you, in which case, by all means read the phase “The Technical Architecture Group….in bed” over and over again.

This post constitutes fair warning that if you try to argue a point with me by appeal to Semantic Web puppies, I will tend to giggle and have a hard time taking you seriously.

Apropos of nothing: Support the writer’s strike. Vote Robot Overlords! (Like you have a choice!)

I’m very happy to see the first of several rounds of OWL WG Working Drafts displayed prominently on the W3C’s front page. C&P, which became a W3C member last summer, has been participating in several capacities: as WG members and in more behind-the-scenes roles.

I’m happy about this because I know how much work Working Drafts represent, though in this case I can’t remember many WGs starting off with such mature member submissions (I guess XML Schema did well in that regard, as did XML, in some sense).

We’re especially excited about revising OWL because, from our point of view, such revision is both a cause and effect of modest but appreciable growth in the commercial use of OWL:

1. There is non-trivial new functionality in four areas: syntactic sugar representing common and useful modeling idioms; new core expressivity: the new OWL will be able to say more things that machines can understand; a clean user-defined datatype mechanism, since users want to extend OWL to cover their datatype reasoning needs; and, finally, improved metamodeling and annotation facilities.
2. Crucially, these areas of new functionality have two important properties: first, they are practically motivated by commercial and industrial users of OWL who have hard problems they’re trying to solve; second, they are sanely conceived and backed by theoretical soundess and goodness—much like relational database technology, which is thought to be the apex of technological practicality, is backed by theoretical soundness that the vast majority of RDBMS users will never understand and have no need to understand
3. The part of OWL that we specialize in, OWL DL, is growing and will continue to grow, we believe, because it offers, for some class of problems, a handy bit of kit, as they say. But it’s not intended to, nor will it, solve every problem—not even every problem in the universe of problems for which ontologies are useful. We say this all the time to our customers and they’re generally sophisticated enough to understand it. That’s a good thing.
4. Even more exciting for us and crucial to our users, the OWL WG has on its plate upcoming a set of standardized tractable fragments, which will give users interoperable subsets of OWL expressivity. Those fragments or species are all motivated by use cases and are realistically implementable. We’re implementing some of them for future products and those efforts are proceeding well.

Pellet was among the first OWL reasoners to support OWL 1.1 features, and we’ll continue to make sure it covers the OWL waterfront, including specialized reasoners and data engines for various tractable fragments.

OWL is not going to take over the world; for my money, it doesn’t have to. What it must do, however, for us to continue to invest in it, is solve problems that our customers have, that is, real world problems for which they are happy to part with their real world money—and to do so better than the alternatives.

So we talked about 5 or 6 SemTech 2008 proposals based on our products, services, and technology bits. The guys convinced me that of those 6 ideas, there were 4 actual, strong proposals:

1. A Pellet tutorial
2. A talk about Pronto, our probabilistic reasoner integrated with Pellet
3. A talk about XACML-DL, our XACML policy analyzer
4. A talk about JSpace, our Linked Data browser

I thought we had a very small chance for (1)-(3), but a better than 50% chance for (4); my reasons were based on what typically shows up at SemTech, the interests of the organizers (in my view), and past talks that have been accepted.

Hence, I was a bit surprised when we got notifications today that (1) and (3) were accepted; (4) was not accepted; and we haven’t heard back on (2), though I’m assuming that it won’t be accepted.

(Update: Actually, the talk on Pronto was accepted, they just sent notification quite late. This is interesting because while we think, long term, there is commercial utility here, it really is quite a complex subject. One thing I realized in watching Pavel do this work over the summer is how surprising valid probabilistic reasoning can be.)

The Pellet talk is called “What to do with an OWL Reasoner”, and we’re hopeful there will be people who attend SemTech for whom that’s an interesting question. I was very surprised that the talk on XACML-DL got in, not because it’s not an interesting bit of tech, since it is, but more because we haven’t said much, if anything publicly about it yet. It has no buzz whatever.

We think policy management may be the big win for OWL in the enterprise space; but it’s still very much a dark horse.

Just as a précis: our XACML-DL analyzer, based on Pellet, for a near arbitrary set of XACML policies, can:

• perform formal policy verification and deep testing (think HTTP unit testing, only way sexier);


• perform policy change analysis;


• detect policy redundancy;


• perform policy repair, debugging, and explanation;


• support policy federation (disjointness checking, etc);


• perform policy set optimization.

I’ve recently started saying, to explain the commercial appeal of policy management generally, that every IT solution creates, eventually, a new round of IT problems, and XACML is a perfect example of that. So you’ve moved from procedural and imperative ACL code all over yr enterprise to declarative, orthogonal ACL decision points using XACML. That’s potentially a huge win in programmer productivity, in security quality, and in compliance. But now that you’ve got a few thousand XML files describing yr ACL policies, how the hell are you going to manage them? Are they game-able? Are they coherent? Are there redundancies and, thus, inefficiences?

Who knows and how does one go about finding out?

Those are precisely the kinds of management services for domain-specific policies that OWL is well-suited for, and there lots and lots of such policy languages out there in the world.