The OWL Experiences and Directions meeting concluded today. Info on it is up at: http://www.webont.org/owled/2008dc/ .
One talk I found interesting was a controlled English interface. It is too early to consider robust but is interesting to explore for one kind of interface to our applications - http://www.webont.org/owled/2008dc/papers/owled2008dc_paper_5.pdf
A lot of interesting experiences on OWL and new OWL features has been intensively discussed in OWL: Experiences and Directions(OWLED 2008). But (potential) users, for adoption purposes, still need some clarification on the lessons learned from past. Therefore, I’m hoping the following questionnaire be answered the OWL community.
Below is an email I sent to the OWL Working Group mailing list (which is public) in response to an action to talk about how I thought we could address OWL Full. I share it here with those of you who are not following the group’s mail. I made a couple of minor edits because I referred in the email to some things in the charter, and was reminded our charter is member only by W3C rules (but I promise, nothing important is missing)….
-Jim Hendler
Before I get to something resembling a proposal, I first want to outline my “ideal vision” (which I know is not the same as some other people’s but at least it makes it clear where I’m coming from), then “define” what I mean by a couple of the terms with respect to that vision, and then make the proposal and provide a justification– so if you don’t care about anything but the latter, drop to the bottom.
Ideal world: If I could start all over again, there would be one language called OWL. The language would be defined as a set of vocabulary terms “owl:xxx” and the definition of an OWL document would be any RDF document (by whatever definition of document one uses) that includes the use of those terms. The language would be aimed at being a good common denominator for the definition of ontologies, not aimed at being a good KR language for AI use (i.e. it’s main function would be interoperability, more precise and expressive KR languages would use it for exchanging at least some of their information where possible). The language would be primarily aimed at “modeling”, not reasoning, and thus the semantics could be less formal than it is now.
Attached to OWL would be a privileged fragment called OWL DL, which would have a very clean semantics. OWL DL would be intended for people whose use of OWL fits one of the important niches OWL can handle - which is classification reasoning (via consistency checking). Folks looking for an expressive common denominator with good reasoning tools would be drawn towards OWL DL, and they would find that most of the documents they created in OWL either already worked well with OWL DL tools, or needed a small amount of work to get there. There could also be a number of special extensions to the OWL vocabulary (lets call it owldl:xxx) that could be used where they were needed for making reasoners better. The semantics of this fragment, which need to be extremely clear and clean, would be very formal. Syntaxes for developing documents in this language would still need to talk to RDF, since they want to provide URIs that would be of use in the Semantic Web (so regular OWL users would have benefit of the clean ontologies built in OWL DL)
There could also be other communities that come to the W3C, or which work in other forums, and create other priviledged versions of OWL for other KR approaches or for other purposes. These fragments would be defined as vocabulary fragments (i.e. the document could contain only these terms) or they could have specific semantics — OWL DL would be an obvious candidate for the semantic base of these, since that would greatly enhance reuse.
Some (loose) definitions:
Operational semantics: I use Java and C all the time. I have never seen any semantics for them other than an “operational semantics” — that is one that says what the intended use of the language constructs is. I also have books on Prolog and Lisp and Scheme, which have something closer, but in fact when I implemented my own prolog once upon a time, the formalism wasn’t really what it is today - I used a document that said what the various features of the language were and how they interacted. These semantics, like the ones in Java and C were written in a language called English. In fact. most languages whether they be programming languages, markup languages, or modeling languages are defined against this kind of semantics. What is called a “reference” (for example, the “programming in C” book or the “Moonual” for Lisp) is generally the user guide to understanding these operational semantics.
A fallacy about operational semantics: Some on this group keep telling me that the difference is that OWL is not a programming language. I happen not to agree, but even if you take that view, I point out most other languages including HTML and XML (and, in fact SQL) have these semantics. (SQL also has a mathematical underpinning, but it includes a number of features that are not covered by that, and are only explaining operationally - what we would call non-semantic features). The fallacy has been that if one says “OWL” and means “OWL DL” then they are right that the language is not like a programming or markup langauge, it is a KR language and that does indeed need a formal semantics. So what I call OWL in the above is the main language, and if it has any semantics at all, it should be operational (and maybe we have to abide by the fact that RDF has a semantics - but that was a mistake in my opinion).
An axiomatic semantics - the term has been used in a number of different ways. I think Boris and I came close to agreeing that many things in OWL and OWL DL could be defined in a fairly straight forward way against traditional rules of logic. This is using logic as the “spec” for the operational semantics — that is, we could say (making up a simple example)
A owl:sameInstanceAs B <=> forall(x) P(A,x) -> P(B,x)
there was one of these done in KIF for DAML, so it is pretty clear that a great amount of what is in the current OWL Full could be defined this way. Note that this does not mean one necessarily should, or could, implement the language by simply inputting these to a logic engine (although that is probably possible for at least the great bulk of the language) but rather that the axioms are being used to provide a more precise description than NL does - but I would still claim this is primarily an operational semantic approach.
OK - my proposal.
I believe we can actually reach the ideal world above with one exception - the language called “OWL” is going to have to be called OWL Full for historical reasons.
Argument
We would need to update the OWL reference, which pretty much contains the operational semantics for OWL Full to include those new constructs we think are of use, and we can remove the part about the restrictions for OWL DL (because there is no longer the need for the 1-1 mapping) - so the OWL 1.0 reference would be extended into the OWL Full document.
We would define OWL DL precisely as we have already and, in my opinion, other than cleanup and resolving the OWL DL only issues, much of the complexity would disappear - because we could have features (and syntax) that are particular to the needs of reasoners that extend the above. The semantics would be aimed at reasoners so and would be based on the current model theory.
Interesting observation
Taking this approach has some nice features:
1 - we are almost done (we would need to decide which OWL DL features need to be added to the OWL Full reference and write them up)- [sentence deleted]
2 - <a few words deleted> we would be defining both Full and DL, the feature mapping would be clear where needed. Features and syntax of DL that seem not to have Full realization would with (a) be added or (b) be declared as “extensions” that are not needed in Full.
3 - We could have fragments like OWL Prime that are defined for OWL Full easily. If we want corresponding fragments in OWL DL, we need to do the semantic work, but that is relatively straightforward. Fragments of DL, like those in the current fragments document, would also be easily derived as they wouldn’t necessarily impact the Full world. (Folks who want mappings from OWL to provably polynomial fragments would either use the OWL DL semantics, or could invent their own - we don’t have to do that work for them)
hmm, looks like my ideal world might be closer to realizable than I thought…
I look forward to being torn to shreds since I know this was written in a language very foreign from that of many in the WG. On the other hand, when we invented Web ontologies at Maryland (SHOE claims earliest use of the term), this is the vision I had in mind, so I guess I’m at least consistent….
cheers
JH
It is no secret, and in fact is a matter of public record, that although I am a member of the W3C’s OWL Working Group, I am not very happy with the language and its design. I worry that we are adding a lot of complexity to the language for a small amount of functionality gain (if any), that the work is being motivated by theoretical issues rather than user need, and that a small fragment of the growing OWL community is adding significant complexity to the language for very specific representational properties that follow from the Description Logic literature, rather than from a rich exploration of the many different roles a Web ontology language could have in the growing Semantic Web info-ecology (i.e. a world of mixed expressivity with heterogeneity among many different reasoners). The three documents that have been released are somewhat difficult to penetrate - at the end of this blog I have a list of the old and new OWL vocabulary terms and as you can see, despite the claim to a minor version number, the OWL 1.1 design almost doubles the size of the language.
Anyway, here’s your chance to prove me wrong if you think I’m mistaken, or to comment on the overall effort if you think I might have a point. The documents have been released and there is a call for reviews - the easiest way to get there is to follow the links from the W3C news item about the publications. Technical comments are, of course, welcome and needed, but since this is the first release of these documents with this wide of a dissemination, it is useful for us also to know if we appear to be addressing users’ needs and if the language design appears to be going in the right direction.
- Jim Hendler
p.s. Before I get accused of trying to sabotage the groups efforts or anything like that, let me point out that the WG’s mailing list archives are public, the history of my comments, the arguments against them, and the rest of the give and take, is all a matter of public record - and I encourage interested users to explore that literature and see from where the different points of views arise. You’d be just as mistaken to take my word on this as to take anyone else’s.
=== New OWL vocabulary, may be a slight variation from the published one - thanks to Peter Patel-Schneider for this list (which I have edited slightly for clarity from his original email)- see the thread there for details===
ORIGINAL OWL:
owl:AnnotationProperty owl:Class owl:DataRange owl:DatatypeProperty owl:FunctionalProperty owl:InverseFunctionalProperty owl:ObjectProperty owl:Ontology owl:Restriction owl:SymmetricProperty owl:TransitiveProperty owl:allValuesFrom owl:cardinality owl:complementOf owl:differentFrom owl:disjointWith owl:equivalentClass owl:equivalentProperty owl:hasValue owl:imports owl:intersectionOf owl:inverseOf owl:maxCardinality owl:minCardinality owl:onProperty owl:oneOf owl:sameAs owl:someValuesFrom owl:unionOf owl:AllDifferent Alternative mapping for DifferentIndividuals axiom owl:distinctMembers owl:DeprecatedClass Used in special "annotations" owl:DeprecatedProperty owl:OntologyProperty Used for ontology properties owl:backwardCompatibleWith Built-in OWL DL annotation properties - OK owl:priorVersion owl:incompatibleWith owl:versionInfo owl:Nothing Built-in OWL Classes - OK owl:Thing ADDED IN OWL 1.1 owl11:AsymmetricProperty Typing triples owl11:FunctionalDataProperty owl11:FunctionalObjectProperty owl11:IrreflexiveProperty owl11:ReflexiveProperty owl11:Individual owl11:declaredAs owl11:equivalentDataProperty Disambiguation for EquivalentProperties axiom owl11:equivalentObjectProperty owl11:subDataPropertyOf Disambiguation for SubProperty axiom owl11:subObjectPropertyOf owl11:DataRestriction Disambiguation for restriction construct owl11:ObjectRestriction owl11:dataPropertyDomain Disambiguation for domain construct owl11:objectPropertyDomain owl11:dataPropertyRange Disambiguation for range construct owl11:objectPropertyRange owl11:Axiom Annotations of axioms owl11:NegativeDataPropertyAssertion For new OWL 1.1 constructs owl11:NegativeObjectPropertyAssertion owl11:SelfRestriction owl11:onClass owl11:onDataRange owl11:disjointDataProperties owl11:disjointObjectProperties owl11:disjointUnionOf owl11:inverseObjectPropertyExpression owl11:<XSD facet>