languages such as Java. However, RDF differs from most programming language type systems in several important respects.

One important difference is that instead of describing a class as having a collection of specific properties, an RDF schema describes

properties as applying to specific classes of resources, using domain and range properties. For example, a typical object-oriented

programming language might define a class Book with an attribute called author having values of type Person. A corresponding RDF

schema would describe a class ex:Book, and, in a separate description, a property ex:author having a domain of ex:Book and a range

of ex:Person.

The difference between these approaches may seem to be only syntactic, but in fact there is an important difference. In the

programming language class description, the attribute author is part of the description of class Book, and applies only to instances of

class Book. Another class (say, softwareModule) might also have an attribute called author, but this would be considered a different

attribute. In other words, the scope of an attribute description in most programming languages is restricted to the class or type in

which it is defined. In RDF, on the other hand, property descriptions are, by default, independent of class definitions, and have, by

default, global scope (although they may optionally be declared to apply only to certain classes using domain specifications).

As a result, an RDF schema could describe a property exterms:weight without a domain being specified. This property could then be

used to describe instances of any class that might be considered to have a weight. One benefit of the RDF property-based approach

is that it becomes easier to extend the use of property definitions to situations that might not have been anticipated in the original

description. At the same time, this is a "benefit" which must be used with care, to insure that properties are not mis-applied in

inappropriate situations.

Another result of the global scope of RDF property descriptions is that it is not possible in an RDF schema to define a specific

property as having locally-different ranges depending on the class of the resource it is applied to. For example, in defining the

property ex:hasParent, it would be desirable to be able to say that if the property is used to describe a resource of class ex:Human,

then the range of the property is also a resource of class ex:Human, while if the property is used to describe a resource of class

ex:Tiger, then the range of the property is also a resource of class ex:Tiger. This kind of definition is not possible in RDF Schema.

Instead, any range defined for an RDF property applies to all uses of the property, and so ranges should be defined with care.

However, while such locally-different ranges cannot be defined in RDF Schema, they can be defined in some of the richer schema

languages discussed in Section 5.5.

Another important difference is that RDF Schema descriptions are not necessarily prescriptive in the way programming language type

declarations typically are. For example, if a programming language declares a class Book with an author attribute having values of type

Person, this is usually interpreted as a group of constraints. The language will not allow the creation of an instance of Book without

an author attribute, and it will not allow an instance of Book with an author attribute that does not have a Person as its value.

Moreover, if author is the only attribute defined for class Book, the language will not allow an instance of Book with some other

attribute.

RDF Schema, on the other hand, provides schema information as additional descriptions of resources, but does not prescribe how

these descriptions should be used by an application. For example, suppose an RDF schema states that an ex:author property has an

rdfs:range of class ex:Person. This is simply an RDF statement that RDF statements containing ex:author properties have instances of

ex:Person as objects.

This schema-supplied information might be used in different ways. One application might interpret this statement as specifying part

of a template for RDF data it is creating, and use it to ensure that any ex:author property has a value of the indicated (ex:Person)

class. That is, this application interprets the schema description as a constraint in the same way that a programming language might.

However, another application might interpret this statement as providing additional information about data it is receiving, information

which may not be provided explicitly in the original data. For example, this second application might receive some RDF data that

includes an ex:author property whose value is a resource of unspecified class, and use this schema-provided statement to conclude

that the resource must be an instance of class ex:Person. A third application might receive some RDF data that includes an ex:author

property whose value is a resource of class ex:Corporation, and use this schema information as the basis of a warning that "there

may be an inconsistency here, but on the other hand there may not be". Somewhere else there may be a declaration that resolves

the apparent inconsistency (e.g., a declaration to the effect that "a Corporation is a (legal) Person").

Moreover, depending on how the application interprets the property descriptions, a description of an instance might be considered

valid either without some of the schema-specified properties (e.g., there might be an instance of ex:Book without an ex:author

property, even if ex:author is described as having a domain of ex:Book), or with additional properties (there might be an instance of

ex:Book with an ex:technicalEditor property, even though the schema describing class ex:Book does not describe such a property).

In other words, statements in an RDF schema are always descriptions. They may also be prescriptive (introduce constraints), but only

if the application interpreting those statements wants to treat them that way. All RDF Schema does is provide a way of stating this

additional information. Whether this information conflicts with explicitly specified instance data is up to the application to determine

and act upon.

我觉得知识的表示和本体是对我们人对世界认识的一种模拟的过程。
我们把世界分为两部分：模型世界和现实世界
模型世界存在于我们的大脑中，本体就相当于这个模型世界，它主要定义了概念和概念之间的关系
现实世界是我们周围客观存在的真实的事物组成的世界，在知识表示中相对于概念的实例，
模型世界和现实世界都应该是变化的，他们相互影响，共同的进化。

知识表示的语言可以有很多种，他们的区别主要在于定义概念和概念之间的关系能力的强弱，当然表示能力和推理能力是一对矛盾，所以在使用的时候要权衡。

比如说使用语义网使用的描述逻辑来进行知识的表示，TBox就相当于模型世界，ABox就相当于现实世界；如果用面向对象语言来表示，Class就是模型世界，Instance就相当于现实世界。

目前来说，本体的构建主要是人手动来完成的，这是一个很复杂的过程。本体创建后还应该有很多的工作，比如说本体进化，还有为了本体能够共享，有Ontology mapping, ontology matching, ontology integration等等

现在看来本体远远不止这么简单。至于本体是什么，我倒真不敢妄言了。

所谓一瓶不响，半瓶光荡，想来就是这个道理了