创建一个模型，并用StmtInterator循环取出Statement

// some definitions

String personURI    = "http://somewhere/JohnSmith";

String givenName    = "John";

String familyName   = "Smith";

String fullName     = givenName + " " + familyName;

// create an empty Model

Model model = ModelFactory.createDefaultModel();

// create the resource

//   and add the properties cascading style

Resource johnSmith

  = model.createResource(personURI)

         .addProperty(VCARD.FN, fullName)

         .addProperty(VCARD.N,

                      model.createResource()

                           .addProperty(VCARD.Given, givenName)

                           .addProperty(VCARD.Family, familyName));

// list the statements in the Model

StmtIterator iter = model.listStatements();

// print out the predicate, subject and object of each statement

while (iter.hasNext()) {

    Statement stmt      = iter.nextStatement();  // get next statement

    Resource  subject   = stmt.getSubject();     // get the subject

    Property  predicate = stmt.getPredicate();   // get the predicate

    RDFNode   object    = stmt.getObject();      // get the object

    System.out.print(subject.toString());

    System.out.print(" " + predicate.toString() + " ");

    if (object instanceof Resource) {

       System.out.print(object.toString());

    } else {

        // object is a literal

        System.out.print(" \"" + object.toString() + "\"");

    }

    System.out.println(" .");

}

2.Writing RDF

// now write the model in XML form to a file

model.write(System.out);

The output should look something like this:

<rdf:RDF

  xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'

  xmlns:vcard='http://www.w3.org/2001/vcard-rdf/3.0#'>

  <rdf:Description rdf:about='http://somewhere/JohnSmith'>

    <vcard:FN>John Smith</vcard:FN>

    <vcard:N rdf:nodeID="A0"/>

  </rdf:Description>

  <rdf:Description rdf:nodeID="A0">

    <vcard:Given>John</vcard:Given>

    <vcard:Family>Smith</vcard:Family>

  </rdf:Description>

</rdf:RDF>

以更紧凑的方法书写RDF模型，保留空节点，但不适合大型的模型输出

// now write the model in XML form to a file

model.write(System.out, "RDF/XML-ABBREV");

To write large files and preserve blank nodes, write in N-Triples format:

// now write the model in XML form to a file

model.write(System.out, "N-TRIPLE");

3. Reading RDF

package jena.rdf.example;

import com.hp.hpl.jena.rdf.model.*;

import com.hp.hpl.jena.util.FileManager;

import java.io.*;

public class Tutorial05{

 static String fileName = D:/../data/camera.owl";

 public static void main(String[] args){

  Model model = ModelFactory.createDefaultModel();

  InputStream in = FileManager.get().open(fileName);

if(in == null){

   throw new IllegalArgumentException("File "+fileName+" Not Found!!"); 

}else{

 model.read(new InputStreamReader(in),"");

   model.write(System.out,"RDF/XML-ABBREV");

  }

 }

}

4. Controlling Prefixes

4.1explicit prefix definitions

Model m = ModelFactory.createDefaultModel();

 String nsA = "http://somewhere/else#";

 String nsB = "http://nowhere/else#";

 Resource root = m.createResource( nsA + "root" );

 Property P = m.createProperty( nsA + "P" );

 Property Q = m.createProperty( nsB + "Q" );

 Resource x = m.createResource( nsA + "x" );

 Resource y = m.createResource( nsA + "y" );

 Resource z = m.createResource( nsA + "z" );

 m.add( root, P, x ).add( root, P, y ).add( y, Q, z );

 System.out.println( "# -- no special prefixes defined" );

 m.write( System.out );

 System.out.println( "# -- nsA defined" );

 m.setNsPrefix( "nsA", nsA );

 m.write( System.out );

 System.out.println( "# -- nsA and cat defined" );

 m.setNsPrefix( "cat", nsB );

 m.write( System.out );

# -- no special prefixes defined

<rdf:RDF

    xmlns:j.0="http://nowhere/else#"

    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

    xmlns:j.1="http://somewhere/else#" >

  <rdf:Description rdf:about="http://somewhere/else#root">

    <j.1:P rdf:resource="http://somewhere/else#x"/>

    <j.1:P rdf:resource="http://somewhere/else#y"/>

  </rdf:Description>

  <rdf:Description rdf:about="http://somewhere/else#y">

    <j.0:Q rdf:resource="http://somewhere/else#z"/>

  </rdf:Description>

</rdf:RDF>

没有引进名称空间，Jena就用默认的方式对名称空间命名j.0 and j.1.

可以用方法setNsPrefix(String prefix, String URI)引进名称空间

4.2 implicit prefix definitions（？？？？？）

As well as prefix declarations provided by calls to setNsPrefix, Jena will remember the prefixes that were used in input to model.read(). 

Take the output produced by the previous fragment, and paste it into some file, with URL file:/tmp/fragment.rdf say. Then run the code: 

Model m2 = ModelFactory.createDefaultModel();

m2.read( "file:/tmp/fragment.rdf" );

m2.write( System.out );

You'll see that the prefixes from the input are preserved in the output. All the prefixes are written, even if they're not used anywhere. You can remove a prefix with removeNsPrefix(String prefix) if you don't want it in the output. 

Since NTriples doesn't have any short way of writing URIs, it takes no notice of prefixes on output and doesn't provide any on input. The notation N3, also supported by Jena, does have short prefixed names, and records them on input and uses them on output. 

Jena has further operations on the prefix mappings that a model holds, such as extracting a Java Map of the exiting mappings, or adding a whole group of mappings at once; see the documentation for PrefixMapping for details. 

5. Jena RDF 包

Jena 是一个为语义网应用设计的一个Java API. 对应用开发者而言, 主要可用的RDF 包是com.hp.hpl.je

na.rdf.model. 因为API 是以接口的方式定义的, 所以应用代码可以使用不同的实现机制而不用改变代码

本身. 这个包包含了可以表示模型, 资源, 属性, 文本, 陈述和其他RDF 关键概念的接口, 还有一个用来

创建模型的ModelFactory. 所以如果要应用代码与实现类保持独立, 最好尽可能地使用接口, 而不要使用

特定的实现类.

com.hp.hpl.jena.impl 这些包包含了许多执行时所常用的执行类. 比如, 它们定义了诸如ResourseImp

l, PropertyImpl 和LiteralImpl 的类, 这些类可以被不同的应用直接使用也可以被继承使用. 应用程序

应该尽可能少地直接使用这些类. 例如, 与其使用ResouceImpl 来创建一个新的实例, 更好的办法是使用

任何正在使用的模型的createResource 方法来完成. 那样的话, 如果模型的执行采用了一个优化的Resou

ce 执行, 那么在这两种类型中不需要有任何的转换工作.

人们所说的接口往往指的是两种不同的东西：一种是JAVA中有严格定义的Interface结构，比如java.lang.Runnable就是一个java接口；另一种就是一个类型所具有的方法特征的集合，也称作“接口”，但这仅是一种逻辑上的抽象。

一个接口相当于剧本中的一个角色，而此角色有哪个演员来扮演相当于接口的实现。因此，一个接口应当简单地代表一个角色，而不是多个角色。如果系统涉及到多个角色的话，那么每一个角色都应该由一个特定的接口代表。

  如果将接口理解成狭义的java 接口，这样一来，ISP讲的就是为同一个角色提供宽窄不一的接口，以对付不同的客户端。这种办法在服务行业中叫做定制服务。也就是说我们只提供给客户端需要的方法。一个设计师往往想节省接口的数目而讲看上去类似的接口合并，实际上这是一种错误的做法，提供给客户多余的方法，使接口变得臃肿，造成接口污染。

   定制化服务设计原则的好处在于：这样作很整洁；有利于系统的维护，向客户端提供public接口是一种承诺，我们应尽量减少这种承诺。将接口隔离出来，有利于降低成本。

传统的过程化设计的设计方法倾向于使高层的模块依赖于低层次的模块，抽象层次依赖于具体层次。倒转原则就是要把这个错误的依赖关系倒转过来，这就是倒转依赖原则的由来。

   在面向对象的系统中，两个类之间通常是三种依赖关系：

1.       零耦合：两个类之间没有耦合关系

2.       具体耦合：具体耦合关系发生在两个具体的类之间，经由一个类引用另一个类造成

3.       抽象耦合：抽象耦合发生在一个具体类和一个抽象之间 或者JAVA接口之间，使两个必须发生关系的类之间存在最大的灵活性。

通常我们对DIP的表述为：抽象不应当依赖于细节；细节应当依赖于抽象。另一种表述为：针对接口编程，不要针对实现编程。也就是说我们应当使用JAVA接口和抽象JAVA类进行变量的类型声明、方法的返回类型说明，以及数据类型的转换等。要保证做到这一点，一个具体的JAVA类应当只实现JAVA接口和抽象JAVA类中声明过的方法，而不应当给出多余的方法。

   引用对象的抽象类型：在很多情况下，一个java程序需要引用一个对象，这个时候，如果这个对象有一个抽象类型的话，应当使用这个抽象类型作为变量的静态类型，这个就是针对接口编程的含义。比如说，蛋代表抽象，鸡代表具体，那么鸡应依赖于蛋，而蛋不应当依赖于鸡，假设蛋使java接口或者java抽象类，鸡是一个具体类，X是一个变量，那么声明变量应该是：蛋 X ＝ new 鸡（），而不应当是 鸡 X  ＝ new 鸡（）

只要一个被引用的对象存在抽象类型，就应当在任何引用此对象的地方使用抽象类型，包括参量的类型声明、方法的返回类型的声明、属性变量的类型声明等。

   联合使用JAVA接口和JAVA抽象类：由于抽象类具有提供缺省实现的优点，而接口具有其他的优点，所以联合使用两者是很好的选择。首先，声明类型的工作是由接口承担，但是同时给出的还有一个抽象类，为这个接口提供一个缺省实现。其他同属于这个抽象类型的具体类可以选择实现这个接口，也可以选择继承自这个抽象类。如果需要向接口加入一个方法的话，只要同时向这个抽象类加入这个方法的具体实现就可以了，因为继承自这个抽象类的子类都会从这个抽象类得到这个具体方法。

   DIP虽然很强大，但是不容易实现，应为依赖关系倒转的缘故，对象的创建可能会使用对象工厂，以避免对具体类的使用。此外，DIP假定所有的具体类都是会变化的，这也不总是正确的，如果一个具体类是稳定的、不会发生变化的，那么使用这个具体类的客户端完全可以依赖于这个具体类型。

也就是说，一个软件实体如果使用的是一个基类的话，那么就一定适用其子类，而且他根本不能察觉出子类跟基类的区别。但是反过来不成里：如果有b是基类对象，而d是子类对象的话，对于方法method(d)，method(b)就不一定成立了。

对于运用LSP具体是实例有：

正方形不是长方形的子类。根据我们的生活常识，可能以为正方形是长方形的子类。但是如果长方形有这样一个方法，reSize()

Public void resize(Rectangle r)

{

Whiel(r.getHeigth >=  r.getWidth)

{

  r.setWidth(r.getWidth+1);

}

}

对于正方形就不适用了，因为Height一改变，Width也就会改变，知道溢出为止。

而不变正方形是长方形的子类，因为不变正方形没有setSize 的方法。看到这里有点疑问，基类有的方法子类并一定有，这样不违反LSP吗？

对于违反LSP的结构要进行代码重构，如果A继承自B，但是违反了LSP，一般的做法是构造一个抽象类或接口，使之拥有A和B的公共方法，然后让A和B分别继承之。在正方形不是长方形的子类的问题中，我们可以通过定义一个四边形接口，该接口拥有方法getWidth和getHeight，但不拥有赋值的方法，这样就避免了reSize()的方法对于正方形的影响。然后让正方形和长方形继承这个接口。

JAVA在编译的时候会使用LSP去检查一个程序是否符合LSP原则。

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

                xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

                xml:base="http://www.geodesy.org/water/naturally-occurring">

    <rdfs:Class rdf:ID="River">

        <rdfs:subClassOf rdf:resource="#Stream"/>

    </rdfs:Class>

    <rdfs:Class rdf:ID="Stream">

        <rdfs:subClassOf rdf:resource="#NaturallyOccurringWaterSource"/>

    </rdfs:Class>

    <rdf:Property rdf:ID="emptiesInto">

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:range rdf:resource="#BodyOfWater"/>

    </rdf:Property>

    <rdf:Property rdf:ID="length">

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>

    </rdf:Property>

    ...

</rdf:RDF>

文字值

 <rdf:Property rdf:ID="length">

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>

</rdf:Property>

在NaturallyOccurringWaterSource.rdfs中我们定义了类，类之间的关系，也定义了类的属性，这样实际上我们创建了一个NaturallyOccurringWaterSource的本体

如何从属性的domain中推理得出资源所属类

<?xml version="1.0"?>

<rdf:Description rdf:ID="Yangtze"

                             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

                             xmlns="http://www.geodesy.org/water/naturally-occurring#">

     <length>6300 kilometers</length>

     <emptiesInto rdf:resource="http://www.china.org/geography#EastChinaSea"/>

</rdf:Description>

显然在上面这段XML中无法显示的得出"Yangtze"的所属类。但根据"Yangtze"的属性length，以及前面在本体中定义的lenth的domain是River，所以可以推断得到"Yangtze"的所属类是River.

合理地设计RDFS文档使之便于推理

<?xml version="1.0"?>

<River rdf:ID="Yangtze"

            xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

            xmlns="http://www.geodesy.org/water/naturally-occurring#">

     <length>6300 kilometers</length>

     <emptiesInto rdf:resource="http://www.china.org/geography#EastChinaSea"/>

</River>

在这个例子中我们可以推理得出emptiesInto 的值是一种BodyOfWater.

<?xml version="1.0"?>

<River rdf:ID="Yangtze"

            xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

            xmlns="http://www.geodesy.org/water/naturally-occurring#">

     <length>6300 kilometers</length>

     <emptiesInto>East China Sea</emptiesInto>

</River>

在这里我们就无法得出以上的推论，只知道emptiesInto的值是文字类型。

1. RDFS的目的是什么？

RDFS的目的在于提供一个XML的词汇表，用于定义类或子类之间的关系以及类和属性之间的关系。这样做的好处在于：提高数据的推理能力和搜索能力。

RDFS主要用于创建某个领域的概念分类。

2.       RDFS可以提供什么样的推理？

举个例子：

推理可以得出：
- Yangtze is a Stream

- Yangtze is an NaturallyOcurringWaterSource

- http://www.china.org/geography#EastChinaSea is a BodyOfWater

3.RDFS如何提高搜索数据的能力

  在上例中我们如果这样提问："Show me all documents that contain info about Streams"

我们将得到这样的答案：

- Yangtze is a Stream, so this document is relevant to the query.

第二部分：RDFS的基本语法

1. rdfs:class

 <rdfs:Class rdf:ID="River">

        <rdfs:subClassOf rdf:resource="#Stream"/>

</rdfs:Class>

用于定义一个类，rdf:ID用于定义一个类的名字

下面这两种定义类的方法是相等的：

<rdfs:Class rdf:ID="River">

        <rdfs:subClassOf rdf:resource="#Stream"/>

</rdfs:Class>和

<rdf:Description rdf:ID="River">

        <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>

        <rdfs:subClassOf rdf:resource="#Stream"/>

</rdf:Description>

2. rdfs:subClassOf

可以有零个/一个/多个rdfs:subClassOf属性

零个rdfs:subClassOf属性隐式地说明了这个类是rdf:Resource的子类

一个rdfs:subClassOf属性说明了这个类是另外一个类的子类

多个rdfs:subClassOf属性说明了这个类是多个类的子类，既是多个类的交集。

比如：

<rdfs:Class rdf:ID="River">

        <rdfs:subClassOf rdf:resource="#Stream"/>

        <rdfs:subClassOf rdf:resource="http://www.containers.org#SedimentContainer"/>

</rdfs:Class>

另外rdfs:subClassOf具有传递依赖

3. rdf:Property

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

                xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

                xml:base="http://www.geodesy.org/water/naturally-occurring">

    <rdf:Property rdf:ID="emptiesInto">

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:range rdf:resource="#BodyOfWater"/>

    </rdf:Property>

    ...

</rdf:RDF>

注意rdfs:domain和rdfs:range的用法：rdfs:domain是值域，rdfs:range是作用域

以下两种表达方法是相等的

<rdf:Property rdf:ID="emptiesInto">

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:range rdf:resource="#BodyOfWater"/>

</rdf:Property>和

<rdf:Description rdf:ID="emptiesInto">

        <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:range rdf:resource="#BodyOfWater"/>

</rdf:Description>

有一点要注意的是：

Class的NS是RDF，而Property的NS是RDFS

4. rdfs:range

表示这个属性可能包含的类型的值。

跟subclassof类似，可以包括零个/一个/多个rdfs:range属性

零个：如果一个属性没有定以rdfs:range说明这个属性的值的类型未确定。

一个：说明这个属性的值的类型唯一

多个：说明这个属性的值的类型有多种。比如：

<rdf:Property rdf:ID="emptiesInto">

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:range rdf:resource="#BodyOfWater"/>

        <rdfs:range rdf:resource="http://www.geodesy.org/coast#CoastalWater"/>

</rdf:Property>

5. rdfs:domain

表示可能使用这个属性的类。

跟rdfs:range类似，不再重复

<rdf:Property rdf:ID="emptiesInto">

        <rdfs:domain rdf:resource="#River"/>

        <rdfs:domain rdf:resource="http://www.containers.org#Vessel"/>

        <rdfs:range rdf:resource="#BodyOfWater"/>

</rdf:Property>

在这里我们要注意，类和属性是分别定义的，而不是象在OO里面那样，定义了类的同时就定义了属性。也就是说在RDFS里面，我们定义了类，然后定义属性，并将属性与类关联起来。这样做的好处是，任何人任何时刻都可以定义类的属性。

<?xml version="1.0"?>

<rdf:RDF

    xmlns:owl="http://www.w3.org/2002/07/owl#"

    xmlns="http://www.owl-ontologies.com/unnamed.owl#"

    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

  xml:base="http://www.owl-ontologies.com/unnamed.owl">

  <owl:Ontology rdf:about=""/>

  <owl:Class rdf:ID="PizzaBase">

    <owl:disjointWith>

      <owl:Class rdf:ID="Pizza"/>

    </owl:disjointWith>

    <owl:disjointWith>

      <owl:Class rdf:ID="PizzaTopping"/>

    </owl:disjointWith>

  </owl:Class>

  <owl:Class rdf:about="#Pizza">

    <owl:disjointWith rdf:resource="#PizzaBase"/>

    <owl:disjointWith>

      <owl:Class rdf:about="#PizzaTopping"/>

    </owl:disjointWith>

  </owl:Class>

  <owl:Class rdf:about="#PizzaTopping">

    <owl:disjointWith rdf:resource="#PizzaBase"/>

    <owl:disjointWith rdf:resource="#Pizza"/>

  </owl:Class>

</rdf:RDF>

同样的结构，为什么有些要用rdf:resource有些又用rdf:about，还有些用rdf:ID？这几个有什么区别呢？

一些网友的观点：

1.

1）rdf:ID和rdf:about的区别： 
rdf:about的值是一个完整URIref，注意也可以是相对URI，（相对于xml:base）;
rdf:ID是对rdf:about的值的缩写，其值是一个“ XML Name”，所以，不能是数字开头，不能有“/”符号等。

例如：rdf:ID="PizzaBase" 等价于rdf:about="(xml:base)+‘#’+‘PizzaBase’ "
这个xml:base的值可以在XML文件头声明，如你例子中的，xml:base="http://www.owl-ontologies.com/unnamed.owl"， 如果没有声明，则其值是RDF文件所放在的位置uri。

2)rdf:resource 和rdf:about

<owl:disjointWith rdf:resource="#PizzaBase"/> 是

<owl:disjointWith >
   <rdf:Description rdf:about="#PizzaBase" />
</owl:disjointWith >
的缩写。这里必须没有对资源="#PizzaBase" 做进一步的说明。所以，rdf:resource只能出现在表示属性的节点中，如这里的owl:disjointWith节点。

而  <owl:disjointWith>
             <owl:Class rdf:about="#PizzaTopping"/>
    </owl:disjointWith>
是等价于：
<owl:disjointWith >
   <rdf:Description rdf:about="#PizzaTopping" >
         <rdf:type rdf:resource="&rdfs;Class" />
   </rdf:Description>
</owl:disjointWith >

这里不能用rdf:resource了，因为声明了#PizzaTopping是一个类。

所以，我们可以看出：
说明了：  <owl:Class rdf:ID="PizzaBase">
以后，后面的都是用：
 <owl:disjointWith rdf:resource="#PizzaBase"/>
了。

2.其实我们可以把rdf:ID看作和rdf:about一样的东西，rdf:ID只是一个缩写而已。所以
  <owl:Class rdf:ID="PizzaBase">

    <owl:disjointWith>

      <owl:Class rdf:ID="Pizza"/>

    </owl:disjointWith>

    <owl:disjointWith>

      <owl:Class rdf:ID="PizzaTopping"/>

    </owl:disjointWith>

  </owl:Class>
中，把所有的rdf:ID="xxx"替换成rdf:about="#xxx"也是可以的，这是我的第一个理解。

第二，为什么这里不能用rdf:resource呢，是因为到目前为止，Pizza类和PizzaTopping类还没有被定义，需要在这里申明它是一个类。如果Pizza类在之前就已经定义了，那么这里也可以用rdf:resource来简写。

3.再补充一个rdf:ID和rdf:about的区别：

rdf:ID是用来定义一个资源，或者说引入一个新的资源名称；
rdf:about除了也可用来定义资源外，还可用来扩展对这个资源的定义(这可以出现在其他本体文件中)。

如果Pizza是用rdf:ID定义的，那么要增加对Pizza的描述，就必须用rdf:about。因为同一个RDF文档中，不能出现两个rdf:ID="Pizza"，否则RDF Parser就会报错。参见：

{{//RDF Primer. Section 3.2 的第4段中间

 However, using rdf:ID provides an additional check when assigning a set of distinct names, since a given value of the rdf:ID attribute can only appear once relative to the same base URI (the catalog document, in this example).

4.Have you looked at the RDF Primer (and specifically, Example 4 in
Section 3.1 and its explanation, which is where this is discussed)?
Basically, rdf:about is for expressing the *subject* of an RDF statement
in RDF/XML.  rdf:resource is for expressing the *object* of an RDF
statement in RDF/XML, when the object is another resource rather than a
literal value.  Does that help?  If you have some particular example in
mind that you are trying to express, could you provide it?

--Frank

按照Frank的说法，rdf:about用来表示statement的主体，rdf:resource在statement的客体是一个资源而不是文字值时用来表示客体

5.在RDF primer的第三章有解释：http://www.w3.org/TR/rdf-primer/
其中的对rdf:ID的解释：
An important difference from previous examples is that, in line 5, the rdf:Description element has an rdf:ID attribute instead of an rdf:about attribute. Using rdf:ID specifies a fragment identifier, given by the value of the rdf:ID attribute (item10245 in this case, which might be the catalog number assigned by example.com), as an abbreviation of the complete URIref of the resource being described. The fragment identifier item10245 will be interpreted relative to a base URI, in this case, the URI of the containing catalog document. The full URIref for the tent is formed by taking the base URI (of the catalog), and appending the character "#" (to indicate that what follows is a fragment identifier) and then item10245 to it, giving the absolute URIref http://www.example.com/2002/04/products#item10245.

抽象类提供一个类型的部分实现，可以有实例变量，构造方法，抽象方法和具体方法。一个抽象类不会有实例。抽象类跟具体类是蛋跟鸡的关系：蛋决定了鸡的性状，鸡是蛋的具体实现。

2.抽象类的用途

抽象类通常代表一个抽象概念，可以用一句话来概括抽象类的用途：抽象类是用来继承的。反过来可以说具体类不是用来继承的，只要有可能，我们不要从具体类继承。

3.抽象类设计使用的原则

在设计抽象类时我们应注意这几条原则：

1）抽象类应尽可能多地拥有具体类公共的代码，这样做可以提高代码的重用性。我们应针对抽象编程，也就是说我们应该把注意力放在“蛋”上。

2）抽象类应尽可能少地拥有数据，数据应尽量放在具体类中。

4.什么时候才应该使用继承复用

继承代表“一般化/特殊化”关系，其中基类代表一般，而衍生类代表特殊，衍生类将基类特殊化或扩展化。只有当以下的Code条件满足时才应当使用继承关系

1）子类是超类的一个特殊种类，而不是超类的一个角色，也就是应当区别IS－A和Has-A。

2）永远不会出现需要将子类换成另一个类的子类的情况，如果不能肯定一个类在将来会不会成为另一个类的子类，就不要把这个类设计成当前超类的子类

3）子类的责任是扩展超类，而不是Override和Nullify超类。如果子类需要大量地置换超类的行为，就说明子类跟超类的行为差别很大，不存在继承关系。

4）只有在分类学上角度看有意义时，才可以使用继承，不要从工具类继承。举个例子：包装商业规则的类不要去继承数据库管理的类，这样也许会让你很方便地让子类具有数据处理的方法，可是这滥用了继承关系