LC2 Responses/TL1

From OWL
Jump to: navigation, search

Subject: [LC response] To Thomas Lörtsch

Dear Thomas,

Thank you for your comment
on the OWL 2 Web Ontology Language last call drafts.


The primer has undergone considerable revision, and is about to be released as a "Last Call" working draft. A primer is, by its very nature, susceptible to being pulled in very many different directions. Producing a primer that satisfies everyone's needs would not be possible given the Working Group's resource constraints, and is probably not possible at all. The Working Group therefore decided to focus on producing a short language primer. We expect that additional Primer-like documents will be produced by third parties, as has been the case with OWL.

Other Introductory Documents:

The remit of the Working group is primarily one of language specification, hence the technical nature of most documents. The Working Group is already struggling with document overload and resource limits. The Working Group feels that the Primer and Quick Reference Guide provide an adequate introduction to OWL 2, and believes that it is appropriate for additional user-facing documents to be produced outside the Working Group.

Syntactic Variations:

One reason for the various syntaxes for OWL is that the "main" syntax (RDF/XML) is difficult to use, and in particular difficult to use for specification. The Functional syntax serves just this purpose: precise specification of the constructs of the language and their semantics. The other syntaxes satisfy other requirements, in particular compatibility with XML tool chains (the XML syntax) and ease of reading/writing (the Manchester syntax). Developing (syntax conversion) tools is outside the remit of the Working Group. Such tools are, however, already being developed by third parties; see, for example, the OWL API <>.


This datatype is listed as at-risk because the current known implementations for OWL 2 or variants thereof may not fully implement this feature. The Working Group expects that during the Candidate Recommentation phase (coming shortly), implementations will indeed be produced for rdf:XMLLiteral and its "at risk" status will be removed.

RDF reification vocabulary:

There are technical reasons not to use the RDF reification vocabulary, having to do with wanting an even weaker formal semantics, and perception reasons not to use the RDF reification vocabulary, having to do with diverging intended meanings for the RDF reification vocabulary. Therefore, the Working Group is unwilling to use the RDF reification vocabulary.

New namespace:

The Working Group feels that OWL 2 is the "new" OWL, and OWL 2 is backwards compatible with OWL. There are also significant costs to having a separate namespace for OWL 2 (for example, writing qualified cardinality restrictions would be problematical). For these reasons the Working Group decided that OWL 2 should not have a new namespace.

Please acknowledge receipt of this email to <> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

Peter F. Patel-Schneider
on behalf of the W3C OWL Working Group



From: thomas <>

Date: Fri, 15 May 2009 12:10:59 +0200 Message-Id: <> To:


a little belated but maybe still of use (if of use at all). i'm coming from a web designer background. my knowledge about description logics is mostly self taught and my interest in semantic web technologies stems from my obsession with multifaceted structuring of information. that said, let's comment:

XMLLiteral: i have to admit that i'm quite perplexed that this datatype is at risk. how can OWL 2 want to be 'on the web' but not support it's single most important datatype? how can it be so difficult to implement a datatype, beside all the real complex problems involved with logics, reasoning etc? i strongly suggest that implementors that want to support OWL 2 without XMLLiteral may (of course) do so but have to make a note to their users (and can't claim full OWL 2 compliance). instead of laying the burden on the users to first check if a given software supports XMLliteral. i don't say that every OWL 2 application needs XMLLiteral. but if it's on the web i want to be able to rely on that.

restrictions versus materialization: this problem is tricky and it needs more elaborate discussion at least in the primer: it's own chapter, explicit mentioning of the concept of "materialization", the implicatons of rdfs:domain and rdfs:range, how your restriction can be my materialization and vice versa, in what ways owl:restriction can be used and in what ways it shouldn't etc. i think a lot of misconceptions about OWL are connected to this topic and it should be discussed exhaustively.

primer: the introduction to the primer states that it will get further work which is good. it has muched improved in the recent version but it still needs much more examples. i would prefer if the primer didn't try so much to use every OWL element once but if it was more of a general guide to ways of modelling common situations, giving example constructs etc. for example i asked a question on public-owl-dev last week and alan rutenberg was so kind to propose a solution. it took me quite a while to understand that solution (and also to a colleague with a very strong semantic web background it was not obvious). while i could understand it after some pondering there is no way i could have come up with it myself in the forseeable future. i need examples, to copy!

more introduction: i would suggest that the introduction of every element in examples gets its own document. the new (and useful) document overview names 4 parts as "for user" but those 4 parts merely give an overview. then you're stuck with the core specification which for non logicians is shockingly unreadable. there is a huge gap between the two which needs to be filled.

syntax: it doesn't help either that there are all sorts of syntactic variations. why can't we stay with infix notation? a trained logician should have a much easier time switching from prefix to infix then the ordinary web developer has the other way round. if OWL is meant to introduce logic into the web data on a large scale then please: climb down from the hill;-) and why do properties have different names in different syntaxes? why does manchester impose even more new constructs? and there is a serious lack of publicly available converters, as web services and as software (but at least those available should be mentioned in the primer). and where have the pictures gone? painting down the graph is sometimes my last resort when i'm trying to understand what's going on (eg when alan gives e an example ;-) and can be really helpful. it's the most easily understandable syntax. manchester may be easy and terse to write (maybe it's the desperate sem-hackers tool of choice?) (well, maybe i'm deformed by to much triple talk...)

reification: why is there a new reification syntax? why not use the one that RDF provides? i can't spot a difference neither semantically (that may be me, of course) nor in terseness or syntactic elegance. it's the same triple bloat, just with new element names, isn't it?

OWL 2 namespace: why isn't there one? wouldn't you, when you introduce new element and sometimes even new rules, refer the user/parser/reasoning engine to a new version of the spec? how does this deal with OWL softwares and services that don't get updated to OWL 2? does it degrade gracefully? degrading gracefully is quite important on the web.

thanks: thanks especially for punning! and thanks for all the other work too! indeed i do (soemhow) see what an enormous amount of work these documents represent and i'm very thankful for it, despite my rant above!

cheers thomas lörtsch