From OWL
Jump to: navigation, search

Goto OWL 2 Full Open Issues Page

Closed issues of OWL 2 Full development.


Closed WG Issues

ID Title Comment
Issue 2 allDisjoint-RDF RDF syntax has been introduced
Issue 5 n-ary datatypes Closed in *this* formulation, but n-aries still open issue
Issue 24 1-version-allowed-policy Imports/Version-TF has been closed
Issue 29 owl:DataRange datarange restrictions are now data *type* restrictions
Issue 55 owl:class postponed
Issue 64 obj-prop-chain rep RDF syntax has been changed
Issue 67 reification for axiom annotations RDF syntax changed --> no RDF Reification anymore
Issue 73 infinite universe rejected
Issue 81 reification for negative assertions RDF syntax changed --> no RDF Reification anymore
Issue 92 owl:Ontology to FS mapping RDF Syntax has been fixed
Issue 108 profilenames Resolution: DL, EL, QL, RL, Full
Issue 112 universalproperty data and object versions of top and bottom properties added
Issue 121 RDFS-based OWL 2 DL rejected by Chairs
Issue 122 QCR RDF syntax RDF Syntax has been fixed
Issue 123 QCRs in OWL R Full "weak" QCRs added to OWL R
Issue 124 datarange complements new RDF syntax for this construct

Closed TF Issues

[FIXED] URIs in semantics tables

FIXED in OWL 2 Full Editor's Draft.

  • Title: Remove column with vocabulary URIs in semantic condition tables
  • Type: enhancement (editorial)
  • Author: m_schnei

In the OWL-1.0-Full spec, many but not all tables have OWL-vocabulary URIs in the left column. I think this is redundant and confusing. I suggest to follow the style of the RDF(S) spec or the pD* paper.

[FIXED] identifier for semantics tables

FIXED in OWL 2 Full Editor's Draft.

  • Title: Give identifiers to semantic condition tables
  • Type: enhancement (editorial)
  • Author: m_schnei

Tables in the OWL Full semantics document should be numbered for easier referring to them from other documents (note by Boris Motik).

[FIXED] Wrong interpretation function name

FIXED in OWL 2 Full Editor's Draft.

  • Title: Usage of "I(.)" instead of "S_I(.)" in "OWL built-in" list.
  • Type: bug (editorial)
  • Author m_schnei

In the list called "OWL built-in syntactic classes and properties", it is always written "I(owl:xyz)" instead of "S_I(owl:xyz)".

[FIXED] Existential if branch

FIXED in OWL 2 Full Editor's Draft.

  • Title: Comprehension principles have existential "IF" branch
  • Type: enhancement (editorial?)
  • Author: m_schnei

The "Comprehension principles" table presents all comprehension principles in the following form:

 If there exists
 then there exists y with

with some assertions A(.) and B(.,.) (x and y may be tuples).

Although the "IF" branch is stated as "if there exists", I don't believe that this is an existential assertion (in comparison to the "THEN" branch, which definitely *is* an existential assertion). I would rather believe that the general logical form of comprehension principles is as follows:

     EXISTS y: B(x,y)

I would like to remove the string "there exists" from the "IF" branches in the comprehension table in order to align the style with the presentation style of other tables.

In the cases where the IF branch talks about sequences, the formulation has then to be:

   l _is_ a sequence of ...

[FIXED] axiomatic triples

FIXED in OWL 2 Full Editor's Draft.

  • Title: Missing axiomatic triples for OWL-1.0 vocabulary
  • Type: change (conservative)
  • Author: m_schnei

RDFS provides axiomatic triples for all parts of the OWL vocabulary. In OWL-Full, several of these axiomatic triples are missing. I would like to add them to 1.1-Full.

Note: Those missing in 1.0 are listed in FullSemanticsAxiomaticTriples. For the new 1.1 vocabulary, I will add them to the semantics of their respective language constructs.

[FIXED] Wrong sequence semantics

FIXED in OWL 2 Full Editor's Draft.

  • Title: Sequence based semantic conditions wrongly defined
  • Type: bug, change (non-conservative)
  • Author: m_schnei

Currently under investigation

Note: This issue has eventually been raised as WG Issue 120 and closed.

[FIXED] Missing AllDifferent semantics

FIXED in OWL 2 Full Editor's Draft.

  • Title: AllDifferent misses "main" semantic condition
  • Type: bug, change (conservative)

With respect to AllDifferent, the OWL-Full spec only has a comprehension principle, but no main semantic condition.

Note: This bug is treated in FullSemanticsAllDifferent, and also in FullSemanticsNaryAxioms.

[REJECT] Restriction semantics

WON'T FIX, because it's not the right way to go. Instead, added missing axiomatic triples.

  • Title: Semantic conditions for Restrictions in 1.0-Full ignore owl:Restriction typing triples
  • Type: change (non-conservative)
  • Author: m_schnei

It is questionable whether this is a good idea, though it works technically. Adding typing axioms for 'owl:Restriction' to the IF conditions would lead to a slight backwards compatibility issue.

Note: The addition of missing axiomatic triples for restrictions, such as "onProperty domain Restriction" fixes the problem: No need to add the typing triple, because it would then be redundant information.

[FIXED] Wrong RDF spec links

FIXED in OWL 2 Full Editor's Draft.

  • Title: 1.0-Full spec points to outdated versions of RDF semantics spec
  • Type: bug (editorial)
  • Author: m_schnei

There are (at least) two hyperlinks in the Full spec, which point to old WDs of the RDF semantics spec:

  • In the intro of chap. 5: The link "semantic extention".
  • In the references list of the AS&S

Note: This bug only effects the OWL 1 Full spec. One only has to take care to not copy and paste without thinking. :)


The chairs decided to NOT open the respective WG issue. Hence, there won't be such a language in OWL 2.

  • Title: Drop the RDF style OWL DL language.
  • Type: change (non-conservative)
  • Author: m_schnei

There are two variants of OWL-DL in the OWL-1.0 spec: One being based on abstract syntax, and one being based on RDF. The two versions are only identical under certain conditions. Without these restrictions, the latter version has very strange properties, and is not a sub-language of OWL-Full.

I strongly plea for dropping the RDF-style OWL-DL version.

Note: Raised as WG Issue 121.

Note: I will provide more evidence for my claim that the RDF-style OWL-DL language has strange properties.

[REJECT] Unifying extensions

I will not do this, since it will probably lead to problems.

  • Title: Should the property extension equal the class extension of a property?
  • Type: change (conservative)
  • Author: m_schnei

In RDFS, an entity can be both a class and a property. In this case, such an entity has both a class extension and a property extension. But nothing is said in the RDFS spec about whether there is a relationship between these two extensions. So there don't have to be any relationship.

It seems to be natural to assume that the tuples in the property extension are also instances of the class extension. However, this would demand that for each such tuple an individual exists. Therefore, the following comprehension principle would be needed:

   p in IOOP,
   (x,y) in EXT_I(p)
   z in CEXT_I(p),
   z = (x,y) [FIXME]

Note: Pat Hayes has told me that he believes this is a bad idea. And I feel so, too. I am not even clear, how to do this technically.

[REJECTED] Only-If semantics for negative assertions

  • Title: Should there only be "ONLY-IF" semantics for negative property assertions?
  • Type: change
  • Author m_schnei

Currently, there is an "ONLY-IF" main semantic condition and a comprehension principle. The latter seems very strong, since it creates negative assertions for every nonexisting combination "s p o". This seems neither desirable, nor necessary, since negative property assertions are syntactic sugar.

Resolution: Since negative assertions are axioms, these have to be IFF conditions, or the correspondence between Full and DL will fail.

[FIXED] Paradoxical self-restrictions

Fixed by changing the role of the Comprehension Principles.

Extending the OWL1 semantics in the obvious way to OWL2 would provide comprehension principles for self-restrictions, as well as the already existing ones for complements.

From these two comprehension principles, in every model of OWL2 Full, we would find

_:y owl:complementOf _:z .
_:z rdf:type owl11:SelfRestriction .
_:z owl:onProperty rdf:type .

If _:y rdf:type _:y then _:y rdf:type _:z and so not _:y rdf:type _:y .

But if not _:y rdf:type _:y then not _:y rdf:type _:z and so _:y rdf:type _:y .

i.e. the classic liar paradox, and OWL2 Full is inconsistent.

To summarize OWL2 Full is OWL Too Full.

Note: This has been raised as WG Issue 119.

[FIXED] Nothing is a datatype

FIXED in OWL 2 Full Editor's Draft.

Jeremy has observed [1] that the empty graph in OWL 1 Full entails

 owl:Nothing rdf:type rdfs:Datatype

See [2] for a proof.

See [1] for a possible remedy.

[FIXED] DL-Correspondence and Axiom Annotations

Solution: The RHS of the correspondence theorem does not allow annotations.

The following G_L |= G_R is an OWL 2 DL entailment:

 G_L := {
   ex:s ex:p ex:o
 G_R := {
   _:x rdf:type owl:Axiom ;
       owl:subject ex:s ;
       owl:predicate ex:p ;
       owl:object ex:o .

But because of the ONLY-IF semantics of the annotation SC this cannot be entailed by OWL 2 Full: One can define an interpretation, which makes "s p o" true, but which makes the conjunction of "subject s, predicate p object o" false. The ONLY IF semantic condition only sais that /if/ this conjunction is true, then "s p o" is true, too.

Making the SC into an IFF condition would be insane, since this would lead to an "annotation avalanche" initiated by every triple "s p o" in an RDF graph.

Probably the easiest way to deal with this issue is by having the IFF direction as a comprehension principle.

[REJECTED] Chain Comprehension Principle

  • Title: Do we need a comprehension principle for the chain property of sub property chains?
  • Type: feature
  • Author: m_schnei
  • Related: Issue 140

Issue 140 has been postponed. And in my answer to PFPS I have explained why I do not require the existence of a property with the chain extension.

It is unclear whether it is necessary to have a property individual for each possible property chain, in order to compete with the semantical expressivity of OWL 2 DL.

If this is necessary, how is such a comprehension introduced technically?

The form would be:

   p_1,..., p_n in IP,
   IEXT(q) = IEXT(p_1) o...o IEXT_(p_n)

This cannot be expressed with the current RDF syntax, since there is no way refer to the property, which represents the chain (if any).

One could think about entailments of the following form:

 p1 o...o pn spc q |= (p1 o...o p* o...o pn spc q

However, this is covered by the IFF semantics of SPCs! So no need for a comprehension principle here.

However, Issue 140 might change the situation, since in this issue requires a name for the chain.

[RESOLVED] Name of Easy Keys

How do we call the Easy Keys in the documents? I see "Keys" everywhere, but called it "Easy Keys" in the Full spec.

I have decided to follow the lead of the Direct Semantics, which calls them just "Keys".

[POSTPONED] More flexible correspondence theorem

One should consider the following form of the correspondence theorem (sketch): By this, the strict dependence on the concrete RDF graphs is relaxed, and what counts are the logical conclusions. And it's possible that the comprehension principles and the IFF semantics for booleans and enums become obsolete by this [FIXME].

Theorem 1 (Correspondence Theorem): Given a datatype map D, which consists of rdf:XMLLiteral and all mandatory datatypes. [FIXME: better formulation!] Let F_1 and F_2 be collections of valid OWL 2 DL ontologies in Functional Syntax that are imports closed, and let F_1 OWL 2 DL entail F_2 w.r.t. D. Then there exist collections of RDF graphs R_1 and R_2 with the following properties:

  • The reverse RDF mapping can be successfully applied to R_1 and R_2, leading to collections M(R_1) and M(R_2) in Functional Syntax, respectively.
  • M(R_1) and M(R_2) are collections of valid OWL 2 DL ontologies in Functional Syntax that are imports closed.
  • M(R_1) OWL 2 DL entails F_1 w.r.t. D, and F_1 OWL 2 DL entails M(R_1) w.r.t. D.
  • M(R_2) OWL 2 DL entails F_2 w.r.t. D, and F_2 OWL 2 DL entails M(R_2) w.r.t. D.
  • R_1 OWL 2 Full + CP entails R_2 w.r.t. D.

[FIXME: Do we also need a translation of the datatype map D into an OWL 2 Full datamap?]


Allows to make all class expressions into ONLY-IF SCs, because one can then alway "extentialize" "named" class expressions: Under DL semantics, the graph

 C owl:intersectionOf (D1 D2)

is equivalent to

 C owl:equivalentClass _:X
 _:X owl:intersectionOf (D1 D2)

and with the comprehension principle for intersections (in whatever role) we have the second triple for free.

Would not make comprehension principles obsolete, since, in general, one cannot replace an existential class expression by something equivalent, which does not need the existence of some "proxy" individual.

Would allow implementers of Full-based DL-checkers to do some preprocessing, by finding better suited graphs for the LHS and RHS of the queried entailment. (But this looks like a useful strategy, anyway.)

Would be simply too much for this release of OWL. The current approach is a first step.

[POSTPONED] Rethink defining semantics for single RDF graph

The DL Semantics states in the introduction that it is defined for a set of axioms instead of an ontology document. In OWL 2 Full, the terms "Consistency" and "Entailment" are defined for /collections/ of RDF graphs. I know that this comes from the RDF Semantics. However, it would be no restriction to only talk about a single RDF graph.

Rejected for the moment, since this would be in odd with RDF Semantics document.

[POSTPONED] IFF semantic conditions for class expressions

For restrictions, OWL 1 Full has only-if semantic conditions, while boolean combinations and enumerations have iff SCs. I wonder whether one should and can weaken the SCs on all "class expression" like Full axioms, without hurting the correspondence to DL.

See <http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0116>

Would be much in odd with OWL 1 Full, even if justified.

[MOOT] Annotation Semantic Conditions

Should there be two typed versions of Semantic Conditions for annotations?

Jie Bao answers as a revision comment: "I support your Editor's Note before current Table 4.17, i.e., removing the typing triples. This will allow annotations in OWL full on any triples. So far I don't see a problem without the typing triples in inference."

Resolution: Mooted by resolution of WG Issue 144.

[WG-RESOLVED] IE7 and O9.5 don't display all HTML entities correctly

  • IE7: lang, rang
  • O9.5: empty, exists (for fonts in RDF-Based Semantics tables)

Resolution: WG decided to not do anything, except for additionally providing the documents in PDF form. Rational was that there are other W3C documents suffering from the same problem, and it doesn't make much sense to hack our documents just to work around MSIE limitations. And MSIE8 will probably be HTML-compliant.


Should something be said about extended RDF graphs?

Resolution: The OWL 2 Full spec is not responsible for saying something about Extended RDF graphs. The RDF Semantics spec is the right place for this. Whatever the decision is for the RDF Semantics, the Full Semantics will follow its lead.

[CLOSED] Missing entries in OWL 2 Full Interpretation?

Result: It turns out that the other sets can also be defined in terms of IEXT. For example, IOAP = CEXT(IS(owl:AnnotationProperty)) = {p in IR: (p,IS(owl:AnnotationProperty)) in IEXT(IS(rdf:type))}

The current form of the interpretation function I(.) has been taken from OWL 1 Full. I(.) omits certain sets and functions. It seems reasonable that IC and ICEXT are omitted, since they can be defined in terms of IEXT. But what about 'IX', 'IXP', 'IDP', 'IAP'?

I suppose that it suffices to have take the axiomatic triples into account, e.g.

 owl:DatatypeProperty rdfs:subClassOf rdf:Property

The set of all semantic conditions is part of the definition of an interpretation, anyway.

[CLOSED] Value Restrictions and QCRs on Data Properties

There are several related questions:

1 Should QCRs with 'onDataRange' coerce the class into a Datatype, or only into a class of literal values?

Solution: Into a datatype. Because:

  • The existing dataranges are actually declared as "rdf:type rdfs:Datatype": owl:datatypeComplementOf and owl:datatypeRestriction.
  • It is ok, since it only has to be made clear that IDC is not restricted to the datatype map datatypes only.
  • There is no precedence in OWL Full that one only infers classes that happen to entirely consist of datatype values.
  • This would be strange, because the concept of a class with datatype values is very unhandy, and Full is about handyness.
  • It is probably very hard to reason with datavalue classes.
  • The SCs would be ugly.

2 For SomeValuesFrom, if applied to data properties: Should the class be a datatype or a class of literal values, or should nothing be said?

Solution: Nothing should be said, since this is no particular language feature. If the property of a value restriction happens to be a data property, then this is simply not treated specifically. That is a design decision. The only case where an explicit distinction is made is for oneOf.

3 Maybe it can even be entailed that the class is then at least a set of literal values? Check!

Solution: Maybe, but this is not an issue here.

[CLOSED] n-ary Value Restrictions and data property inference

Currently, the LHS of the SCs demand that the sequence is about data properties. I guess that the SCs should rather entail that the properties are data properties, having a sequence of resources on the LHS.

Resolution: Proposed change was performed.

[CLOSED] Should "Ontologies" section be moved?

Is there a better place in the document? Probably directly after the "Vocabulary" section.

Resolution: The section has been moved to Section 3.

[CLOSED] Scope of Datatype Restrictions

I think datatype restrictions should only be defined for datatypes which occur in the datatype map. Currently, they are defined for all instances of IDC.

Resolution: Added a comment to the table comment. Actually, nothing had to be changed, because datatypes not in the datatype map will generally lead to an inconsistent ontology.

[CLOSED] Domain of IL in Interpretations section

The RDF Semantics document says that the domain of IL is the set of all /typed/ literals. What about the /plain/ literals?

Answer: Pat Hayes has answered my question. Plain literals are also treated by Simple Interpretations, as defined in the table of Section 1.4 in the RDF Semantics. But this treatment is always the same for all Simple Interpretations, so there does not need to be a parameter to the interpretation (no tuple entry). IL, on the other side, maps the typed literals, and these may be different for different interpretations.

[CLOSED] Replace all occurrences of "IS(.)" by "I(.)"

In the RDF Semantics, "I(.)" is generally used to interpret URIs instead of "IS(.)". While it doesn't matter in the particular case of URIs (see table in Sec. 1.4 of the RDF Semantics), I /must/ be used for example to refer to the denotation of bNodes or plain literals, since there are no "component mappings" for this.

Solution: Changed throughout document.

[CLOSED] Ontology Headers and Versioning

Should something be said concerning ontology headers and versioning? They don't add to the semantics, but perhaps for completeness?

Resolution: Added some "may" text.

[FIXED] Range of IL in Interpretations section

The RDF Semantics document says that the range of IL is IR, not LV, due to technical problems with ill-typed literals. One might be explicit in the section, and tell what's going on.

Solution: Range changed to IR according to RDF Semantics, with a reference to where this is explained.

[CLOSED] Correspondence Theorem and reference to vocabulary

Is it necessary for the correspondence theorem to mention the vocabulary, etc. similar to the definitions in the "Interpretation" section?

Solution: No, there is no dependency on the vocabulary. But there was an error in the definitions of consistency and entailment, which made this believe. This bug has now been fixed.

Drop xsd:ENTITY, xsd:ID, and xsd:IDREF

Currently proposed.

Solution: Added an ednote to the draft.

[CLOSED] Should RDF List vocabulary be treated in Full Semantics?

The complete semantics for the RDF List vocabulary is defined in the RDF Semantics spec. So there is, technically, no need to treat it in the Full Semantics document. But lists are of particular relevance for OWL Full, so perhaps, redundant treatment makes some sense?

Solution: No treatment of rdf:List. It has been made clear in the first paragraph of the SC section, that the SCs in the RDF-Based Semantics are (mostly) only about the OWL vocabulary, and that the section has to be read in conjunction with the RDF Semantics. Further, the vocabulary is not used in any of the tables anymore, but only in the "conventions" paragraph.

Propositional Datatype Ranges

Related to closed Issue 147

Should we have dedicated SCs that entail, that if every class of a union or intersection expression, then the union or intersection itself is a datatype? This would be more in line with OWL 2 DL.

Solution: Additional semantic conditions have been added, being analog to the "datatype" semantic condition for enumerations.

Axiomatic Triples introduction should perhaps be moved to Appendix

To be considered.

Solution: Done.

Axiomatic Triples introduction not complete

The introductory text for the two "Axiomatic Triples" tables for "Classes" and "Properties" may not be complete. Needs some analysis what's actually missing.

Solution: Added text that it might be impossible to capture all axiomatic aspects of OWL 2 Full by a set of axiomatic triples.

negative data property assertions

Check whether the semantic conditions for negative data assertions are adequate, or whether they may lead to problems. Currently, the object of a negative data assertion is entailed to be a data value.

Solution: Did not change the semantics, but added some "warning" preceding text to the table

Check whether relaxed hasSelf range is problem for correspondence

Maybe we need to entail "true" in the semantic condition?

Solution: No change, because:

  • There will be no problems with the correspondence theorem, since the Direct Semantics are not affected by the "true" stuff.
  • Entailing "true" would not produce any relevant information w.r.t. the semantic meaning of a self restriction.
    • In general, an RDF graph defining a self restriction will have the "true" part, anyway, so this is a corner case discussion. And if some graph really omits "true", then I do not see a reason for fixing this "almost-bug" by the semantic condition.
  • Having the CP produce the "true" value is fine. The alternative would be to simply assert the existence of some value value for owl:hasSelf, and this does not seem to be motivated.

Handling of Basic Sets

The "basic" sets turn out to be definable in terms of IEXT. Should they still be listed in a table in the SCs, or better in the Interpretations chapter?

Solution: There are now two tables: One defines the basic sets in the "Interpretations" section, and one specifies the semantic conditions in the "Semantic Conditions" section.

Possibly revise Introduction section

The following text is an adjusted version of Section 1.4 of the OWL Reference:

OWL is a vocabulary extension of RDF [RDF Semantics]. Thus any RDF graph forms an OWL Full ontology. Further, the meaning given to an RDF graph by OWL includes the meaning given to the graph by RDF. OWL Full ontologies can thus include arbitrary RDF content, which is treated in a manner consistent with its treatment by RDF. OWL assigns an additional meaning to certain RDF triples. The section on semantic conditions specifies exactly which triples are assigned a specific meaning, and what this meaning is.

Solution: The introduction has been revised

Citations are not correct

Adjust to other documents.

Add anchors to relevant paragraphs

Before every table intro there should be an anchor (p id=...=).

Solution: Done.

[REDUNDANT] Too Strong Sequence Guards

In IFF semantic conditions, the sequence guards in, for example, boolean expressions, seem to be an obstacle for the "IF" direction to match. One needs the sequence to exist, instead of only the set of elements. An idea would be to split all these sequence based IFF-semantic conditions into two IF-SCs, where the second SC introduces the necessary list (existential assertion).

Solution: This issue has been incorporated into the "Comprehension Principles" issue. It is a main motivation to reconsider the CPs.

Apply Ivan's linguistic change proposals

Ivan has send me lists for "Introduction" and "Axiomatic Triples"

(chain syntax) Syntax of Sub Property Chains

This syntax should really be changed into a single triple form.

Solution: Closed without action, now that RDF Mapping is in LC state.

(nary axioms) Additional n-ary Axioms

There should also be n-ary Axioms for Equivalences.

  • Currently, the rational behind having naries for the Disjoints is computational complexity. But should be modelling ease.
  • Problems with annotations: Will repeat annotation for each produced triple.

Solution: Closed without action, now that RDF Mapping is in LC state.

(chain domain) Should the domain of owl:propertyChain be IR?

Currently, the domain of owl:propertyChain is set to IP. This is not necessary, because the semantic condition coerces the LHS of this property to IP, anyway. And there doesn't seem to be a motivation for IP, except that the actual RDF Syntax happens to use a rdfs:subPropertyOf triple. But the left hand side of the triple is simply meant to be a "root node".

Solution: Relaxed domain to IR, and added a "specific note" to the Properties table.

(uri reference) "URI" vs. "URI reference"

The "Vocabulary" section uses the term "URI reference" several times. This comes from OWL 1. The question is whether this term should be used. Check against:

  • OWL 1 Full
  • RDF Semantics
  • OWL 2 DL
  • general meaning of the word "URI reference"

Solution: All occurrences of "URI" have been replaced by "URI reference", following the RDF Semantics spec.

(vocab entailment) Talking about "Vocabulary Entailment"

The first paragraph of the "Interpretations" section talks about "Vocabulary Entailment". Is this a good idea? Check with:

  • OWL 1 Full
  • RDF Semantics

Solution: It makes sense to talk about Vocabulary Entailment at the given position. However, it was wrong to say that "OWL 2 Full provides a vocabulary interpretation". This was corrected to the plural form: "provides vocabulary interpretation[s]". This has also been changed in the intro accordingly.

(parts diagram) Add image to Full introduction

How should the picture look like? It should probably show the most relevant aspects of a Full interpretation.

Solution: Closed with no action. A technical argument for not including such an image has been given by public email. Further, the intro has been clarified and elaborated on the topics related to such a diagram, so a diagram isn't really needed anymore.

(annotations in theorem) Explain why Correspondence Theorem does not allow Annotations

The correspondence theorem does not allow annotations on the RHS of entailments. The reason should be explicitly given.

Solution: Added an explaining paragraph below the theorem.

(iri) URIs should be changed to IRIs

Alan Ruttenberg has asked me whether the RDF-Based Semantics shouldn't switch from talking about URIs to IRIs.

There are two conflicting points here:

  • The RDF Semantics uses the term "URI reference" throughout the document, and explicitly refers to the old URI RFC.
  • All other technical documents of OWL 2 have always referred to the new IRI RFC, and in the meanwhile explicitly use the term "IRI" throughout the documents.

Now I am split: My goal wasn't only that the RDF-Based Semantics is /semantically/ compatible with the RDF Semantics, but that it also reuses the terminology used in that spec. And my strategy was that, if terminology is intended to be changed (as it probably makes sense in the case of URIs), then this change should be made in RDF not somewhere in the middle of the "SemWeb stack". On the other hand, the RDF-Based Semantics is of course obliged to keep terminologically in line with the rest of OWL 2.

So, since there is no technical backwards compatibility issue with moving from URIs to IRIs, my plan is to perform the change, but make it explicit in the document that this is a terminological deviation from the RDF Semantics.

What I want from the WG is backing of this decision, i.e. it should be primarily a WG-decision, not the decision of an editor, because I can imagine some "RDF hardliners" to come up with complaints.

Solution: Changed "URI" to "IRI", pointing to the change in both the "Introduction" and in the "Differences to OWL Full" sections.

(explain annotation) Clarify the state of Annotations in Full

There should be some note explaining that in OWL Full, annotations are not comments to syntactic entities.

Solution: Added some text to the Introduction section.

(formula rendering) Align rendering to Direct Semantics

The tables and everything else should have the same look as the Direct Semantics.

There is also a technical reason for this: Opera prints some HTML-Entities in the tables of the Direct Semantics, but not in the tables of the RDF-Based Semantics.

It would perhaps sufficient to have a dedicated table for the datatype specific semantic conditions.

Solution: Done.

(rendering alignment) Collection of editorial changes regarding rendering

  • Perhaps better write "c in IC, d_1,...,d_n in IC" instead of (currently) "c,d_1,...,d_n in IC"
  • change "1<=i!=k<=n" to style in Direct Semantics
  • check style "<x,y>, <y,z> in IEXT(p)"

Solution: Done (and additional changes, too).

(semcond intro) Revise Introduction Section on Semantic Conditions and Vocabulary Interpretations

Solution: Done.

(localization intro) Clarify Introduction Section on missing Typing Triples in Semantic Conditions

General design of semantic conditions and axiomatic triples are responsible for this.

Solution: Done.

(corresponding datatype map) Datatype Map in Correspondence Theorem

Currently, the correspondence theorem only talks about an OWL 2 Full Datatype Map. It should also talk about the "corresponding" OWL 2 DL Datatype Map.

Solution: Done.

(informative correspondence) Should the correspondence section be an informative appendix?

The correspondence between Full and DL, and in particular the comprehension principles, are not really part of OWL 2 Full. So it seems to be consequent to mark the whole section "informative".

If the section is going to be informative, then it should perhaps become an appendix.

Solution: Section is now an informative appendix.

(facet sets) Revise the facet related aspects of Datatype Maps

The DL Datatype Maps contain the facets. Without having these in the Full Datatype Maps, a rigid correspondence proof will probably not be possible.

Also, the naming conventions are different between both documents.

And the semantic conditions and comprehension principles for datatype restrictions have to be adjusted.

The wording of the definitions of the sets should be aligned with the Structural Spec.

Solution: Greatly revised.

(invalid facet premise) Comprehension Principle for Datatype Restrictions has broken premise

A premise of the form "f_i is a facet" does not work.

Solution: fixed.

(inverses comprehension) Is a comprehension principle needed for inverse property expressions?

OWL 2 DL introduces inverse property expressions. Looks like there needs to be a comprehension principle for this, either.

Would then need to be treated by Balancing, either.

Solution: Added comprehension principle with explaining text, and balancing rule.

(comprehension) Reconsider the Role of Comprehension Principles

The current state of the CPs is that they do not belong to the official semantics of OWL 2 Full, but are primarily used for proving the correspondence theorem. Actually, the proof is trivial, since the CPs introduce an inconsistency, so all entailments can be inferred. On the other hand, there should be at least a good hint to implementers how to cope with the "missing DL entailments" problem. In particular, the problem, that the "sequence guards" of the sequence based axioms are too strong for the "IF" direction. A different, more useful way to deal with CPs would be good.

Solution: The correspondence theorem is now based on the new "balancing" idea. Comprehension principles are only provided for the general case (not for comparison with DL).

(balancing) Define the OWL 2 Balancing Method

The balancing has to take into account:

  • class expressions
  • datatype restrictions
  • declarations for names that only occur on the RHS

Solution: Completed!

(separated dl) Check whether correspondence theorem requires separated vocabulary

In OWL 1, Theorem 2 required a separated voabulary for OWL DL. What about OWL 2?

Solution: Probably, there exists no Problem. There would only be a real problem for an OWL-DL/RDF language.

(difference alignment) Align expamples in "Differences" section with examples in proof

There are different examples. Check, whether this can be aligned!

Solution: Perfect alignment by same example everywhere.

(datatype conditions) Compare D semantic conditions with "Datatype Map" section

I think I have at least confused the argument to L2V: It should probably be the datatype itself, not its name.

Solution: Fixed definitions of IFS and IF2V for semantic condition on datatype restrictions.

(bnode interpretations) Check for places where "I+A" should be used instead of "I"

Solution: There are actually two examples (preceding text of the semantic conditions for classes and properties), where variables could stand for bNodes, so in these examples it would be better to have "I+A" instead of "I". However, since these examples are only informative, and since understandability outweighs rigid correctness, it has been decided to leave them as they are. In all other cases, things are correct.

(empty list) Sequence definition misses the empty case

OWL 1 Full defines the case that l = nil. This is currently missing in OWL 2 Full.

Solution: Fixed.

(literal values) Correctly say what LV contains

LV should contain not only the value spaces of the datatypes (as stated actually), but also the denotations of the plain literals, with or without language tag. There was a certain text in Full 1, and there is probably also text in the RDF Semantics.


Instead of referring to Unicode strings, as in OWL 1, I refer to "plain literals" and cite the RDF Concepts spec. This avoids the need to cite to the Unicode spec with all its version problems.

(condition satisfaction) Explain what it means that semantic conditions are satisfied

This or an other term ("meet" in OWL 1 Full) should be explained when D-interpretations are introduced. Also, the same term should be then used in the definition of OWL 2 Full interpretations.

Currently, there is a kind of explanation, but it is not quite correct: The semantic conditions do not primarily constrain graphs, but the IEXT mapping of the interpretation [FIXME].

Also, it should be listed which conditions are met by D-interpretations (Simple, RDF, RDFS and D). In OWL 1 Full, there were examples instead, but I do not consider this useful.


  • The conditions have been listed.
  • The term has been consistently changed to "meet".
  • The explanation keeps unchanged for the moment, since it is sufficiently correct.
  • If the explanation is going to be changed, then in the context of the "class satisfaction" issue, since this has to explain what the specific form of "OWL 2 Full satisfaction is".

(ontology section) Ontology Section

The RDF-Based Semantics contains a section called "Ontologies", which explains what an OWL 2 Full ontology is (an RDF graph), and defines the concept of an "Imports Closure". I am not sure whether this section should be removed from the document, or changed to say something about the (actual vs. intended) semantics of ontologies containing owl:import triples.

Solution: There is now a rewritten section, normatively only talking about the syntax of OWL 2 Full, and informatively referring to Structural Spec concerning ontology management stuff.

(correspondence intro) Correspondence Section should clarify purpose of section

People seem to have difficulties to understand what the "Correspondence Section" is about.

Solution: Rewrote the intro.

(owl dl) Define a few non-existent terms

Currently, no document calls OWL 2 DL actually OWL 2 DL. At the beginning of the Correspondence section, this name, and a few associated names, have to be introduced.

Solution: The intro now introduces at least the most important terms.

(if expressions) Consider changing all semantic conditions for expressions to Only-If

Apparently, the IFF semantics are not necessary for expressions, but make some trouble when it comes to explanation ("why are restrictions ONLY-IF, while booleans IFF are?").

Best will be to check again the example which lead to the introduction of IFF semantics, which was some Post-LC change, AFAIR.

The introductory text in OWL 1 Full (page 3) can be adjusted as an explanation then.

Solution: Not changed, since this would have been an error. The intro of the "Semantic Conditions" section says why.

(graph satisfaction) Define OWL 2 Full Satisfaction

There should be a clear definition of graph satisfaction, after OWL 2 Full interpretations have been introduced, and before consistency and entailment is defined.

After this definition exists, the short paragraph on satisfaction for D-interpretations can be removed.

Solution: Added a definition.

(nary datatypes) n-ary Datatype Extensions

I said in [1] that I believe some additional kind of extension has to be introduced to OWL 2 Full, in order to cope with n-ary datatypes. However PFPS has stated in in this email a different position that this is not necessary.

Solution: Not treated.

(nary complement) Datatype Complements have to be n-ary

The Direct Semantics defines datatype complements to be also allowed for n-ary datatypes.

Solution: Following "nary datatypes" resolution.

(proof) Correspondence Theorem needs proof

There is still no proof for the correspondence theorem. The proof will depend on the outcome of some other issues stated here:

  • issue about "Datatype Maps and Facets"
  • issue about "N-ary Datatypes"
  • issue about "Role of the Comprehension Principles" (major dependency)

The proof will most probably be only a "proof sketch", since a complete proof would probably be very large, and technically complex. Since the Full Semantics has been created closely in line with the Direct Semantics, it is probably sufficient to investigate only the bits where the two semantics actually differ, and this also only by example.

Solution: Basically completed, but ongoing refinement necessary.

(condition description) Revise descriptions of semantic condition tables

The descriptions of the semantic condition tables should be more self contained: Since these sections will primarily used as a reference, readers should not be supposed to precisely know about every aspect in the rest of the document. In particular, if semantic information is spread over several tables, or if there are certain special aspects to the semantics, these should be clearly noted in the tables description.

Solution: Done, modulo some smaller issues, marked as ednotes.

(condition ordering) The order of semantic conditions should be more aligned with DL Semantics

While the partition into tables used in the RDF-Based Semantics is not under consideration, the ordering within the tables should be better aligned with the Direct Semantics, to allow for better comparison.

Solution: Aligned order for boolean connectives and property restrictions (was already aligned for property characteristics). More alignment does not make sense, since the splitting into tables follow different strategies.

(table rendering) Rendering of Semantic Condition Tables

Some tables in the "Semantic Conditions" section are hard to read. For example, the table on boolean class expressions. Some experiments should be tried, for example with sub tables or more than one table.

Solution: Some improvements. Not perfect, but unclear how to do better. So let's wait for LC comments.

Goto OWL 2 Full Open Issues Page