OWL 1.1

by Bijan Parsia

One result, by intent, of the OWL: Experiences and Directions workshop is that we have consensus, broadly speaking, on an OWL “1.1”. That is, we agreed on things that the implementors and theorists thought was feasible and the users thought would be (most) useful. Peter Patel-Schneider has written up our consensus in the form of a preliminary specification, namely overview and syntax documents. (Bernardo is working on the updated model theory…that boy is SUCH the busy beaver.) We have commitments from the implementors of four out of five of major reasoners (Pellet, FaCT++, Cerebra and Racer, with the status of KAON2 unknown to me…they might have agreed and I just don’t remember) to try to implement “enough” of the new specs across us by May. Swoop and I imagine Protégé will support the new features as well.

The idea is to create facts on the ground…a new state of the deployed that would feed into a standardization effort (if it seemed necessary!) This is why it was important to get the implementors on board. If we all agree on a syntax and a feature set, then standardization can be quick and easy. The users needed to be on board so we don’t waste our time. None of these feature feed our research agenda at all (since they are, as our fundamental criteria put it, well understood and relatively easy wins), so there needs to be other sorts of reward, like a happy user base.

The overview document does a good job of saying what’s up, but to sum up the main thrust of OWL DL 1.1 is that we move from SHOIN (with limited D) as the underlying description logic to SROIQ (where the D is quite a bit) plus punning, a limited form a metamodeling that pushes annotation properties to the next level. Conceptually, these are relatively small changes well within the spirit of OWL DL (and OWL overall).

There are still issues, of course, in particular the one that has bedeviled OWL and esp. OWL DL from the start: How to deal with RDF (esp. the RDF encoding of the syntax). Especially annoying (to the point that Evren thinks we should drop the feature) is how to write negated role assertions. I.e., that Mary does not love Sally. That not is a pain in triples. The obvious solution is something along the lines of owl:inverseOf…but bleah. (RDF triples are a barrier to other useful extensions, like the K operator. See Jordan’s paper for some details.)

We’re going to have another workshop, again colocated with ISWC, next year. At that point I hope we’ll have 6 months of OWL 1.1 experience to deal with, and can start thinking about OWL 1.2 and more importantly, OWL 2.0. We’ll try to make OWL 1.1 a W3C note/submission and expect it to be an easy win for a future working group.

These are good things: working light and agile; trying to get systems built that have the features people need; and being community driven. Build the consensus first, THEN go to the standards bodies. Anyone may participate in the workshops or on the mailing list—- just recognize that you have to convince some people to donate their time and energy. Our basic principle is that if the implementors aren’t going to do it, then there’s no point in “standardizing” it, even informally. While this does put the “power” in the hands of the implementors, everyone has a chance to weild or influence that power. You can just persuade us. Or you can pay money to the Racer or Cerebra or KAON guys. Or you can roll up your sleeves and dive into the Pellet, FaCT++, Swoop, or Protégé code (they are all open source), or write your own tool! Or pay someone to work on the open source tools. Windging, whining, bullying, complaining of unfairness are off the table. I and the all the folks at Mindswap are happy to help get people into our code!

Torture, abrogating laws at whim, domestic spying without oversite, and endless detention without trial—- just four simple reasons (out of many) for outrage. If you need a little anti-Democrat joy as well, consider not just how they rolled over for all this, but also Waco and the Clinton continuation of sanctions against Iraq.

67 Responses to “OWL 1.1”

  1. Dan Connolly Says:

    Have you looked at the W3C XG/incubator process? I’d like to think it’s appealing to your sort of group.

  2. Dan Connolly Says:

    Have you looked at the W3C XG/incubator process? I’d like to think it’s appealing to your sort of group.

  3. Dan Connolly Says:

    Have you looked at the W3C XG/incubator process? I’d like to think it’s appealing to your sort of group.

  4. Dan Connolly Says:

    Have you looked at the W3C XG/incubator process? I’d like to think it’s appealing to your sort of group.

  5. Dan Connolly Says:

    Have you looked at the W3C XG/incubator process? I’d like to think it’s appealing to your sort of group.

  6. Dan Connolly Says:

    I’m getting 404’s on the overview and syntax docs.

  7. Dan Connolly Says:

    I’m getting 404’s on the overview and syntax docs.

  8. Dan Connolly Says:

    I’m getting 404’s on the overview and syntax docs.

  9. Dan Connolly Says:

    I’m getting 404’s on the overview and syntax docs.

  10. Dan Connolly Says:

    I’m getting 404’s on the overview and syntax docs.

  11. Duncan Hull Says:

    Hi Bijan, I look forward to using OWL 1.1 when it arrives, the links to Peters overview and syntax are dead, do you know where they moved to? Duncan

  12. Duncan Hull Says:

    Hi Bijan, I look forward to using OWL 1.1 when it arrives, the links to Peters overview and syntax are dead, do you know where they moved to? Duncan

  13. Duncan Hull Says:

    Hi Bijan, I look forward to using OWL 1.1 when it arrives, the links to Peters overview and syntax are dead, do you know where they moved to? Duncan

  14. Duncan Hull Says:

    Hi Bijan, I look forward to using OWL 1.1 when it arrives, the links to Peters overview and syntax are dead, do you know where they moved to? Duncan

  15. Duncan Hull Says:

    Hi Bijan, I look forward to using OWL 1.1 when it arrives, the links to Peters overview and syntax are dead, do you know where they moved to? Duncan

  16. Dan Connolly Says:

    Have you looked at the W3C XG/incubator process? I’d like to think it’s appealing to your sort of group.

  17. Dan Connolly Says:

    I’m getting 404’s on the overview and syntax docs.

  18. Duncan Hull Says:

    Hi Bijan, I look forward to using OWL 1.1 when it arrives, the links to Peters overview and syntax are dead, do you know where they moved to? Duncan

  19. Danny Says:

    IANAL, so there may be perfectly obvious justifications for moving to OWL 1.1. But I am involved with development on the web, and it seems mighty strange to me that 1.1 is under discussion (even 1.2, 2.0) when there are – how many? – I’d guess not many more than 10 implementations of OWL 1.0 reasoners. What are the features people need? Where is the community drive in this direction? I’m not suggesting there’s necessarily anything wrong with these developments, it’s just hard to see what’s right.

  20. Danny Says:

    IANAL, so there may be perfectly obvious justifications for moving to OWL 1.1. But I am involved with development on the web, and it seems mighty strange to me that 1.1 is under discussion (even 1.2, 2.0) when there are – how many? – I’d guess not many more than 10 implementations of OWL 1.0 reasoners. What are the features people need? Where is the community drive in this direction? I’m not suggesting there’s necessarily anything wrong with these developments, it’s just hard to see what’s right.

  21. Danny Says:

    IANAL, so there may be perfectly obvious justifications for moving to OWL 1.1. But I am involved with development on the web, and it seems mighty strange to me that 1.1 is under discussion (even 1.2, 2.0) when there are – how many? – I’d guess not many more than 10 implementations of OWL 1.0 reasoners. What are the features people need? Where is the community drive in this direction? I’m not suggesting there’s necessarily anything wrong with these developments, it’s just hard to see what’s right.

  22. Danny Says:

    IANAL, so there may be perfectly obvious justifications for moving to OWL 1.1. But I am involved with development on the web, and it seems mighty strange to me that 1.1 is under discussion (even 1.2, 2.0) when there are – how many? – I’d guess not many more than 10 implementations of OWL 1.0 reasoners. What are the features people need? Where is the community drive in this direction? I’m not suggesting there’s necessarily anything wrong with these developments, it’s just hard to see what’s right.

  23. Danny Says:

    IANAL, so there may be perfectly obvious justifications for moving to OWL 1.1. But I am involved with development on the web, and it seems mighty strange to me that 1.1 is under discussion (even 1.2, 2.0) when there are – how many? – I’d guess not many more than 10 implementations of OWL 1.0 reasoners. What are the features people need? Where is the community drive in this direction? I’m not suggesting there’s necessarily anything wrong with these developments, it’s just hard to see what’s right.

  24. Danny Says:

    PS. I’ve found the “Irresistible SROIQ” paper – anything else you’d recommend? (Ideally more clearly related to real-world issues with SHOIN).

  25. Danny Says:

    PS. I’ve found the “Irresistible SROIQ” paper – anything else you’d recommend? (Ideally more clearly related to real-world issues with SHOIN).

  26. Danny Says:

    PS. I’ve found the “Irresistible SROIQ” paper – anything else you’d recommend? (Ideally more clearly related to real-world issues with SHOIN).

  27. Danny Says:

    PS. I’ve found the “Irresistible SROIQ” paper – anything else you’d recommend? (Ideally more clearly related to real-world issues with SHOIN).

  28. Danny Says:

    PS. I’ve found the “Irresistible SROIQ” paper – anything else you’d recommend? (Ideally more clearly related to real-world issues with SHOIN).

  29. bijan Says:

    The Syntax and Overview links are live now, they are also attached to the email Peter sent annoucing them. (I’ll email all the queriers about them to let them know).

    Re: justification. Er…why must there be 10 reasoners before we add features? Features aren’t driven by implementations, but by use cases, and these extentions were all requested by users at the workshop. So that’s the community drive. Believe me, no implementor wants to do these features because, by and large, they are not theoretically interesting. We won’t be writing all that many papers about these (that aren’t systems paper). Actually, that was perfectly clear in my post, so I don’t understand, Danny, why you don’t get it :)

    Besides, once you have two, if you don’t want to fragment the community, you have to coordinate. We are a small enough community that we can coordinate the way we are doing. What’s wrong with that? One reason we didn’t move to an incubator group (well, ok, they weren’t quite ready yet) is that we want to be as light weight as possible and try to grow the market (and the state of the art). It’s possible that not all the features we develop here will make it into a W3C specification. (Maybe they’ll turn out to be bad ideas, though I think only punning might have problems.)

    (“Real” reasoners out there are Racer, Pellet, FaCT++, Cerebra engine, and KAON2…that I know of. 3 of these are commercially supported! All are under active development (well, KAON2 might see a hiatus, but I believe Boris intends to keep it going). This is indicative to me of a healthy market. That’s up from 1 commercial one when OWL went to Rec and only 3 (Racer, Cerebra and the aging FaCT) when OWL started/went to last call/went to CR even, though Pellet might have been there by then in a preliminary form.)

    One other 1.1 task is to identify useful but tractable subsets of owl (e.g., the EL family, or DL Lite). I think this will spawn a new user community and several new implementations.

  30. bijan Says:

    The Syntax and Overview links are live now, they are also attached to the email Peter sent annoucing them. (I’ll email all the queriers about them to let them know).

    Re: justification. Er…why must there be 10 reasoners before we add features? Features aren’t driven by implementations, but by use cases, and these extentions were all requested by users at the workshop. So that’s the community drive. Believe me, no implementor wants to do these features because, by and large, they are not theoretically interesting. We won’t be writing all that many papers about these (that aren’t systems paper). Actually, that was perfectly clear in my post, so I don’t understand, Danny, why you don’t get it :)

    Besides, once you have two, if you don’t want to fragment the community, you have to coordinate. We are a small enough community that we can coordinate the way we are doing. What’s wrong with that? One reason we didn’t move to an incubator group (well, ok, they weren’t quite ready yet) is that we want to be as light weight as possible and try to grow the market (and the state of the art). It’s possible that not all the features we develop here will make it into a W3C specification. (Maybe they’ll turn out to be bad ideas, though I think only punning might have problems.)

    (“Real” reasoners out there are Racer, Pellet, FaCT++, Cerebra engine, and KAON2…that I know of. 3 of these are commercially supported! All are under active development (well, KAON2 might see a hiatus, but I believe Boris intends to keep it going). This is indicative to me of a healthy market. That’s up from 1 commercial one when OWL went to Rec and only 3 (Racer, Cerebra and the aging FaCT) when OWL started/went to last call/went to CR even, though Pellet might have been there by then in a preliminary form.)

    One other 1.1 task is to identify useful but tractable subsets of owl (e.g., the EL family, or DL Lite). I think this will spawn a new user community and several new implementations.

  31. bijan Says:

    The Syntax and Overview links are live now, they are also attached to the email Peter sent annoucing them. (I’ll email all the queriers about them to let them know).

    Re: justification. Er…why must there be 10 reasoners before we add features? Features aren’t driven by implementations, but by use cases, and these extentions were all requested by users at the workshop. So that’s the community drive. Believe me, no implementor wants to do these features because, by and large, they are not theoretically interesting. We won’t be writing all that many papers about these (that aren’t systems paper). Actually, that was perfectly clear in my post, so I don’t understand, Danny, why you don’t get it :)

    Besides, once you have two, if you don’t want to fragment the community, you have to coordinate. We are a small enough community that we can coordinate the way we are doing. What’s wrong with that? One reason we didn’t move to an incubator group (well, ok, they weren’t quite ready yet) is that we want to be as light weight as possible and try to grow the market (and the state of the art). It’s possible that not all the features we develop here will make it into a W3C specification. (Maybe they’ll turn out to be bad ideas, though I think only punning might have problems.)

    (“Real” reasoners out there are Racer, Pellet, FaCT++, Cerebra engine, and KAON2…that I know of. 3 of these are commercially supported! All are under active development (well, KAON2 might see a hiatus, but I believe Boris intends to keep it going). This is indicative to me of a healthy market. That’s up from 1 commercial one when OWL went to Rec and only 3 (Racer, Cerebra and the aging FaCT) when OWL started/went to last call/went to CR even, though Pellet might have been there by then in a preliminary form.)

    One other 1.1 task is to identify useful but tractable subsets of owl (e.g., the EL family, or DL Lite). I think this will spawn a new user community and several new implementations.

  32. bijan Says:

    The Syntax and Overview links are live now, they are also attached to the email Peter sent annoucing them. (I’ll email all the queriers about them to let them know).

    Re: justification. Er…why must there be 10 reasoners before we add features? Features aren’t driven by implementations, but by use cases, and these extentions were all requested by users at the workshop. So that’s the community drive. Believe me, no implementor wants to do these features because, by and large, they are not theoretically interesting. We won’t be writing all that many papers about these (that aren’t systems paper). Actually, that was perfectly clear in my post, so I don’t understand, Danny, why you don’t get it :)

    Besides, once you have two, if you don’t want to fragment the community, you have to coordinate. We are a small enough community that we can coordinate the way we are doing. What’s wrong with that? One reason we didn’t move to an incubator group (well, ok, they weren’t quite ready yet) is that we want to be as light weight as possible and try to grow the market (and the state of the art). It’s possible that not all the features we develop here will make it into a W3C specification. (Maybe they’ll turn out to be bad ideas, though I think only punning might have problems.)

    (“Real” reasoners out there are Racer, Pellet, FaCT++, Cerebra engine, and KAON2…that I know of. 3 of these are commercially supported! All are under active development (well, KAON2 might see a hiatus, but I believe Boris intends to keep it going). This is indicative to me of a healthy market. That’s up from 1 commercial one when OWL went to Rec and only 3 (Racer, Cerebra and the aging FaCT) when OWL started/went to last call/went to CR even, though Pellet might have been there by then in a preliminary form.)

    One other 1.1 task is to identify useful but tractable subsets of owl (e.g., the EL family, or DL Lite). I think this will spawn a new user community and several new implementations.

  33. bijan Says:

    The Syntax and Overview links are live now, they are also attached to the email Peter sent annoucing them. (I’ll email all the queriers about them to let them know).

    Re: justification. Er…why must there be 10 reasoners before we add features? Features aren’t driven by implementations, but by use cases, and these extentions were all requested by users at the workshop. So that’s the community drive. Believe me, no implementor wants to do these features because, by and large, they are not theoretically interesting. We won’t be writing all that many papers about these (that aren’t systems paper). Actually, that was perfectly clear in my post, so I don’t understand, Danny, why you don’t get it :)

    Besides, once you have two, if you don’t want to fragment the community, you have to coordinate. We are a small enough community that we can coordinate the way we are doing. What’s wrong with that? One reason we didn’t move to an incubator group (well, ok, they weren’t quite ready yet) is that we want to be as light weight as possible and try to grow the market (and the state of the art). It’s possible that not all the features we develop here will make it into a W3C specification. (Maybe they’ll turn out to be bad ideas, though I think only punning might have problems.)

    (“Real” reasoners out there are Racer, Pellet, FaCT++, Cerebra engine, and KAON2…that I know of. 3 of these are commercially supported! All are under active development (well, KAON2 might see a hiatus, but I believe Boris intends to keep it going). This is indicative to me of a healthy market. That’s up from 1 commercial one when OWL went to Rec and only 3 (Racer, Cerebra and the aging FaCT) when OWL started/went to last call/went to CR even, though Pellet might have been there by then in a preliminary form.)

    One other 1.1 task is to identify useful but tractable subsets of owl (e.g., the EL family, or DL Lite). I think this will spawn a new user community and several new implementations.

  34. bijan Says:

    Re: utility. Two core features are simply obvious things that should have or almost are in OWL: Qualified cardinality restrictions and user defined datatypes. QCRs were in daml+oil and are hugely important to bioinformatics applications (e.g.,
    “In contrast, a limitation in the expressive power of OWL-DL did cause con-
    siderable problems: the lack of qualified number restrictions (also called qualified cardinality restrictions).” in “A little semantics goes a long way in Biology”). Similarly, there are tons of requests for real user defined datatypes. In either case, the details are less important than agreement between the implemntors.

    The rest of the SROIQ stuff seemed both useful and easy. Having limited “triagnle” property composition gives you some useful “rule like” axioms.

    Given the minorness and the nice “rounding out” there was no reason not to add them.

  35. bijan Says:

    Re: utility. Two core features are simply obvious things that should have or almost are in OWL: Qualified cardinality restrictions and user defined datatypes. QCRs were in daml+oil and are hugely important to bioinformatics applications (e.g.,
    “In contrast, a limitation in the expressive power of OWL-DL did cause con-
    siderable problems: the lack of qualified number restrictions (also called qualified cardinality restrictions).” in “A little semantics goes a long way in Biology”). Similarly, there are tons of requests for real user defined datatypes. In either case, the details are less important than agreement between the implemntors.

    The rest of the SROIQ stuff seemed both useful and easy. Having limited “triagnle” property composition gives you some useful “rule like” axioms.

    Given the minorness and the nice “rounding out” there was no reason not to add them.

  36. bijan Says:

    Re: utility. Two core features are simply obvious things that should have or almost are in OWL: Qualified cardinality restrictions and user defined datatypes. QCRs were in daml+oil and are hugely important to bioinformatics applications (e.g.,
    “In contrast, a limitation in the expressive power of OWL-DL did cause con-
    siderable problems: the lack of qualified number restrictions (also called qualified cardinality restrictions).” in “A little semantics goes a long way in Biology”). Similarly, there are tons of requests for real user defined datatypes. In either case, the details are less important than agreement between the implemntors.

    The rest of the SROIQ stuff seemed both useful and easy. Having limited “triagnle” property composition gives you some useful “rule like” axioms.

    Given the minorness and the nice “rounding out” there was no reason not to add them.

  37. bijan Says:

    Re: utility. Two core features are simply obvious things that should have or almost are in OWL: Qualified cardinality restrictions and user defined datatypes. QCRs were in daml+oil and are hugely important to bioinformatics applications (e.g.,
    “In contrast, a limitation in the expressive power of OWL-DL did cause con-
    siderable problems: the lack of qualified number restrictions (also called qualified cardinality restrictions).” in “A little semantics goes a long way in Biology”). Similarly, there are tons of requests for real user defined datatypes. In either case, the details are less important than agreement between the implemntors.

    The rest of the SROIQ stuff seemed both useful and easy. Having limited “triagnle” property composition gives you some useful “rule like” axioms.

    Given the minorness and the nice “rounding out” there was no reason not to add them.

  38. bijan Says:

    Re: utility. Two core features are simply obvious things that should have or almost are in OWL: Qualified cardinality restrictions and user defined datatypes. QCRs were in daml+oil and are hugely important to bioinformatics applications (e.g.,
    “In contrast, a limitation in the expressive power of OWL-DL did cause con-
    siderable problems: the lack of qualified number restrictions (also called qualified cardinality restrictions).” in “A little semantics goes a long way in Biology”). Similarly, there are tons of requests for real user defined datatypes. In either case, the details are less important than agreement between the implemntors.

    The rest of the SROIQ stuff seemed both useful and easy. Having limited “triagnle” property composition gives you some useful “rule like” axioms.

    Given the minorness and the nice “rounding out” there was no reason not to add them.

  39. Danny Says:

    Thanks Bijan.

    The bioinformatics case sounds reasonable, but I’m afraid a lot of the rest sounds like adding stuff because it’s possible, because it looks good on paper. Stable specifications, a decent number of implementations, web-wide practical application of these technologies…shouldn’t they come before version 1.1?

    I do think the number of implementations is a point of note, in that they are a way of exploring the territory – not necessarily the territory of the DL community, but of the web community at large. For that wider community, I’d have thought things like looking at tractable subsets would certainly be valuable, in contrast to presenting a moving target of this year’s model and theory – “DL2010…An Existential Odyssey”, if you get my drift.

    I guess my basic concern is whether more engineering will somehow lead to more deployment, bring the SW closer, or just make life that much more confusing for the vast majority of relatively non-expert application implementers. I wish I didn’t sound so negative about what I’m sure is valuable work. But when I look at the Web now I don’t see a clear requirement for qualified cardinality restrictions or whatever, rather an environment crying out for a clear route towards adding semantics of any sort.

  40. Danny Says:

    Thanks Bijan.

    The bioinformatics case sounds reasonable, but I’m afraid a lot of the rest sounds like adding stuff because it’s possible, because it looks good on paper. Stable specifications, a decent number of implementations, web-wide practical application of these technologies…shouldn’t they come before version 1.1?

    I do think the number of implementations is a point of note, in that they are a way of exploring the territory – not necessarily the territory of the DL community, but of the web community at large. For that wider community, I’d have thought things like looking at tractable subsets would certainly be valuable, in contrast to presenting a moving target of this year’s model and theory – “DL2010…An Existential Odyssey”, if you get my drift.

    I guess my basic concern is whether more engineering will somehow lead to more deployment, bring the SW closer, or just make life that much more confusing for the vast majority of relatively non-expert application implementers. I wish I didn’t sound so negative about what I’m sure is valuable work. But when I look at the Web now I don’t see a clear requirement for qualified cardinality restrictions or whatever, rather an environment crying out for a clear route towards adding semantics of any sort.

  41. Danny Says:

    Thanks Bijan.

    The bioinformatics case sounds reasonable, but I’m afraid a lot of the rest sounds like adding stuff because it’s possible, because it looks good on paper. Stable specifications, a decent number of implementations, web-wide practical application of these technologies…shouldn’t they come before version 1.1?

    I do think the number of implementations is a point of note, in that they are a way of exploring the territory – not necessarily the territory of the DL community, but of the web community at large. For that wider community, I’d have thought things like looking at tractable subsets would certainly be valuable, in contrast to presenting a moving target of this year’s model and theory – “DL2010…An Existential Odyssey”, if you get my drift.

    I guess my basic concern is whether more engineering will somehow lead to more deployment, bring the SW closer, or just make life that much more confusing for the vast majority of relatively non-expert application implementers. I wish I didn’t sound so negative about what I’m sure is valuable work. But when I look at the Web now I don’t see a clear requirement for qualified cardinality restrictions or whatever, rather an environment crying out for a clear route towards adding semantics of any sort.

  42. Danny Says:

    Thanks Bijan.

    The bioinformatics case sounds reasonable, but I’m afraid a lot of the rest sounds like adding stuff because it’s possible, because it looks good on paper. Stable specifications, a decent number of implementations, web-wide practical application of these technologies…shouldn’t they come before version 1.1?

    I do think the number of implementations is a point of note, in that they are a way of exploring the territory – not necessarily the territory of the DL community, but of the web community at large. For that wider community, I’d have thought things like looking at tractable subsets would certainly be valuable, in contrast to presenting a moving target of this year’s model and theory – “DL2010…An Existential Odyssey”, if you get my drift.

    I guess my basic concern is whether more engineering will somehow lead to more deployment, bring the SW closer, or just make life that much more confusing for the vast majority of relatively non-expert application implementers. I wish I didn’t sound so negative about what I’m sure is valuable work. But when I look at the Web now I don’t see a clear requirement for qualified cardinality restrictions or whatever, rather an environment crying out for a clear route towards adding semantics of any sort.

  43. Danny Says:

    Thanks Bijan.

    The bioinformatics case sounds reasonable, but I’m afraid a lot of the rest sounds like adding stuff because it’s possible, because it looks good on paper. Stable specifications, a decent number of implementations, web-wide practical application of these technologies…shouldn’t they come before version 1.1?

    I do think the number of implementations is a point of note, in that they are a way of exploring the territory – not necessarily the territory of the DL community, but of the web community at large. For that wider community, I’d have thought things like looking at tractable subsets would certainly be valuable, in contrast to presenting a moving target of this year’s model and theory – “DL2010…An Existential Odyssey”, if you get my drift.

    I guess my basic concern is whether more engineering will somehow lead to more deployment, bring the SW closer, or just make life that much more confusing for the vast majority of relatively non-expert application implementers. I wish I didn’t sound so negative about what I’m sure is valuable work. But when I look at the Web now I don’t see a clear requirement for qualified cardinality restrictions or whatever, rather an environment crying out for a clear route towards adding semantics of any sort.

  44. bijan Says:

    I started replying point by point, but, eh, it’s pointless. :)

    I don’t see you’ve raised a remotely salient point: “web wide practical application” is not a pre-requisite for vendors to coordinate the support of their uses, which is what we did. There were over 60 people at the OWL Workshop and consensus was overwhelming for this course of action (there was one person I recall expressing some similar meta qualms about it, and he participated with verve in the selection of things to go into 1.1.) So, we have users…why shouldn’t we support them? In contrast, you don’t seem to be an OWL user…why should I worry about your qualms? You don’t see a need for the expressiveness, a load of other people do.

    I find your dismissal of the number of implementations as indecent just silly. I don’t know what else to say about that. There are three companies selling OWL reasoners and two open source implementations. All of these are independently developed.

    As for making it more confusing for non-expert application implementers…how so? If you are an ontology developer, learn the new features and use them if you need them. If you don’t need them, don’t use them. Really, this just seems to be a non sequitur.

    In case it isn’t clear, I’m not remotely swayed by your qualms. So don’t bother repeating them :) I have been somewhat swayed by worries that calling it “OWL 1.1” (or OWL 2.0) might slow adoption because it makes it seem like OWL isn’t finished. That’s one reason for not taking it to a standards body (yet). This is just users and implementors getting together…what’s the harm?

    (I don’t buy the slow adoption argument, though I don’t have conclusive evidence either way. I’ve heard people argue that not adding stuff slows adoption because it makes OWL seem stagnant. I know it slows adoption by people who need more expressiveness.)

    (It would be interesting to shift it into an incubator group. I’m not sure it’s the best idea. The other point is that we wanted this to be very lightweight and inexpensive, whereas a normal working group is very expensive. An incubator group might be as cheap as an Oasis TC, which would be reasonable.)

  45. bijan Says:

    I started replying point by point, but, eh, it’s pointless. :)

    I don’t see you’ve raised a remotely salient point: “web wide practical application” is not a pre-requisite for vendors to coordinate the support of their uses, which is what we did. There were over 60 people at the OWL Workshop and consensus was overwhelming for this course of action (there was one person I recall expressing some similar meta qualms about it, and he participated with verve in the selection of things to go into 1.1.) So, we have users…why shouldn’t we support them? In contrast, you don’t seem to be an OWL user…why should I worry about your qualms? You don’t see a need for the expressiveness, a load of other people do.

    I find your dismissal of the number of implementations as indecent just silly. I don’t know what else to say about that. There are three companies selling OWL reasoners and two open source implementations. All of these are independently developed.

    As for making it more confusing for non-expert application implementers…how so? If you are an ontology developer, learn the new features and use them if you need them. If you don’t need them, don’t use them. Really, this just seems to be a non sequitur.

    In case it isn’t clear, I’m not remotely swayed by your qualms. So don’t bother repeating them :) I have been somewhat swayed by worries that calling it “OWL 1.1” (or OWL 2.0) might slow adoption because it makes it seem like OWL isn’t finished. That’s one reason for not taking it to a standards body (yet). This is just users and implementors getting together…what’s the harm?

    (I don’t buy the slow adoption argument, though I don’t have conclusive evidence either way. I’ve heard people argue that not adding stuff slows adoption because it makes OWL seem stagnant. I know it slows adoption by people who need more expressiveness.)

    (It would be interesting to shift it into an incubator group. I’m not sure it’s the best idea. The other point is that we wanted this to be very lightweight and inexpensive, whereas a normal working group is very expensive. An incubator group might be as cheap as an Oasis TC, which would be reasonable.)

  46. bijan Says:

    I started replying point by point, but, eh, it’s pointless. :)

    I don’t see you’ve raised a remotely salient point: “web wide practical application” is not a pre-requisite for vendors to coordinate the support of their uses, which is what we did. There were over 60 people at the OWL Workshop and consensus was overwhelming for this course of action (there was one person I recall expressing some similar meta qualms about it, and he participated with verve in the selection of things to go into 1.1.) So, we have users…why shouldn’t we support them? In contrast, you don’t seem to be an OWL user…why should I worry about your qualms? You don’t see a need for the expressiveness, a load of other people do.

    I find your dismissal of the number of implementations as indecent just silly. I don’t know what else to say about that. There are three companies selling OWL reasoners and two open source implementations. All of these are independently developed.

    As for making it more confusing for non-expert application implementers…how so? If you are an ontology developer, learn the new features and use them if you need them. If you don’t need them, don’t use them. Really, this just seems to be a non sequitur.

    In case it isn’t clear, I’m not remotely swayed by your qualms. So don’t bother repeating them :) I have been somewhat swayed by worries that calling it “OWL 1.1” (or OWL 2.0) might slow adoption because it makes it seem like OWL isn’t finished. That’s one reason for not taking it to a standards body (yet). This is just users and implementors getting together…what’s the harm?

    (I don’t buy the slow adoption argument, though I don’t have conclusive evidence either way. I’ve heard people argue that not adding stuff slows adoption because it makes OWL seem stagnant. I know it slows adoption by people who need more expressiveness.)

    (It would be interesting to shift it into an incubator group. I’m not sure it’s the best idea. The other point is that we wanted this to be very lightweight and inexpensive, whereas a normal working group is very expensive. An incubator group might be as cheap as an Oasis TC, which would be reasonable.)

  47. bijan Says:

    I started replying point by point, but, eh, it’s pointless. :)

    I don’t see you’ve raised a remotely salient point: “web wide practical application” is not a pre-requisite for vendors to coordinate the support of their uses, which is what we did. There were over 60 people at the OWL Workshop and consensus was overwhelming for this course of action (there was one person I recall expressing some similar meta qualms about it, and he participated with verve in the selection of things to go into 1.1.) So, we have users…why shouldn’t we support them? In contrast, you don’t seem to be an OWL user…why should I worry about your qualms? You don’t see a need for the expressiveness, a load of other people do.

    I find your dismissal of the number of implementations as indecent just silly. I don’t know what else to say about that. There are three companies selling OWL reasoners and two open source implementations. All of these are independently developed.

    As for making it more confusing for non-expert application implementers…how so? If you are an ontology developer, learn the new features and use them if you need them. If you don’t need them, don’t use them. Really, this just seems to be a non sequitur.

    In case it isn’t clear, I’m not remotely swayed by your qualms. So don’t bother repeating them :) I have been somewhat swayed by worries that calling it “OWL 1.1” (or OWL 2.0) might slow adoption because it makes it seem like OWL isn’t finished. That’s one reason for not taking it to a standards body (yet). This is just users and implementors getting together…what’s the harm?

    (I don’t buy the slow adoption argument, though I don’t have conclusive evidence either way. I’ve heard people argue that not adding stuff slows adoption because it makes OWL seem stagnant. I know it slows adoption by people who need more expressiveness.)

    (It would be interesting to shift it into an incubator group. I’m not sure it’s the best idea. The other point is that we wanted this to be very lightweight and inexpensive, whereas a normal working group is very expensive. An incubator group might be as cheap as an Oasis TC, which would be reasonable.)

  48. bijan Says:

    I started replying point by point, but, eh, it’s pointless. :)

    I don’t see you’ve raised a remotely salient point: “web wide practical application” is not a pre-requisite for vendors to coordinate the support of their uses, which is what we did. There were over 60 people at the OWL Workshop and consensus was overwhelming for this course of action (there was one person I recall expressing some similar meta qualms about it, and he participated with verve in the selection of things to go into 1.1.) So, we have users…why shouldn’t we support them? In contrast, you don’t seem to be an OWL user…why should I worry about your qualms? You don’t see a need for the expressiveness, a load of other people do.

    I find your dismissal of the number of implementations as indecent just silly. I don’t know what else to say about that. There are three companies selling OWL reasoners and two open source implementations. All of these are independently developed.

    As for making it more confusing for non-expert application implementers…how so? If you are an ontology developer, learn the new features and use them if you need them. If you don’t need them, don’t use them. Really, this just seems to be a non sequitur.

    In case it isn’t clear, I’m not remotely swayed by your qualms. So don’t bother repeating them :) I have been somewhat swayed by worries that calling it “OWL 1.1” (or OWL 2.0) might slow adoption because it makes it seem like OWL isn’t finished. That’s one reason for not taking it to a standards body (yet). This is just users and implementors getting together…what’s the harm?

    (I don’t buy the slow adoption argument, though I don’t have conclusive evidence either way. I’ve heard people argue that not adding stuff slows adoption because it makes OWL seem stagnant. I know it slows adoption by people who need more expressiveness.)

    (It would be interesting to shift it into an incubator group. I’m not sure it’s the best idea. The other point is that we wanted this to be very lightweight and inexpensive, whereas a normal working group is very expensive. An incubator group might be as cheap as an Oasis TC, which would be reasonable.)

  49. Danny Says:

    Ok, maybe I’m wrong to be concerned about this, and I don’t expect to sway you. Certainly when you hide the OWL 1.1/2.0 label the effort has a different complexion, and development in this area is undeniably a good thing. But I am an OWL user, and probably more to the point am an active web developer who believes the SW vision is a very good idea. With all due respect, the requirements of a self-selected group of existing OWL theoreticians and users may not reflect the requirements of the Semantic Web. Again I could be wrong, but there’s a scent of fragmentation here, and that makes me nervous.

  50. Danny Says:

    Ok, maybe I’m wrong to be concerned about this, and I don’t expect to sway you. Certainly when you hide the OWL 1.1/2.0 label the effort has a different complexion, and development in this area is undeniably a good thing. But I am an OWL user, and probably more to the point am an active web developer who believes the SW vision is a very good idea. With all due respect, the requirements of a self-selected group of existing OWL theoreticians and users may not reflect the requirements of the Semantic Web. Again I could be wrong, but there’s a scent of fragmentation here, and that makes me nervous.

  51. Danny Says:

    Ok, maybe I’m wrong to be concerned about this, and I don’t expect to sway you. Certainly when you hide the OWL 1.1/2.0 label the effort has a different complexion, and development in this area is undeniably a good thing. But I am an OWL user, and probably more to the point am an active web developer who believes the SW vision is a very good idea. With all due respect, the requirements of a self-selected group of existing OWL theoreticians and users may not reflect the requirements of the Semantic Web. Again I could be wrong, but there’s a scent of fragmentation here, and that makes me nervous.

  52. Danny Says:

    Ok, maybe I’m wrong to be concerned about this, and I don’t expect to sway you. Certainly when you hide the OWL 1.1/2.0 label the effort has a different complexion, and development in this area is undeniably a good thing. But I am an OWL user, and probably more to the point am an active web developer who believes the SW vision is a very good idea. With all due respect, the requirements of a self-selected group of existing OWL theoreticians and users may not reflect the requirements of the Semantic Web. Again I could be wrong, but there’s a scent of fragmentation here, and that makes me nervous.

  53. Danny Says:

    Ok, maybe I’m wrong to be concerned about this, and I don’t expect to sway you. Certainly when you hide the OWL 1.1/2.0 label the effort has a different complexion, and development in this area is undeniably a good thing. But I am an OWL user, and probably more to the point am an active web developer who believes the SW vision is a very good idea. With all due respect, the requirements of a self-selected group of existing OWL theoreticians and users may not reflect the requirements of the Semantic Web. Again I could be wrong, but there’s a scent of fragmentation here, and that makes me nervous.

  54. Danny Says:

    IANAL, so there may be perfectly obvious justifications for moving to OWL 1.1. But I am involved with development on the web, and it seems mighty strange to me that 1.1 is under discussion (even 1.2, 2.0) when there are – how many? – I’d guess not many more than 10 implementations of OWL 1.0 reasoners. What are the features people need? Where is the community drive in this direction? I’m not suggesting there’s necessarily anything wrong with these developments, it’s just hard to see what’s right.

  55. Danny Says:

    PS. I’ve found the “Irresistible SROIQ” paper – anything else you’d recommend? (Ideally more clearly related to real-world issues with SHOIN).

  56. bijan Says:

    The Syntax and Overview links are live now, they are also attached to the email Peter sent annoucing them. (I’ll email all the queriers about them to let them know).

    Re: justification. Er…why must there be 10 reasoners before we add features? Features aren’t driven by implementations, but by use cases, and these extentions were all requested by users at the workshop. So that’s the community drive. Believe me, no implementor wants to do these features because, by and large, they are not theoretically interesting. We won’t be writing all that many papers about these (that aren’t systems paper). Actually, that was perfectly clear in my post, so I don’t understand, Danny, why you don’t get it :)

    Besides, once you have two, if you don’t want to fragment the community, you have to coordinate. We are a small enough community that we can coordinate the way we are doing. What’s wrong with that? One reason we didn’t move to an incubator group (well, ok, they weren’t quite ready yet) is that we want to be as light weight as possible and try to grow the market (and the state of the art). It’s possible that not all the features we develop here will make it into a W3C specification. (Maybe they’ll turn out to be bad ideas, though I think only punning might have problems.)

    (“Real” reasoners out there are Racer, Pellet, FaCT++, Cerebra engine, and KAON2…that I know of. 3 of these are commercially supported! All are under active development (well, KAON2 might see a hiatus, but I believe Boris intends to keep it going). This is indicative to me of a healthy market. That’s up from 1 commercial one when OWL went to Rec and only 3 (Racer, Cerebra and the aging FaCT) when OWL started/went to last call/went to CR even, though Pellet might have been there by then in a preliminary form.)

    One other 1.1 task is to identify useful but tractable subsets of owl (e.g., the EL family, or DL Lite). I think this will spawn a new user community and several new implementations.

  57. bijan Says:

    Re: utility. Two core features are simply obvious things that should have or almost are in OWL: Qualified cardinality restrictions and user defined datatypes. QCRs were in daml+oil and are hugely important to bioinformatics applications (e.g.,
    “In contrast, a limitation in the expressive power of OWL-DL did cause con-
    siderable problems: the lack of qualified number restrictions (also called qualified cardinality restrictions).” in “A little semantics goes a long way in Biology”). Similarly, there are tons of requests for real user defined datatypes. In either case, the details are less important than agreement between the implemntors.

    The rest of the SROIQ stuff seemed both useful and easy. Having limited “triagnle” property composition gives you some useful “rule like” axioms.

    Given the minorness and the nice “rounding out” there was no reason not to add them.

  58. Danny Says:

    Thanks Bijan.

    The bioinformatics case sounds reasonable, but I’m afraid a lot of the rest sounds like adding stuff because it’s possible, because it looks good on paper. Stable specifications, a decent number of implementations, web-wide practical application of these technologies…shouldn’t they come before version 1.1?

    I do think the number of implementations is a point of note, in that they are a way of exploring the territory – not necessarily the territory of the DL community, but of the web community at large. For that wider community, I’d have thought things like looking at tractable subsets would certainly be valuable, in contrast to presenting a moving target of this year’s model and theory – “DL2010…An Existential Odyssey”, if you get my drift.

    I guess my basic concern is whether more engineering will somehow lead to more deployment, bring the SW closer, or just make life that much more confusing for the vast majority of relatively non-expert application implementers. I wish I didn’t sound so negative about what I’m sure is valuable work. But when I look at the Web now I don’t see a clear requirement for qualified cardinality restrictions or whatever, rather an environment crying out for a clear route towards adding semantics of any sort.

  59. bijan Says:

    I started replying point by point, but, eh, it’s pointless. :)

    I don’t see you’ve raised a remotely salient point: “web wide practical application” is not a pre-requisite for vendors to coordinate the support of their uses, which is what we did. There were over 60 people at the OWL Workshop and consensus was overwhelming for this course of action (there was one person I recall expressing some similar meta qualms about it, and he participated with verve in the selection of things to go into 1.1.) So, we have users…why shouldn’t we support them? In contrast, you don’t seem to be an OWL user…why should I worry about your qualms? You don’t see a need for the expressiveness, a load of other people do.

    I find your dismissal of the number of implementations as indecent just silly. I don’t know what else to say about that. There are three companies selling OWL reasoners and two open source implementations. All of these are independently developed.

    As for making it more confusing for non-expert application implementers…how so? If you are an ontology developer, learn the new features and use them if you need them. If you don’t need them, don’t use them. Really, this just seems to be a non sequitur.

    In case it isn’t clear, I’m not remotely swayed by your qualms. So don’t bother repeating them :) I have been somewhat swayed by worries that calling it “OWL 1.1” (or OWL 2.0) might slow adoption because it makes it seem like OWL isn’t finished. That’s one reason for not taking it to a standards body (yet). This is just users and implementors getting together…what’s the harm?

    (I don’t buy the slow adoption argument, though I don’t have conclusive evidence either way. I’ve heard people argue that not adding stuff slows adoption because it makes OWL seem stagnant. I know it slows adoption by people who need more expressiveness.)

    (It would be interesting to shift it into an incubator group. I’m not sure it’s the best idea. The other point is that we wanted this to be very lightweight and inexpensive, whereas a normal working group is very expensive. An incubator group might be as cheap as an Oasis TC, which would be reasonable.)

  60. Danny Says:

    Ok, maybe I’m wrong to be concerned about this, and I don’t expect to sway you. Certainly when you hide the OWL 1.1/2.0 label the effort has a different complexion, and development in this area is undeniably a good thing. But I am an OWL user, and probably more to the point am an active web developer who believes the SW vision is a very good idea. With all due respect, the requirements of a self-selected group of existing OWL theoreticians and users may not reflect the requirements of the Semantic Web. Again I could be wrong, but there’s a scent of fragmentation here, and that makes me nervous.

  61. bijan Says:

    I think you are wrong. I think you shouldn’t expect to sway me because your arguments are either unfounded or vague. Actually, they are pure FUD, which is why they torque me off :) We switched to the 1.1 label to mitigate fears, but really, if you are all bent out of shape by that label..pfft. I’m not against marketing but the semantic web has far graver marketing problems than this. Plus, a user driven, vendor supported effort is exactly the kind of things one would expect to see.

    I see while you don’t mention it, you do drop the “not a decent number of implementations”. What is the decent number, btw? Do you have ANY criteria to offer for when we can make moves? I mean, this isn’t an immediate standardization effort. It’s preliminary.

    I don’t fear the label.

    As for your last three sentence, well, they are offensive. The “insight” of a self-selected active web developer who believes the SW vision is a very good idea may not reflect the requirements of the Semantic Web either. We tried to reach out to a broad community. Our process was, and continues to be, open. We intend to gather experience. We intend to submit a note to the W3C. We are working against fragmentation.

    The Semantic Web isn’t a person or even an institution. It doesn’t have requirements. Grr. What a BOGUS dialectical move. I spend a great deal of my time thinking about the Semantic Web, why would you think we wouldn’t consider these things? Or are we just dumber than you? Where’s your reality check?

    I notice too that you completely ignored the vendor support.

    Ok, I’m ticked and should stop. It’s perfectly fine to have concerns. It’s theoretically possible that the OWL 1.1 effort will kill the Semantic Web, the Web itself, and life as we know it. But I don’t think so, and in the absent of more specific evidence, I think it’s fair to put such worries aside.

    (Oh, if you want another driver, datatypes are definitely key. We will hit a roadblock in supporting Web Services policy languages without better numerics. Our reduction of WS-Policy to OWL has spurred more interest in OWL from the Web Services guys than anything else I know of.)

  62. bijan Says:

    BTW, you are, of course, welcome to attend the next OWL Experiences and Directions workshop next year, which will, again, be colocated with ISWC. And feel free to join the mailing list. I think you will be more effective if you take a less generally naysaying attitude, and be more precise in your qualms and their basis, but, eh, up to you.

  63. Danny Says:

    I’m sorry Bijan, I didn’t mean to tick you off. I do have concerns, but obviously haven’t articulated them very well (not that they are particularly well-formed – I think it was only last night I heard of OWL 1.1). That is all. If there is (or will be) wide support for this effort then my concerns are void. Either well, time will tell. I am interested in the tech/theory, so would very much like to join the mailing list, and I’ll do my utmost to refrain from naysaying ;-)

  64. bijan Says:

    Fair enough. There are risks, but I think the risks are greater in inaction in this matter. I’m certainly open to my being wrong wrong wrong, though I tend not to predict it.

    Currently there’s a debate on the list about whether a more “modular” OWL 1.1 spec is a good idea…again it’s all marketing. I personally (as you can see) think it’s a terrible idea. I’ve gotten pretty grumpy about it, but hey, I’m a grumpy guy.

    I think catering to the bioinformatics folks is a v. good thing. Having OBO in OWL is a great tractor app, and if we can attribute a drug discovery or two to OWL ontologies…well, that’s a great selling point.

  65. Danny Ayers, Raw Blog : » This Week’s Semantic Web Says:

    [...] The future of OWL? : OWL 1.1 – preliminary overview and syntax docs [...]

  66. Danny Ayers, Raw Blog : » ‘K, what’s wrong with this? Says:

    [...] Ok, I had a bit of a knee-jerk negative reaction to the OWL 1.1 post from Bijan (I assume it is he, as he responded to my grumbles in comments), and wasn’t very diplomatic. The things being discussed are interesting, and extensions to OWL will no doubt be useful. But I still have my concerns, the main thing being an uneasy feeling that it’s premature to be working on a new version of OWL when the current one hasn’t really been put through its paces on the web. But these guys are logicians and I doubt uneasy feelings carry much weight in such circles. So I’ve made a start on reading around the subject a bit. [...]

  67. Michel Bohms Says:

    I am applying OWL to product modelling. Decomposition is crucial here. Best practice pattern using someValuesFrom is unsufficient (not enough cardinality control). We clearly need QCR’s. I have no problem having an OWL update if only it gives me standard way of doing QCR’s. Second need is numeric ranges. Again. OWL1.1 would really keep me from going (back) to other formalisms (liek ISO STEP EXPRESS etc.). Finally it would be great to have some syntactic sugar for things like allowed values; current list constructs are very awkward. Can’t wait till systems like protege and TBC are implementing QCR’s/numeric ranges exactly as agreed by OWL1.1.