Layering RDFS into OWL

Pat Hayes (and maybe Peter Patel-Schneider)

-1. Status of this document.

This is a draft intended for discussion within the WebOnt WG. It is not in any way definitive. Comments look like this and can be omitted on a first reading. This is used for highlighting semantic conditions.This is used to indicate truths and inference rules. Changes (other than deletions and minor typos) indicated this way. This is the n-th version for some reasonably large n, drafted 9/22/02 and modified 9/23/02 in response to Peter's comments.

NOTE. This document is written under the assumption that several changes have been made to the RDF MT. We assume that an appropriate semantics is available for the rdf:List vocabulary which guarantees that the root node of a properly formed RDF list graph always denotes a finite sequence; we will indicate such sequences by the use of square brackets without further comment. We also assume that the semantic conditions on rdfs:subClassOf and rdfs:subPropertyOf have been strengthened to 'iff' conditions on the class and property extensions. This fixes a bug in the [RDFMT] noted recently by Peter.

1. The OWL and RDFS universes

All of the OWL vocabulary is defined on the 'OWL universe', which is a collection of RDFS classes which are intended to circumscribe the domain of application of the OWL vocabulary: owl:Thing, owl:Class and owl:Property.

In this document, we give essentially two versions of OWL, which we will call respectively 'large OWL' and 'fast OWL'. Large OWL identifies the OWL and RDFS universes, and the OWL vocabulary applies to the entire RDFS universe without restriction, but there are no guarantees of deductive efficiency. In fast OWL, the OWL universe is assumed to be a restricted subset of the RDFS universe, and the OWL vocabulary can only be used in a restricted fashion corresponding to the OWL abstract syntax; but the language can be processed by efficient DL reasoners. Both versions of the language support all 'natural' entailments, but the semantic conditions need to be stated slightly differently in the two cases.The part of the language common to both large and fast OWLs is called 'weak OWL', and we give that first in order to emphasise the extent of this commonality.

Both large OWL and fast OWL can be given a simpler semantics, but the simplifications are not compatible with each other. For example, large OWL does not need to make the distinctions between the OWL and RDFS domains, and classes like owl:Class are irrelevant. We have tried here to emphasise the similarities rather than make use of such possibilities for mathematical optimization.

The chief differences in practice between the two versions lie in the care which is required to ensure that the syntactic forms used are legal. In large OWL, no care is needed. In fast OWL, considerable care is needed. If using the fast-OWL conventions within a larger enclosing RDF theory, this need for care is manifested by the need to include explicit assumptions about classes and properties being in owl:Class and owl:Property, and individuals being in owl:Thing. These localizing assumptions are all trivially true in large OWL, and can also be ignored when one conforms to the OWL abstract syntax, since that syntax guarantees that only things in the relevant classes can be mentioned. But using a mixture of fast-OWL and RDF would require paying close attention to which parts of the vocabulary can be 'legally' used to refer to things in the OWL universe, and restricting the OWL inference machinery to that subset.

2. OWL/RDF syntax.

We will follow the general rules of the translation of OWL into RDFS described in [OWLAS]. In particular, we will use the same syntactic device of OWL lists encoded as RDF graphs, and the same convention of three triples to encode a restriction.

We will consider the following OWL vocabulary.

3. Weak semantics for the OWL/RDF vocabulary.

We first state the basic ('weak') semantic conditions for the OWL vocabulary. These do not fully capture the OWL meaning, but they can be safely assumed by all users of OWL in any version. Basically, the semantics given here provides for the use of the OWL vocabulary in a simple assertional mode, where each triple makes an assertion about the entities named in it, but there is no presumption made that any restriction classes exist other than the ones named explicitly in the axioms and their simple Boolean combinations.

Note that owl:sameIndividualAs and owl:differentIndividualFrom are defined on the whole RDFS universe, in contrast to the rest of the OWL vocabulary. This is not essential, but it is harmless and useful.

We also impose the following owl universe conditions which ensure that the OWL universe follows the same internal rules as the RDFS universe:

(We do not require an analogous conditions on rdfs:range in order to allow for non-OWL classes being used as datatypes.)

Fianlly, we impose the following weak closure conditions on IOC. It is required to contain classes corresponding to all finite subsets and all unions, intersections and relative complements:

These guarantee that the elementary set construction assertions are always meaningful. (Mathematically, these can be summarised by saying that IOC contains elements corresponding to the finitely generated Boolean algebra over IOT.) Note that the empty set is a finite subset of IOT, and the complement of the empty set is IOT, so IOC must contain classes with these extensions.

The analogous closure conditions on restrictions are given later. They need to be stated differently depending on which way one wishes to complete the definition of the language.

Comments and notes.

The semantic conditions on owl:Thing, owl:Class and owl:Property exactly correspond to those for rdf:Resource, rdfs:Class and rdf:Property respectively, but restricted to the OWL universe. We make use of this in defining 'large OWL'

The weak semantics of owl:FunctionalProperty and owl:UniqueProperty are identical, but we give them both here since in the strong version of the semantics they apply to different subsets of the universe. Note that complementation is defined relative to the class of OWL things.

Note that sameClassAs applies only to OWL classes and means having the same class extension as; this is not exactly the same meaning as identity between classes, since two or more distinct classes might have the same class extension. Similarly for samePropertyAs. This means, for example, that

A P V .
A owl:sameClassAs B .

do not entail B P V , given only this semantics. Similarly, properties of properties, such as rdfs:range and rdfs:domain, are not necessarily preserved under owl:samePropertyAs. The only true identity relation here is owl:sameIndividualAs, which might be better named simply 'owl:sameAs' .

The use of lists in OWL/RDF is to provide a single argument which encodes a sequence of arguments. In a familiar transformation, an n-ary function is redescribed as a unary function on a sequence with n elements.

Restrictions are classes defined in terms of properties and other classes. OWL/RDF uses an auxiliary property owl:onProperty to state the connection between a restriction and the property used to define it. We give the interpretation of owl:onProperty the name IRP (Interpretation Restriction Property) in order to emphasize this special role. Note that it is required to be a function, i.e. it associates a unique property with every restriction. This construction depends on the fact the RDFS classes are intensional, since this allows several distinct classes to share the same extension. When we state the closure conditions for restrictions this will be important, as those conditions require restriction classes to exist corresponding to every class/property combination, and so we need a 'stock' of classes, many of which may have the same extensions, to provide arguments for the IRP function.

We will call an RDFS interpretation which satisfies the above conditions a weak OWL interpretation, and refer to weak OWL consistency, weak OWL entailment, etc. in the usual way. Weak OWL interpretations make a number of triples always true, and we list them here as the weak OWL knowledge base. These are shared by all versions of OWL, so can be safely taken as true by all users of the OWL vocabulary.(This is based on Peter's 'O' KB, with minor changes and some additions.)

There are also several patterns of entailment (ie, inference rules) which can be used to draw conclusions which are valid under this semantics. (We do not claim that this set is complete.)

3.1 Entailments with the weak semantics

With the semantic conditions stated so far, the OWL vocabulary can be used within an arbitrary RDF graph, but it only makes meaningful assertions about things in the OWL universe, and only draws a limited range of conclusions, since there are no built-in assumptions about which RDF entities are in the OWL universe.

For example,

JohnClass owl:oneOf _:1 .
_:1 rdf:first John .
_:1 rdf:rest rdf:nil .

weak-OWL entails

John rdf:type JohnClass .

as one might expect, but there is a subtlety in the reasoning: the antecedent's use of owl:oneOf implicitly asserts that John is an owl:Thing and JohnClass is an owl:Class. However, the following graph could be false in a weak-OWL interpretation:

John rdf:type _:x .
_:x owl:oneOf _:1 .
_:1 rdf:first John .
_:1 rdf:rest rdf:nil .

since the relevant OWL class might not exist; for example, if John is not an owl:Thing. (The list would exist, but that is not in itself enough to establish that what it contains is in the OWL universe.) Similarly,

John rdf:type Student .
John rdf:type Employee .

does not weak-OWL entail

John rdf:type _:x .
_:x owl:intersectionOf _:l1 .
_:l1 rdfl:first Student .
_:l1 rdf:rest _:l2 .
_:l2 rdfl:first Employee .
_:l2 rdf:rest rdf:nil .

in spite of the weak closure conditions, since Student may not be an owl:Class. In order to obtain the intuitive conclusions, we must add 'localizing' assertions of the form

.... rdf:type owl:Thing/Class/Property .

which ensure that the user urirefs refer to things in the appropriate parts of the OWL universe, in order to ensure that the required conclusions follow. Sometimes, as in the first example above, these can be inferred from the domain and range conditions on the OWL vocabulary, but in general, care is needed. When localizing assertions are added, the weak semantic conditions suffice to establish the intuitive conclusions: the above graph is weak-OWL entailed by

John rdf:type owl:Thing .
John rdf:type Student .
John rdf:type Employee .
Student rdf:type owl:Class .
Employee rdf:type owl:Class .

When it comes to restrictions, the OWL vocabulary only conveys part of the full OWL meaning, so that many 'natural' entailments do not go through. For example, one might expect that

John friend Susan .
John rdf:type owl:Thing .
Susan rdf:type owl:Thing .
friend rdf:type owl:Property.

would entail

John rdf:type _:x .
_:x owl:onProperty friend .
_:x owl:minCardinality 1 .

since it seems obvious that Susan's friendship is enough to conclude that John is in the class of people with at least one friend, and all the vocabulary is properly located; but this inference is not valid (with the semantic conditions so far) since the antecedent does not guarantee that there is a restriction class of John's friends, i.e. that this class actually exists. In general, this semantics provides no guarantee that any restriction classes exist other than those that are actually named in some way in the antecedents: it has no built-in assumptions about restrictions on properties actually existing. Note that if we had actually given the restriction a name, thereby establishing that it does exist, then we could make the analogous inference:

John friend Susan .
John rdf:type owl:Thing .
Susan rdf:type owl:Thing .
friend rdf:type owl:Property.
HasFriend owl:onProperty friend .
HasFriend owl:minCardinality 1 .

weak-OWL entails

John rdf:type HasFriend .

The next two sections discuss two different strategies for extending OWL entailment to encompass the full range of intuitively valid conclusions from an OWL/RDF graph.

4. Large OWL

One possible way to use the OWL vocabulary is to assume that the OWL and RDFS universes are identical. The resulting language can express some surprising contradictions, and the general task of detecting inconsistencies is probably undecideable in general, and even when it can be decided it is of unknown complexity (but almost certainly NP-complete.) This might be called the dangerous option. Users who are willing to take the computational risks inherent in this freewheeling use of the OWL vocabulary gain some flexibility in composing and using it.

Using the OWL vocabulary without restrictions in this way means that many of the distinctions which motivate the use of the OWL classifications become meaningless, so that much of the 'basic' vocabulary becomes redundant. For example, owl:Thing and rdf:Resource have the same extension, as do owl:Class and rdfs:Class. The basic semantic assumptions are trivial to state:

One can obtain this option by adding enough extra assertions to force these identities to hold. This can be done in various ways, but the following, which we will refer to as the large-OWL knowledge base, is sufficient.

Any OWL/RDFgraph which entails the large OWL knowledge base is said to be a large-OWL graph. Obviously, the localization assertions now follow trivally, so we will omit them when discussing large-OWL graphs.

The appropriate closure conditions to add for the large-OWL semantics are also straightforward to state: any combination of class and property should define an appropriate restriction class. We will call these the large closure conditions. These guarantee that the the universe contains classes corresponding to the restriction operations. (Note that the existence of the relevant class does not imply that its extension is nonempty: many restrictions, eg a restriction on a property to a class disjoint from its range, will simply define a class with an empty extension.)

We will say that a weak OWL interpretation of a graph G is a large-OWL interpretation of G if it satisfies the large closure conditions. Usually this is of interest only when G is a large-OWL graph.

Obviously, one could simplify large OWL by identifying the OWL and RDFS universes, abandoning the redundant distinctions, and simply using rdf:Resource instead of owl:Thing and so on. The basic OWL classes could then be eliminated from the language, and the ranges and domains of the rest of the OWL vocabulary could be relaxed to the analogous RDFS domains and ranges. However, that strategy would result in a genuinely different language, and would require reasoners to be aware of the re-naming conventions used. We therefore recommend that users who prefer to use OWL reasoning in the large make this explicit by importing or adding the large-OWL KB into their graphs. Once that is done, of course, it follows for example that

owl:Class owl:sameClassAs rdf:Resource .
owl:Property owl:SameClassAs rdf:Property .

so that the RDFS class names may be freely used instead of the OWL class names elsewhere in the graph.

Large OWL retains the distinction between owl:ObjectProperty and owl:DataTypeProperty, but makes no assertions about them other than being subclasses of owl:Property.

5.1 Contradictions in large OWL.

Since owl:complementOf is essentially negation (it takes the complement with respect to IOT, which is the entire universe IR in large OWL), it is easy to write OWL graphs which are contradictory, i.e. have no satisfying interpretations. Perhaps the simplest way to do this is by saying that a class exists which is identical with its own complement:

_:y owl:complementOf _:y .

The semantic conditions provide no way to satisfy this, since in order to satisfy the owl: complementOf conditions IOT would have to be empty, in which case there is nothing for _:y to denote.

One particularly famous kind of contradiction arises when one says that some class contains only those classes that do not contain themselves, and asks whether it contains itself. This non-existent class is named for Bertrand Russell, who used it to show that Frege's original set theory was inconsistent. In large-OWL/RDF the 'circularity' of this definition poses no problem, and it might for example be expressed by the following graph:

ex:Russell owl:complementOf _:z .
_:z rdf:type owl:Restriction .
_:z owl:onProperty rdf:type .
_:z owl:hasValue _:z .

This is often called 'Russell's paradox', but in fact it has a non-paradoxical conclusion, which is that there is no such class (of things that do not contain themselves), i.e. that the above graph is unsatisfiable. (Frege regarded this as 'paradoxical' because his set theory incorporated the assumption that any description defined a class, an idea which is now recognized as hopelessly optimistic.) Large OWL does not make any such assumptions about its class-defining vocabulary. The strong closure conditions guarantee that if _:y is a class then it has a complement, but they do not of course guarantee that this complement can possibly be _:y itself. The situation is analogous to using arithmetic terms to write equations. We know that given any integers, their sums, products and negatives exist; but that does not guarantee that all equations have integer solutions. The first contradiction above is like saying that an integer y exists which satisfies y = 1 – y, which is of course simply false. What the second example illustrates, however, is that detecting contradictions in large OWL is likely to be a very complex task in general, since they can arise from very subtle chains of reasoning. Most contradictions are not so overtly clear as they are in the first example. In general, users of large OWL need to be aware that they any process which combines or composes OWL graphs runs the risk of generating inconsistency, and that the task of detecting those inconsistencies is, in general, only semi-decideable. This is of course the normal situation for users of such an expressive language: it might be called the first-order existential condition.

Fast OWL, described below, provides an extra layer of protection against such contradictions by imposing syntactic restrictions which make it syntactically impossible to construct 'circular' descriptions like the Russell above graph. It is still possible to construct inconsistencies in fast OWL, but the syntactic restrictions also make it much easier to detect them; in particular, fast-OWL is a decideable language so that contradictions can be detected reliably and even fairly efficiently. [reference? Ian??]

5.2 Some large-OWL entailments

In large OWL, simply using a uriref as the value of rdf:type implicitly asserts that it denotes an OWL class, since every RDFS class is an OWL class. There is therefore no need to make localizing assertions explicit in order to draw the 'intuitive' entailments that one would expect from a straighforward reading of the OWL/RDF vocabulary. These include entailments involving the existence of unnamed restrictions, which are not sanctioned by weak OWL entailment. Moreover, since complementation is defined relative to the entire RDFS class universe, the semantic conditions on union and intersection obey the usual duality conditions (deMorgan's laws) on all RDFS classes:

To illustrate the reasoning for the first example: the weak closure conditions guarantee that the relevant _:z exists provided Student and Employee are OWL classes; the large-OWL graph conditions guarantee that they are OWL classes; and the semantic conditions on complementOf and unionOf guarantee that John is in _:z 's class extension.

6. Fast OWL.

The other option takes weak OWL/RDF in a different direction, one which corresponds more closely to the design of the OWL abstract syntax [OWLAS]. This envisions OWL as talking about a much more restricted kind of universe than the rather free-wheeling RDFS universe. In this version of OWL/RDF, the OWL universe is strictly layered into individual 'things' which can have properties and be in classes, classes of things, and properties of things; and the properties are segregated into those which take things as values and those which only take datatypes as values. Classes cannot contain other classes or properties, and properties cannot have classes as values, or be applied to classes. (Classes which contain themselves are right out.)

Under these conditions, of course, the large-OWL knowledge base would be quite unacceptable: it would have consequences that would be considered syntactically illegal. This means that one can say fewer things in fast OWL than in large OWL. On the other hand, many users are quite comfortable with these restrictions, one can get much better performance from inference engines by staying inside the fast OWL framework.

Not every OWL/RDF graph is legal in fast OWL, so before giving the extra semantic conditions we first define the basic syntactic legality conditions. Consider all the bnodes and urirefs in the graph other than those in the RDFS and OWL vocabularies: call this the set of names in the graph. In order to be legal for fast OWL, the names must be separated so that no name refers to more than one of an OWL individual, class, object property, datatype property or datatype value. The fast-OWL semantic conditions make sense only when applied to a vocabulary which is separated in this way. (This notion from Peter.) This separation needs to be consistent through lists, so that any list used in the graph must mention only things from one of the above categories. This means that for each node in the graph, we can classify it according to which part of the OWL universe, or what kind of sequence, it can refer to. We will refer to these names respectively as <individual> (referring to IOT), <class> (to IOC) , <oproperty> (to IOOP) <dtproperty> (to IODP) and <dtv> (to LV) when giving the semantic conditions below. Second, the RDF, RDFS or OWL vocabulary cannot be used to refer to anything in any part of the OWL universe. Examples like the Russell set (which treats rdf:type as an OWL property) are syntactically illegal in fast OWL. What this means is that fast OWL treats the RDF/S/OWL vocabulary as a logical vocabulary whose role is best thought of as part of the syntax of the language itself, and enforces a strict separation between this logical vocabulary and the application vocabulary of individual, class and property names which are used by a particular KB. Seen from this 'layered' perspective, the RDF(S) style of usage, where for example one uses rdfs:range to fix the rdfs:range of itself, and rdfs:Class is itself an rdfs:Class, seems to confuse language and metalanguage.

Any OWL/RDF KB which is obtained by translating from a piece of well-formed OWL abstract syntax [OWLAS] will satisfy these conditions.

The extra semantic conditions for fast OWL all amount to imposing extra conditions on the OWL universe. First, there are restrictions:

Second, the large closure conditions given above for large OWL need to be re-stated to take into account these restrictions on the OWL universe and ensure that all the entities in the closures are in the appropriate parts of the universe. The following table of fast closure conditions should be thought of as a finer-grained version of the table of large closure restrictions in section 4.They represent the appropriate limitations of the same closure rules to the 'layered' fast-OWL universe.(These are taken from Peter's document.)

A weak OWL interpretation of a fast-OWL graph G which satisfies these conditions is a fast-OWL interpretation. Fast-OWL satisfiability, entailment etc. are defined as usual. Note however that these concepts are meaningless when applied to RDF graphs that do not conform to the syntactic form required for fast OWL. This means that a fast-OWL inference rule must preserve fast-OWL syntactic wellformedness, as well as truth, in order to be correct.

Fast OWL makes a larger set of RDF triples universally true in addition to those in the weak knowledge base. They include the following fast knowledge base:

and fast OWL also supports the following additional inference principles:

6.1. Entailments in fast OWL.

Provided that the expressions involved are fast-OWL legal, fast OWL supports similar basic entailments as large OWL, except that it is now necessary in general to make the locating assumptions explicit, and moreover one can draw more conclusions about the OWL types of inferred classes. For example,

John friend Susan .

does not fast-OWL entail

John rdf:type owl:Thing .
Susan rdf:type owl:Thing .
friend rdf:type owl:ObjectProperty .

and so all this would need to be added explicitly as an antecedent in order to draw the conclusion

John rdf:type _:x .
_:x owl:onProperty friend .
_:x owl:minCardinality 1 .

(compare 5.2). However, one can now also conclude from

_:y rdf:type _:x .

that

_:y rdf:type owl:Thing .

since the fast semantic closure conditions also locate the domain and range of the restriction in the proper parts of the OWL universe. In general, fast-OWL assertions used in an RDF context need to be supported by explicit localizing assertions which ensure that the user urirefs refer to things in the relevant part of the OWL universe, but they also allow one to infer more fine-grained localizing information about the entities that are inferred to exist. In large OWL the required localizing assertions all follow trivially from the large-OWL KB, so can be ignored.

In fast OWL one can repair missing localizations in any separated-syntax KB by adding a particular set of localizing assertions consisting of all triples of the form

<individual> rdf:type owl:Thing .
<class> rdf:type owl:Class .
<oproperty> rdf:type owl:ObjectProperty .
<dtproperty> rdf:type owl:DataTypeProperty .

Call the result of adding all such assertions to a fast-OWL KB the localization of the KB. It should be the case that fast OWL mirrors the OWL abstract-syntax MT in the following sense: given any abstract OWL expressions E, F, then E OWL-entails F iff the localization of the translation of E fast-OWL entails the translation of F; from which it follows that it fast-OWL entails the localization of the translation of F. Thus, localizations of translations provide an accurate RDF 'mirror' for abstract OWL, under the fast-OWL semantic conditions.

7. Options for combining OWL with RDF: Summary.

The above can all be summed up by saying that one can use the OWL/RDF vocabulary in different modes or styles, which have a great deal in common but differ on what is the proper relationship between the OWL and RDF vocabularies. Here are the options that seems to be clearly viable, with their respective pros and cons.

Large OWL/RDF

This simply uses the OWL vocabulary freely in an RDF(S) context, imposing no extra syntactic restrictions. The OWL and RDFS universes are identified; owl:Thing, owl:Class and owl:Property are treated as synonymous with rdf:Resource, rdfs:Class and rdf:Property respectively.

This obviously gives the most expressive freedom and allows OWL to be used throughout arbitrary RDF KBs, and intermixed with other vocabulary. In particular, large-OWL classes, being all RDFS classes, can contain classes and properties.

The resulting language is essentially a first-order set theory which does not fit into any useful complexity class. Inconsistency is undecideable, and entailment is semi-decideable. There are no useful complexity restrictions on complete inference engines. Particular subcases of the language may be tractable, of course, but there will be no generally efficient complete inference method which is guaranteed to terminate.

Fast OWL/RDF

This restricts the OWL vocabulary to expressions which use only a separated application vocabulary. The OWL universe is a strict subset of the RDFS universe, and OWL entailments will only hold when the appropriate OWL localization conditions are added for user urirefs.

This requires parsers to check OWL/RDF KBs for syntactic conformity, limits the things that can be said using the vocabulary, and restricts useful OWL entailments to limited parts of the RDFS universe. Provided that the localization conditions are made explicit, this allows fast RDF to be merged with other RDF content, but the OWL vocabulary cannot be used freely. Also, there is no general guarantee that an RDF merge of fast OWL graphs is fast-OWL legal, so each case must be checked to ensure that the merged vocabulary is separated.In a fast-OWL universe, OWL classes cannot contain other OWL classes or properties. Comment. It would be possible for an OWL class to contain non-OWL classes and properties, but OWL would be obliged to treat them as individuals. Any triples which mentioned them in a class or property context would violate the fast-OWL syntactic separation conditions, so could not be considered valid fast-OWL conclusions or assumptions.

Fast-OWL/RDF is computationally fairly tractable. Consistency is decideable.(In fact this requires some additional syntactic conditions which forbid the use of transitive properties in restrictions: see [OWLAS]) Inference and satisfiability can be handled by efficient description-logic reasoners.

OWL/RDF as a carrier for abstract OWL

A particular case of fast-OWL is obtained by restricting the language to expressions which result from applying the translation of the OWL abstract syntax into RDF [OWLAS]. This treats OWL/RDF as a 'surface notation' for OWL considered as a non-RDF-based language.

There is no need to check the OWL/RDF for wellformedness since this is guaranteed; and there is no need to include the localizing assertions explicitly, since it is syntactically impossible to refer to which is anything not in the OWL universe, so they can be simply assumed to be universally true. However, it is not in general possible to merge this OWL/RDF with any other piece of RDF without violating these conditions.

This has the same computational properties as the previous option but also provides a syntactic interface route to the reasoners (via an abstract-syntax OWL parser).

Weak OWL

All of the above options have potential negative consequences for freely merging RDF graphs containing OWL vocabulary. For example, the strong OWL option is inconsistent with a fast-OWL graph, and there is no guarantee that an RDF merge of two fast-OWL graphs is fast-OWL legal. Restricting entailments to the weak OWL semantics is the option that preserves the most interoperability, since weak OWL imposes no syntactic constraints of its own and all weak-OWL entailments are also valid under the other OWL use modes.

Weak OWL however does not support many intuitively correct inferences involving restrictions, and does not guarantee that any efficient reasoning strategy will be available. It seems likely that weak OWL has the same inferential complexity as large OWL. The 'safest' strategy would therefore be to conform to the syntactic constraints of fast OWL but only draw weak-OWL conclusions. This might be called the lesser spotted OWL option.

7.1 Other possible options

In many ways, large OWL and fast OWL represent two extremes in a range of possibilities. Different versions of the language impose varying syntactic restrictions on the same basic set of meanings. The care needed to keep the options separate is made necessary by the implicit assumptions and simplifications which rely on these incompatible syntactic restrictions.

It might be worth trying to come up with a general-purpose way to state such syntactic restrictions, thereby providing a single framework within which the various versions of the language could coexist without being accidentally injured by the implicit assumptions made by some other version. But there may not be time to do this in the life of the Webont WG.

8. References

[RDFMT] RDF MT

[OWLAS] Owl Abstract Syntax

[PFPSOWLMT] Peter's OWL model theory draft

9. PS. A metaphor.

After writing the above an analogy occurred to me. Imagine that we wish to interact only with good people. One way to do this is to simply decide that everyone is good, which is a strategy that is easy to apply but has some risks. Another way to do it is to find a place where all the people are in fact good and stay in that place, but that limits ones ability to make acquaintances. Both of these have the advantage that having made one's decision, one can effectively forget about goodness altogether. Those who are unable or unwilling to adopt either of these strategies are obliged to check everyone they meet in order to see who is good and who is not, and to take care only to associate with the former, which requires constant vigilance and effort. These three options correspond respectively to large OWL/RDF, fast OWL/RDF used solely to convey abstract OWL, and fast OWL/RDF used in an RDF context.