Pat Hayes (and maybe Peter PatelSchneider)
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 nth 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.
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 fastOWL 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 fastOWL 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.
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.
Structural Vocabulary  rdf:first 
Classes  rdf:List 
Properties  owl:sameIndividualAs owl:sameClassAs owl:samePropertyAs owl:differentIndividualFrom owl:DisjointWith owl:complementOf owl:inverseOf 
List Properties  owl:oneOf owl:unionOf owl:intersectionOf 
Restriction Properties  owl:allValuesFrom owl:someValuesFrom owl:hasValue owl:minCardinality owl:maxCardinality owl:cardinality 
owl:onProperty
to connect a restriction class to a property and a class. Technical
comment. giving a coherent OWL semantics to this OWL/RDF syntactic trick seems
to require the use of 'intensional' classes, ie classes which are distinct but
have the same class extension, as in [RDFMT]. A simpler semantics which treated
classes simply as sets would not work without special adhoc constructions. This
point was clarified by conversations with Ian Horrocks.
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.
If E is  then ICEXT(I(E)) is 
owl:Thing  IOT, a subset of IR 
owl:Nothing  {}, the empty set 
owl:Class  IOC, a subset of IC 
owl:Property  IOP, a subset of IP 
owl:ObjectProperty  IOOP, a subset of IOP 
owl:DataTypeProperty  IODP, a subset of IOP 
owl:Restriction  IOR, a subset of IOC 
If E is  then c is in ICEXT(I(E)) iff c is in IOP and: 
owl:SymmetricProperty  if <x, y> in IEXT(c) then <y, x> is in IEXT(c) 
owl:FunctionalProperty  if <x, y1> and <x, y2> in IEXT(c) then y1 = y2 
owl:InverseFunctionalProperty  if <x1, y> and <x2, y> in IEXT(c) then x1 = x2 
owl:TransitiveProperty  if <x, y> and <y, z> in IEXT(c) then <x, z> is in IEXT(c) 
If E is  then <x,y> is in IEXT(I(E)) iff: 
owl:sameIndividualAs  x = y 
owl:sameClassAs  ICEXT(x) = ICEXT(y) and x, y in IOC 
owl:complementOf  ICEXT(x) = IOT  ICEXT(y) and x,y in IOC 
owl:samePropertyAs  IEXT(x) = IEXT(y) and x,y in IOP 
owl:differentIndividualFrom  x =/= y 
owl:disjointWith  ICEXT(x) and ICEXT(y) are disjoint and x,y in IOC. 
owl:inverseOf  <u, v> is in IEXT(x) iff <v, u> is in IEXT(y) and x,y in IOP 
If E is  then <x, y> is in IEXT(I(E)) iff x is in IOC and y is a sequence [y1,...,yn] and : 
owl:oneOf  ICEXT(x) = {y1,..., yn} 
owl:unionOf  ICEXT(x) = ICEXT(y1) union ... ICEXT(yn) 
owl:intersectionOf  ICEXT(x) = ICEXT(y1) intersection ... ICEXT(yn) 
If E is:  then IEXT(I(E)) is 
owl:onProperty  IRP, a function from IOR to IOP 
If E is:  and <x, y> is in IEXT(I(E)) then x is in IOR, y is in IOC and ICEXT(x) = 
owl:allValuesFrom  {u  if <u, v> in IEXT(IRP(x)) then v in ICEXT(y) } 
owl:someValuesFrom  {u  exists a v such that <u, v> in IEXT(IRP(x)) and v in ICEXT(y) } 
owl:hasValue  {u  <u, y> in IEXT(IRP(x)) } 
If E is:  and <x, y> is in IEXT(I(E)) then x is in IOR, y is an integer and ICEXT(x) = 
owl:minCardinality  {u  <u, v1>,....,<u, vn> all distinct in IEXT(IRP(x)) for some n >= y } 
owl:maxCardinality  {u  if <u, v1>,....,<u, vn> all distinct in IEXT(IRP(x)) then n <= y } 
owl:cardinality  {u  <u, v1>,....,<u, vn> all distinct in IEXT(IRP(x)) iff n = y } 
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:
if x is in IOP, then IEXT(x) is a set of pairs <x,y> with x in IOT and y in (IOT union LV) 
if x is in IOC, then ICEXT(x) is a subset of IOT 
if x is in IOP and <x,y> is in IEXT(I(rdfs:domain)) then y is in IOC 
(We do not require an analogous conditions on rdfs:range in order to allow for nonOWL 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:
For any finite subset S of IOT, there is an x in IOC with ICEXT(x) = S 
For any x in IOC, there is a y in IOC with ICEXT(y) = IOT – ICEXT(x) 
For any C1,C2 in IOC, there are x and y in IOC with
ICEXT(x) = C1 intersection C2 and ICEXT(y) = C1 union C2 
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 nary 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.)
owl:Thing rdf:type owl:Class . owl:Class rdf:subClassOf rdfs:Class . 
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.)
this:  entails this: 
AAA rdf:type owl:Property . 
AAA rdfs:domain owl:Thing 
AAA rdf:type CCC . 
BBB rdf:type CCC . 

AAA owl:sameClassAs BBB . 

AAA owl:samePropertyAs BBB . 
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 builtin 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 .
weakOWL 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
weakOWL 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 weakOWL 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 weakOWL 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 builtin 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 .
weakOWL 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.
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 NPcomplete.) 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:
IOT = IR 
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 largeOWL knowledge base, is sufficient.

Any OWL/RDFgraph which entails the large OWL knowledge base is said to be a largeOWL graph. Obviously, the localization assertions now follow trivally, so we will omit them when discussing largeOWL graphs.
The appropriate closure conditions to add for the largeOWL 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.)
for any x which is  and p in  there is a y in IOR with IRP(y)=p and <y, x> in: 
in IC  IOP  IEXT(I(owl:allValuesFrom)) 
in IC  IOP  IEXT(I(owl:someValuesFrom)) 
in IR  IOP  IEXT(I(owl:hasValue)) 
a nonnegative integer  IOP  IEXT(I(owl:minCardinality)) 
a nonnegative integer  IOP  IEXT(I(owl:maxCardinality)) 
a nonnegative integer  IOP  IEXT(I(owl:cardinality)) 
We will say that a weak OWL interpretation of a graph G is a largeOWL interpretation of G if it satisfies the large closure conditions. Usually this is of interest only when G is a largeOWL 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 renaming conventions used. We therefore recommend that users who prefer to use OWL reasoning in the large make this explicit by importing or adding the largeOWL 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.
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 nonexistent class is named for Bertrand Russell, who used it to show that Frege's original set theory was inconsistent. In largeOWL/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 nonparadoxical 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 classdefining 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 semidecideable. This is of course the normal situation for users of such an expressive language: it might be called the firstorder 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, fastOWL is a decideable language so that contradictions can be detected reliably and even fairly efficiently. [reference? Ian??]
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:
this:  largeOWL entails this: 
John rdf:type _:y . _:y owl:complementOf _:x . _:x unionOf _:l1 . _:l1 owl:first Student . _:l1 owl:rest _:l2 . _:l2 owl:first Employee . _:l2 owl:rest owl:nil . 
John rdf:type _:z . _:z owl:complementOf Student . 
John friend Susan . 
John rdf:type _:x . _:x owl:onProperty friend . _:x owl:minCardinality 1 . 
John rdf:type owl:Object 
John rdf:type _:x . _:x owl:oneOf _:l . _:l owl:first John . _:l owl:rest owl:nil . 
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 largeOWL 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.
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 freewheeling 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 largeOWL 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 fastOWL 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 wellformed 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:
IOT, IOC, IOOP, IODP, ICEXT(I(rdf:List)) and LV are
pairwise disjoint (that is, none of them have anything in common with
any of the others), and none of them contain the denotations of anything
in the RDF, RDFS or OWL namespaces.. 
Second, the large closure conditions given above for large OWL need to be restated 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 finergrained version of the table of large closure restrictions in section 4.They represent the appropriate limitations of the same closure rules to the 'layered' fastOWL universe.(These are taken from Peter's document.)
for any x which is  and p in  there is a y in IOR with IRP(y)=p and <y, x> in: 
in IOC  IOOP  IEXT(I(owl:allValuesFrom)) 
a datatype or sequence of datatype values  IODP  IEXT(I(owl:allValuesFrom)) 
in IOC  IOOP  IEXT(I(owl:someValuesFrom)) 
a datatype or sequence of datatype values  IODP  IEXT(I(owl:someValuesFrom)) 
in IOT  IOOP  IEXT(I(owl:hasValue)) 
a datatype value  IODP  IEXT(I(owl:hasValue)) 
a nonnegativeinteger  IOP  IEXT(I(owl:minCardinality)) 
a nonnegativeinteger  IOP  IEXT(I(owl:maxCardinality)) 
a nonnegativeinteger  IOP  IEXT(I(owl:cardinality)) 
A weak OWL interpretation of a fastOWL graph G which satisfies these conditions is a fastOWL interpretation. FastOWL 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 fastOWL inference rule must preserve fastOWL 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:
owl:SymmetricProperty
rdf:subClassOf owl:ObjectProperty . owl:InverseFunctionalProperty rdf:subClassOf owl:ObjectProperty . owl:TransitiveProperty rdf:subClassOf owl:ObjectProperty . 
and fast OWL also supports the following additional inference principles:
this:  fastOWL entails this: 
AAA rdf:type owl:DataTypeProperty 
AAA rdf:range owl:DataTypeValue 
AAA rdf:type owl:ObjectProperty 
AAA rdf:range owl:Thing 
Provided that the expressions involved are fastOWL 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 fastOWL 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, fastOWL 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 finegrained localizing information about the entities that are inferred to exist. In large OWL the required localizing assertions all follow trivially from the largeOWL KB, so can be ignored.
In fast OWL one can repair missing localizations in any separatedsyntax 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 fastOWL KB the localization of the KB. It should be the case that fast OWL mirrors the OWL abstractsyntax MT in the following sense: given any abstract OWL expressions E, F, then E OWLentails F iff the localization of the translation of E fastOWL entails the translation of F; from which it follows that it fastOWL entails the localization of the translation of F. Thus, localizations of translations provide an accurate RDF 'mirror' for abstract OWL, under the fastOWL semantic conditions.
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, largeOWL classes, being all RDFS classes, can contain classes and properties.
The resulting language is essentially a firstorder set theory which does not fit into any useful complexity class. Inconsistency is undecideable, and entailment is semidecideable. 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 fastOWL legal, so each case must be checked to ensure that the merged vocabulary is separated.In a fastOWL universe, OWL classes cannot contain other OWL classes or properties. Comment. It would be possible for an OWL class to contain nonOWL 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 fastOWL syntactic separation conditions, so could not be considered valid fastOWL conclusions or assumptions.
FastOWL/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 descriptionlogic reasoners.
OWL/RDF as a carrier for abstract OWL
A particular case of fastOWL 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 nonRDFbased 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 abstractsyntax 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 fastOWL graph, and there is no guarantee that an RDF merge of two fastOWL graphs is fastOWL 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 weakOWL 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 weakOWL conclusions. This might be called the lesser spotted OWL option.
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 generalpurpose 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.
[RDFMT] RDF MT
[OWLAS] Owl Abstract Syntax
[PFPSOWLMT] Peter's OWL model theory draft
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.