【OWL】：Web Ontology Language
【OWL】：Web Ontology Language
目录
1. Introduction
2. What is OWL 2?
3. Modeling Knowledge: Basic Notions
4. Classes, Properties, and Individuals – And Basic Modeling With Them
4.1 Classes and Instances
4.2 Class Hierarchies
4.3 Class Disjointness
4.4 Object Properties
4.5 Property Hierarchies
4.6 Domain and Range Restrictions
4.7. Equality and Inequality of Individuals
4.8. Datatypes
5. Advanced Class Relationships
5.1 Complex Classes
5.2 Property Restrictions
5.3 Property Cardinality Restrictions
5.4 Enumeration of Individuals
6. Advanced Use of Properties
6.1. Property Characteristics
7. Advanced Use of Datatypes1. Introduction
The W3C OWL 2 Web Ontology Language (OWL) is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things. OWL is a computational logic-based language such that knowledge expressed in OWL can be reasoned with by computer programs either to verify the consistency of that knowledge or to make implicit knowledge explicit. OWL documents, known as ontologies, can be published in the World Wide Web and may refer to or be referred from other OWL ontologies. OWL is part of the W3C's Semantic Web technology stack, which includes RDF [RDF Concepts] and SPARQL [SPARQL].
2. What is OWL 2?
- OWL 2 is a language for expressing ontologies.
- The term ontology has a complex history both in and out of computer science, but we use it to mean a certain kind of computational artifact – i.e., something akin to a program, an XML schema, or a web page – generally presented as a document.
- An ontology is a set of precise descriptive statements about some part of the world (usually referred to as the domain of interest or the subject matter of the ontology). Precise descriptions satisfy several purposes: most notably, they prevent misunderstandings in human communication and they ensure that software behaves in a uniform, predictable way and works well with other software.
- In order to precisely describe a domain of interest, it is helpful to come up with a set of central terms – often called vocabulary – and fix their meaning. Besides a concise natural language definition, the meaning of a term can be characterized by stating how this term is interrelated to the other terms. A terminology, providing a vocabulary together with such interrelation information constitutes an essential part of a typical OWL 2 document. Besides this terminological knowledge, an ontology might also contain so called assertional knowledge that deals with concrete objects of the considered domain rather than general notions.
- OWL 2 is not a programming language.
- OWL 2 is declarative, i.e. it describes a state of affairs in a logical way. Appropriate tools (so-called reasoners) can then be used to infer further information about that state of affairs. How these inferences are realized algorithmically is not part of the OWL document but depends on the specific implementations.
- OWL 2 is not a schema language for syntax conformance.
- Unlike XML, OWL 2 does not provide elaborate means to prescribe how a document should be structured syntactically. In particular, there is no way to enforce that a certain piece of information (like the social security number of a person) has to be syntactically present. This should be kept in mind as OWL has some features that a user might misinterpret this way.
- OWL 2 is not a database framework.
- Admittedly, OWL 2 documents store information and so do databases. Moreover a certain analogy between assertional information and database content as well as terminological information and database schemata can be drawn. However, usually there are crucial differences in the underlying assumptions (technically: the used semantics). If some fact is not present in a database, it is usually considered false (the so-called closed-world assumption) whereas in the case of an OWL 2 document it may simply be missing (but possibly true), following the open-world assumption. Moreover, database schemata often come with the prescriptive constraint semantics mentioned above. Still, technically, databases provide a viable backbone in many ontology-oriented systems.
3. Modeling Knowledge: Basic Notions
OWL 2 is a knowledge representation language, designed to formulate, exchange and reason with knowledge about a domain of interest. Some fundamental notions should first be explained to understand how knowledge is represented in OWL 2. These basic notions are:
- Axioms: the basic statements that an OWL ontology expresses
- Entities: elements used to refer to real-world objects
- Expressions: combinations of entities to form complex descriptions from basic ones
While OWL 2 aims to capture knowledge, the kind of “knowledge” that can be represented by OWL does of course not reflect all aspects of human knowledge. OWL can be considered as a powerful general-purpose modeling language for certain parts of human knowledge. The results of the modeling processes are called ontologies – a terminology that also helps to avoid confusion since the term “model” is often used in a rather different sense in knowledge representation.
Now, in order to formulate knowledge explicitly, it is useful to assume that it consists of elementary pieces that are often referred to as statements or propositions. Statements like “it is raining” or “every man is mortal” are typical examples for such basic propositions. Indeed, every OWL 2 ontology is essentially just a collection of such basic “pieces of knowledge.” Statements that are made in an ontology are called axioms in OWL 2, and the ontology asserts that its axioms are true. In general, OWL statements might be either true or false given a certain state of affairs. This distinguishes them from entities and expressions as described further below.
There are OWL tools – reasoners – that can automatically compute consequences. The way ontological axioms interact can be very subtle and difficult for people to understand. This is both a strength and a weakness of OWL 2. It is a strength because OWL 2 tools can discover information that a person would not have spotted. This allows knowledge engineers to model more directly and the system to provide useful feedback and critique of the modeling. It is a weakness because it is comparatively difficult for humans to immediately foresee the actual effect of various constructs in various combinations. Tool support ameliorates the situation but successful knowledge engineering often still requires some amount of training and experience.
Having a closer look at statements in OWL, we see that they are rarely “monolithic” but more often have some internal structure that can be explicitly represented. They normally refer to objects of the world and describe them e.g. by putting them into categories (like “Mary is female”) or saying something about their relation (“John and Mary are married”). All atomic constituents of statements, be they objects (John, Mary), categories (female) or relations (married) are called entities. In OWL 2, we denote objects as individuals, categories as classes and relations as properties. Properties in OWL 2 are further subdivided. Object properties relate objects to objects (like a person to their spouse), while datatype properties assign data values to objects (like an age to a person). Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead of the domain of interest.
4. Classes, Properties, and Individuals – And Basic Modeling With Them
4.1. Classes and Instances
We start by introducing the persons we are talking about. This can be done as follows:
:Mary rdf:type :Person .This statement talks about an individual named Mary and states that this individual is a person. More technically, being a person is expressed by stating that Mary belongs to (or “is a member of” or, even more technically, “is an instance of”) the class of all persons. In general classes are used to group individuals that have something in common in order to refer to them. Hence, classes essentially represent sets of individuals.In modeling, classes are often used to denote the set of objects comprised by a concept of human thinking, like the concept person or the concept woman. Consequently, we can use the same type of statement to indicate that Mary is a woman by expressing that she is an instance of the class of women:
:Mary rdf:type :Woman .4.2. Class Hierarchies
In the previous section, we were talking about two classes: the class of all persons and that of all women. To the human reader it is clear that these two classes are in a special relationship: Person is more general than Woman, meaning that whenever we know some individual to be a woman, that individual must be a person. However, this correspondence cannot be derived from the labels “Person” and “Woman” but is part of the human background knowledge about the world and our usage of those terms. Therefore, in order to enable a system to draw the desired conclusions, it has to be informed about this correspondence. In OWL 2, this is done by a so-called subclass axiom:
:Woman rdfs:subClassOf :Person .The presence of this axiom in an ontology enables reasoners to infer for every individual which is specified as an instance of the class Woman, that it is an instance of the class Person as well. As a rule of thumb, a subclass relationship between two classes A and B can be specified, if the phrase “every A is a B” makes sense and is correct.
It is common in ontological modeling to use subclass statements not only for sporadically declaring such interdependencies, but to model whole class hierarchies by specifying the generalization relationships of all classes in the domain of interest. Suppose we also want to state that all mothers are women:
:Mother rdfs:subClassOf :Woman .Then a reasoner could not only derive for every single individual that is classified as mother, that it is also a woman (and consequently a person), but also that Mother must be a subclass of Person – coinciding with our intuition. Technically, this means that the subclass relationship between classes is transitive. Besides this, it is also reflexive, meaning that every class is its own subclass – this is intuitive as well since clearly, every person is a person etc.
Classes in our vocabulary may effectively refer to the same sets, and OWL provides a mechanism by which they are considered to be semantically equivalent. For example, we use the term Person and Human interchangeably, meaning that every instance of the class Person is also an instance of class Human, and vice versa. Two classes are considered equivalent if they contain exactly the same individuals. The following example states that the class Person is equivalent to the class Human.
:Person owl:equivalentClass :Human .Stating that Person and Human are equivalent amounts exactly to the same as stating that both Person is a subclass of Human and Human is a subclass of Person.
4.3. Class Disjointness
In Section 4.1, we stated that an individual can be an instance of several classes. However, in some cases membership in one class specifically excludes membership in another. For example, if we consider the classes Man and Woman, we know that no individual can be an instance of both classes (for the sake of the example, we disregard biological borderline cases). This “incompatibility relationship” between classes is referred to as (class) disjointness. Again, the information that two classes are disjoint is part of our background knowledge and has to be explicitly stated for a reasoning system to make use of it. This is done as follows:
[] rdf:type owl:AllDisjointClasses ;
owl:members ( :Woman :Man ) . In practice, disjointness statements are often forgotten or neglected. The arguable reason for this could be that intuitively, classes are considered disjoint unless there is other evidence. By omitting disjointness statements, many potentially useful consequences can get lost. Note that in our example, the disjointness axiom is needed to deduce that Mary is not a man. Moreover, given the above axioms, a reasoner can infer the disjointness of the classes Mother and Man.
4.4. Object Properties
In the preceding sections we were concerned with describing single individuals, their class memberships, and how classes can relate to each other based on their instances. But more often than not, an ontology is also meant to specify how the individuals relate to other individuals. These relationships are central when describing a family. We start by indicating that Mary is John's wife.
:John :hasWife :Mary .Hereby, the entities describing in which way the individuals are related – like hasWife in our case, are called properties.
Note that the order in which the individuals are written is important. While “Mary is John's wife” might be true, “John is Mary's wife” certainly isn't. Indeed, this is a common source of modeling errors that can be avoided by using property names which allow only one unique intuitive reading. In case of nouns (like “wife”), such unambiguous names might be constructions with “of” or with “has” (wifeOf or hasWife). For verbs (like “to love”) an inflected form (loves) or a passive version with “by” (lovedBy) would prevent unintended readings.
We can also state that two individuals are not connected by a property. The following, for example, states that Mary is not Bill's wife.
[] rdf:type owl:NegativePropertyAssertion ;
owl:sourceIndividual :Bill ;
owl:assertionProperty :hasWife ;
owl:targetIndividual :Mary .Negative property assertions provide a unique opportunity to make statements where we know something that is not true. This kind of information is particularly important in OWL where the default stance is that anything is possible until you say otherwise.
4.5. Property Hierarchies
In Section 4.2 we argued that it is useful to specify that one class membership implies another one. Essentially the same situation can occur for properties: whenever B is known to be A's wife, it is also known to be A's spouse (note, that this is not true the other way round). OWL allows to specify this statement as follows:
:hasWife rdfs:subPropertyOf :hasSpouse .There is also a syntactic shortcut for property equivalence, which is similar to class equivalence.
4.6. Domain and Range Restrictions
Frequently, the information that two individuals are interconnected by a certain property allows to draw further conclusions about the individuals themselves. In particular, one might infer class memberships. For instance, the statement that B is the wife of A obviously implies that B is a woman while A is a man. So in a way, the statement that two individuals are related via a certain property carries implicit additional information about these individuals. In our example, this additional information can be expressed via class memberships. OWL provides a way to state this correspondence:
:hasWife rdfs:domain :Man ;
rdfs:range :Woman .Having these two axioms in place and given e.g. the information that Sasha is related to Hillary via the property hasWife, a reasoner would be able to infer that Sasha is a man and Hillary a woman.
4.7. Equality and Inequality of Individuals
Note that from the information given so far, it can be deduced that John and Mary are not the same individual as they are known to be instances of the disjoint classes Man and Woman, respectively. However, if we add information about another family member, say Bill, and indicate that he is a man, then there is nothing said so far that implies that John and Bill are not the same. OWL does not make the assumption that different names are names for different individuals. (This lack of a required “unique names assumption” is particularly well-suited to Semantic Web applications where names may be coined by different organizations at different times unknowingly referring to the same individual.) Hence, if we want to exclude the option of John and Bill being the same individual, this has to be explicitly specified as follows:
:John owl:differentFrom :Bill .It is also possible to state that two names refer to (denote) the same individual. For example, we can say that James and Jim are the same individual.
:James owl:sameAs :Jim.This would enable a reasoner to infer that any information given about the individual James also holds for the individual Jim.
4.8. Datatypes
So far, we have seen how we can describe individuals via class memberships and via their relationships to other individuals. In many cases, however, individuals are to be described by data values. Think of a person's birth date, his age, his email address etc. For this purpose, OWL provides another kind of properties, so-called Datatype properties. These properties relate individuals to data values (instead of to other individuals), and many of the XML Schema datatypes [XML Schema Datatypes] can be used. The following is an example using a datatype property. It states that John's age is 51.
:John :hasAge 51 .Likewise, we can state that Jack's age is not 53.
[] rdf:type owl:NegativePropertyAssertion ;
owl:sourceIndividual :Jack ;
owl:assertionProperty :hasAge ;
owl:targetValue 53 .Domain and range can also be stated for datatype properties as it is done for object properties. In that case, however, the range will be a datatype instead of a class. The following states that the hasAge property is only used to relate persons with non-negative integers.
:hasAge rdfs:domain :Person ;
rdfs:range xsd:nonNegativeInteger .We would like to point out at this stage a common mistake which easily occurs when using property domains and ranges. In the example just given, which states that the hasAge property is only used to relate persons with non-negative integers, assume that we also specify the information that Felix is in the class Cat and that Felix hasAge 9. From the combined information, it would then be possible to deduce that Felix is also in the class Person, which is probably not intended. This is a commonly modeling error: note that a domain (or range) statement is not a constraint on the knowledge, but allows a reasoner to infer further knowledge. If we state – as in our example – that an age is only given for persons, then everything we give an age for automatically becomes a person.
5. Advanced Class Relationships
In the previous sections we have dealt with classes as something “opaque” carrying a name. We used them to characterize individuals, and related them to other classes via subclass or disjointness statements.
We will now demonstrate how named classes, properties, and individuals can be used as building blocks to define new classes.
5.1 Complex Classes
By means of the language elements described so far, simple ontologies can be modeled. In order to express more complex knowledge, OWL provides logical class constructors. In particular, OWL provides language elements for logical and, or, and not. The corresponding OWL terms are borrowed from set theory: (class) intersection, union and complement. These constructors combine atomic classes – i.e. classes with names – to complex classes.
The intersection of two classes consists of exactly those individuals which are instances of both classes. The following example states that the class Mother consists of exactly those objects which are instances of both Woman and Parent:
:Mother owl:equivalentClass [
rdf:type owl:Class ;
owl:intersectionOf ( :Woman :Parent )
] .An example for an inference which can be drawn from this is that all instances of the class Mother are also in the class Parent.
The union of two classes contains every individual which is contained in at least one of these classes. Therefore we could characterize the class of all parents as the union of the classes Mother and Father:
:Parent owl:equivalentClass [
rdf:type owl:Class ;
owl:unionOf ( :Mother :Father )
] .The complement of a class corresponds to logical negation: it consists of exactly those objects which are not members of the class itself. The following definition of childless persons uses the class complement and also demonstrates that class constructors can be nested:
:ChildlessPerson owl:equivalentClass [
rdf:type owl:Class ;
owl:intersectionOf ( :Person
[ rdf:type owl:Class ;
owl:complementOf :Parent ] )
] .All the above examples demonstrate the usage of class constructors in order to define new classes as combination of others. But, of course, it is also possible to use class constructors together with a subclass statement in order to indicate necessary, but not sufficient, conditions（必要不充分） for a class. The following statement indicates that every Grandfather is both a man and a parent (whereas the converse is not necessarily true):
:Grandfather rdfs:subClassOf [
rdf:type owl:Class ;
owl:intersectionOf ( :Man :Parent )
] .In general, complex classes can be used in every place where named classes can occur, hence also in class assertions. This is demonstrated by the following example which asserts that Jack is a person but not a parent.
:Jack rdf:type [
rdf:type owl:Class ;
owl:intersectionOf ( :Person
[ rdf:type owl:Class ;
owl:complementOf :Parent ]
)
] .5.2 Property Restrictions
Property restrictions provide another type of logic-based constructors for complex classes. As the name suggests, property restrictions use constructors involving properties.
One property restriction called existential quantification defines a class as the set of all individuals that are connected via a particular property to another individual which is an instance of a certain class. This is best explained by an example, like the following which defines the class of parents as the class of individuals that are linked to a person by the hasChild property.
:Parent owl:equivalentClass [
rdf:type owl:Restriction ;
owl:onProperty :hasChild ;
owl:someValuesFrom :Person
] .This means that there is an expectation that for every instance of Parent, there exists at least one child, and that child is a member of the class Person. This is useful to capture incomplete knowledge. For example, Sally tells us that Bob is a parent, and therefore we can infer that he has at least one child even if we don't know their name. Natural language indicators for the usage of existential quantification are words like “some,” or “one.”
Another property restriction, called universal quantification is used to describe a class of individuals for which all related individuals must be instances of a given class. We can use the following statement to indicate that somebody is a happy person exactly if all their children are happy persons.
:HappyPerson rdf:type owl:Class ;
owl:equivalentClass [
rdf:type owl:Restriction ;
owl:onProperty :hasChild ;
owl:allValuesFrom :Happy
] .5.3 Property Cardinality Restrictions
Using universal quantification, we can say something about all of somebody's children, whereas existential quantification allows us to refer to (at least) one of them. However, we might want to specify the number of individuals involved in the restriction. Indeed, we can construct classes depending on the number of children. The following example states that John has at most four children who are themselves parents:
:John rdf:type [
rdf:type owl:Restriction ;
owl:maxQualifiedCardinality "4"^^xsd:nonNegativeInteger ;
owl:onProperty :hasChild ;
owl:onClass :Parent
] .Note that this statement allows John to have arbitrarily many further children who are not parents.
Likewise, it is also possible to declare a minimum number by saying that John is an instance of the class of individuals having at least two children who are parents:
:John rdf:type [
rdf:type owl:Restriction ;
owl:minQualifiedCardinality "2"^^xsd:nonNegativeInteger ;
owl:onProperty :hasChild ;
owl:onClass :Parent
] .If we happen to know the exact number of John's children who are parents, this can be specified as follows:
:John rdf:type [
rdf:type owl:Restriction ;
owl:qualifiedCardinality "3"^^xsd:nonNegativeInteger ;
owl:onProperty :hasChild ;
owl:onClass :Parent
] .In a cardinality restriction, providing the class is optional; if we just want to talk about the number of all of John's children we can write the following:
:John rdf:type [
rdf:type owl:Restriction ;
owl:cardinality "5"^^xsd:nonNegativeInteger ;
owl:onProperty :hasChild
] .5.4 Enumeration of Individuals
A very straightforward way to describe a class is just to enumerate all its instances. OWL provides this possibility, e.g. we can create a class of birthday guests:
:MyBirthdayGuests owl:equivalentClass [
rdf:type owl:Class ;
owl:oneOf ( :Bill :John :Mary )
] .Note that this axiom provides more information than simply asserting class membership of Bill, John, and Mary as described in Section 4.1. In addition to that, it also stipulates that Bill, John, and Mary are the only members of MyBirthdayGuests. Therefore, classes defined this way are sometimes referred to as closed classes or enumerated sets. If we now assert Jeff as an instance of MyBirthdayGuests, the consequence is that Jeff must be equal to one of the above three persons.
6. Advanced Use of Properties
Until now we focused on classes and properties that were merely used as building blocks for class expressions. In the following, we will see what other modeling capabilities with properties OWL 2 offers.
6.1. Property Characteristics
Sometimes one property can be obtained by taking another property and changing its direction, i.e. inverting it. For example, the property hasParent can be defined as the inverse property of hasChild:
:hasParent owl:inverseOf :hasChild .This would for example allow to deduce for arbitrary individuals A and B, where A is linked to B by the hasChild property, that B and A are also interlinked by the hasParent property. However, we do not need to explicitly assign a name to the inverse of a property if we just want to use it, say, inside a class expression. Instead of using the new hasParent property for the definition of the class Orphan, we can directly refer to it as the hasChild-inverse:
:Orphan owl:equivalentClass [
rdf:type owl:Restriction ;
owl:onProperty [ owl:inverseOf :hasChild ] ;
owl:allValuesFrom :Dead
] .In some cases, a property and its inverse coincide, or in other words, the direction of a property doesn't matter. For instance the property hasSpouse relates A with B exactly if it relates B with A. For obvious reasons, a property with this characteristic is called symmetric, and it can be specified as follows
:hasSpouse rdf:type owl:SymmetricProperty .On the other hand, a property can also be asymmetric meaning that if it connects A with B it never connects B with A. Clearly, this is the case for the property hasChild and is expressed like this:
:hasChild rdf:type owl:AsymmetricProperty .Previously, we considered subproperties in analogy to subclasses. It turns out that it also make sense to transfer the notion of class disjointness to properties: two properties are disjoint if there are no two individuals that are interlinked by both properties. Following common law, we can thus state that parent-child marriages cannot occur:
:hasParent owl:propertyDisjointWith :hasSpouse .Properties can also be reflexive: such a property relates everything to itself. For the following example, note that everybody has himself as a relative.
:hasRelative rdf:type owl:ReflexiveProperty .Properties can furthermore be irreflexive, meaning that no individual can be related to itself by such a role. A typical example is the following which simply states that nobody can be his own parent.
:parentOf rdf:type owl:IrreflexiveProperty .Next, consider the hasHusband property. As every person can have only one husband (which we take for granted for the sake of the example), every individual can be linked by the hasHusband property to at most one other individual. This kind of properties are called functional and are described as follows:
:hasHusband rdf:type owl:FunctionalProperty .Note that this statement does not require every individual to have a husband, it just states that there can be no more than one. Moreover, if we additionally had a statement that Mary's husband is James and another that Mary's husband is Jim, it could be inferred that Jim and James must refer to the same individual.
It is also possible to indicate that the inverse of a given property is functional:
:hasHusband rdf:type owl:InverseFunctionalProperty .This indicates that an individual can be husband of at most one other individual.
Now have a look at a property hasAncestor which is meant to link individuals A and B whenever A is a direct descendant of B. Clearly, the property hasParent is a “special case” of hasAncestor and can be defined as a subproperty thereof. Still, it would be nice to "automatically" include parents of parents (and parents of parents of parents). This can be done by defining hasAncestor as transitive property. A transitive property interlinks two individuals A and C whenever it interlinks A with B and B with C for some individual B.
:hasAncestor rdf:type owl:TransitiveProperty .7. Advanced Use of Datatypes
In Section 4.8, we learned that individuals can be endowed with numerical information, essentially by connecting them to a data value via a datatype property – just like object properties link to other domain individuals. In fact, these parallels extend to the more advanced features of datatype usage.
First of all, data values are grouped into datatypes and we have seen in Section 4.8 how a range restriction on a datatype property can be used to indicate the kind of values this property can link to. Moreover, it is possible to express and define new datatypes by constraining or combining existing ones. Datatypes can be restricted via so-called facets, borrowed from XML Schema Datatypes [XML Schema Datatypes]. In the following example, we define a new datatype for a person's age by constraining the datatype integer to values between (inclusively) 0 and 150.
:personAge owl:equivalentClass
[ rdf:type rdfs:Datatype;
owl:onDatatype xsd:integer;
owl:withRestrictions (
[ xsd:minInclusive "0"^^xsd:integer ]
[ xsd:maxInclusive "150"^^xsd:integer ]
)
] .
Likewise, datatypes can be combined just like classes by complement, intersection and union. Thereby, assuming we have already defined a datatype minorAge, we can define the datatype majorAge by excluding all data values of minorAge from personAge:
:majorAge owl:equivalentClass
[ rdf:type rdfs:Datatype;
owl:intersectionOf (
:personAge
[ rdf:type rdfs:Datatype;
owl:datatypeComplementOf :minorAge ]
)
] .Moreover, a new datatype can be generated by just enumerating the data values it contains.
:toddlerAge owl:equivalentClass
[ rdf:type rdfs:Datatype;
owl:oneOf ( "1"^^xsd:integer "2"^^xsd:integer )
] .In Section 6.1, we saw ways of characterizing object properties. Some of those are also available for datatype properties. For example, we can express that every person has only one age by characterizing the hasAge datatype property as functional:
:hasAge rdf:type owl:FunctionalProperty .New classes can be defined by restrictions on datatype properties. The following example defines the class teenager as all individuals whose age is between 13 and 19 years.
:Teenager rdfs:subClassOf
[ rdf:type owl:Restriction ;
owl:onProperty :hasAge ;
owl:someValuesFrom
[ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minExclusive "12"^^xsd:integer ]
[ xsd:maxInclusive "19"^^xsd:integer ]
)
]
] .
参考：
OWL 2 Web Ontology Language Primer (Second Edition)： https://www.w3.org/TR/2012/REC-owl2-primer-20121211/