W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2009

Re: profiles and the rec track

From: Jim Hendler <hendler@cs.rpi.edu>
Date: Tue, 27 Jan 2009 13:31:09 -0500
Cc: W3C OWL Working Group <public-owl-wg@w3.org>
Message-Id: <5D97C372-0C25-47EF-B802-8666DEB9EFBA@cs.rpi.edu>
To: Bijan Parsia <bparsia@cs.man.ac.uk>

  Let me be clear, I don't doubt any of what you say below, I don't  
have any objection to any of the profiles separately, and I think they  
are all defensible - the thing I worry about is so much coming out at  
the same time - the WG is releasing a major upgrade to OWL,  new  
syntaxes, an XML serialization, 3 new profiles, and whatever else I've  
forgotten -- it makes the "semantic web stack" more complex, at a time  
when we are still working to win hearts and minds, not yet at a point  
where there's huge user demand --- so my recommendation is purely  
political with respect to letting these things out a little at a time,  
rather than all at once.
  Anyone who comes hear you (or even me) talk about all the profiles  
and updates can understand, but to most people it looks like too much  
at once - I think we will get pushback from the AC on this, might be  
wiser to come up with our own plans then to have something imposed on us
   I do believe there are implementations, I do believe we can  
document things - but fwiw, it is not clear to me we would see more  
uptake in the next, let's say 12 months, if EL, QL, and RL are rec  
track vs. they are in a stable WG note with a status saying the will  
eventually move rec track, and that these are expected to be the final  
language designs -- if you think about it, this is what we are doing w/ 
Manchester syntax, if I understand current plans right, and I think it  
worth considering thinking the same w/the profiles -- anyone wanting  
to use them has an interoperable design, and we're not seeing dozens  
of companies putting out ad hoc versions - rather, we have a few big  
players (esp IBM and Oracle) who will help promote and advertise,  
maybe even sooner if we don't have to do the whole CR/PR timing
  I'd welcome thoughts from the reps from these companies esp.

On Jan 27, 2009, at 12:14 PM, Bijan Parsia wrote:

> Just one small point.
> On 27 Jan 2009, at 15:47, Jim Hendler wrote:
> [snip]
>> 2 - there's a lot of question about EL vs DL - again, the primary  
>> explanations are with respect to theoretical performance, but the  
>> AC members aren't interested in that - as one pointed out to me  
>> "there's a lot off polynomial stuff that doesn't work in practice,  
>> and some exponential and undecidables that are in daily use" - he's  
>> right.
> [snip]
> This is, of course, true. But there is fairly extensive experience  
> supporting OWL EL, OWL RL, and OWL QL as robustly scalable. It's not  
> just that they formally toe the line, but that they practically do  
> so. (And even just theoretically, the *way* the have their  
> complexity makes it pretty clear that they are robust...i.e., the  
> likely sources of difficulty are pretty easy to see. For example, a  
> naive OWL QL implementation can die if you have a huge, super deep  
> hierarchy with a moderately sized query involving separate branches  
> (because the query grows exponentially). This is not a likely case  
> given that the likely application area or...actually, at all. Even  
> there, it's pretty straightforward to deal with.)
> There are *at least* three independent implementations of EL++ (CEL,  
> IBM, and in Pellet). All exhibit excellent scaling behavior on all  
> inputs thrown at them (including SNOMED).
> Back in the day, when we were considering what profiles to include,  
> I said that 2 *production quality* interoperable implementations  
> should be the bar. We can define production quality in a number of  
> ways, of course, and include scaling.
> I just what to emphasize that the the rationales are not with  
> respect to *theoretical* performance (though that is part of the  
> story) nor are the *primary* rationales. OWL QL is useless for  
> SNOMED in spite of its theoretical better performance. Hence OWL EL.
> (Please don't respond that SNOMED is a narrow case. I just picked it  
> because it's a clear example, not that it is the only example. It's  
> large, significant, with fairly complex but intelligible modeling.)
> I'd be happy to chat with any AC members who are confused on this  
> point and explain in detail why the performance of these profiles is  
> not merely "theoretically" good.
> Cheers,
> Bijan.

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180
Received on Tuesday, 27 January 2009 18:31:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:08 UTC