浏览器请求网格系统中的资源时，首先到某个网格站点要求取得索引信息，网格站点到中心服务器取得更新的索引后，返回给浏览器。

浏览器根据索引文件到各个网格站点取得分布式数据，显示。
当浏览器提交数据时，提交到网格站点，然后网格站点向中心服务器通告数据更新索引信息，以使得中心服务器的索引更新。

系统的特点在于：中心存储维护的数据简单；网格站点轻便，可移植性强；浏览器为RIA。
请关注：http://01235.net/default.asp?cateID=2

分布式和语义，答案似乎已经有了rdf/xml。但是并不能面向用户。rdf/xml很难啃，如何指定将rdf/xml中的数据显示出来，也是难题。对于框架开发本身也有难度，站点上不同平台对rdf/xml的操作有不同的方式，要想统一的话如使用dom、sax，就很底层了。或许可以将xml的解析放到browser上，在javascript中使用dom，这还是底层的操作，而且可能提供的js lib文件比较大，带来传输速度问题。mozilla中正开发E4X，提供xml的javascript bingding，未来可能会在各种浏览器中集成，这是一个值得期待的好消息，但是利用binding 操作xml时，js lib可能也不会很小。总之在通用性，开发难度以及灵活性之间难以兼顾。

另一中选择是rdf/n3，其不是w3c的推荐标准，但是比rdf/xml更受欢迎。进一步抽去n3中的rule，formulate等与数据存贮关系不大的部分，我们可以关注它的子集turtle ：http://www.ilrt.bris.ac.uk/discovery/2004/01/turtle/，turtle是对n3的另一个子集n-triple 的扩展。使用turtle会有两个问题：不像xml那样有节点的概念，因此无法取得文档的某个片断；工具太少。

前一个问题可以通过使用Turtle的一个超集Trig：http://www.wiwiss.fu-berlin.de/suhl/bizer/TriG/#turtle 来解决。它用来表示具名图（named graph）。 和quad（四元组）比较相似，增加的元为graphname，以表示一个表述片断（具名图）。具名图是可以嵌套的，他的每一个资源也是图。graphname和Id间可以建立对应关系，从而实现idrdf。

后一个问题可以通过将Trig转化为json来解决 ，实际上Trig和json的结构很像。转化起来比较简单，除了作为subject 的空节点难以用json表示，但相信也可以解决。而json是很适合于交换数据和处理数据的，这方面几乎超过了xml。对于grider而言他们只需要学习json就够了，这非常简单。

能否直接用json存贮文件？方便，不需要转化了，但是目前还没有看到这方面的例子，而且rdf工具也不能处理json文件。但是不管用json还是Trig存贮数据，只要能提供json<-->Trig转化api，就不是问题，而这很简单。
目前可以考虑提供这样的api，暂命名为json3G
请关注：http://01235.net/default.asp?cateID=2

其实我觉得这些都是小的问题，还有不叫关键的是系统的体系结构等等的设计工作吧

前面我说考虑到rdf/xml比较难啃和比较难以显示，是针对多数一般用户而言，因为框架是给用户使用的。用rdf/xml表示语义方面本身有缺陷，用其书写的文档可读性很差，对用户来讲这是最要命的。至于显示，xsl的确是显示xml一个好方法，也符合系统中显示模板重用的需要。但是xsl显示rdf/xml可能会不适合，而且显得有点多余。因为rdf不像xml，他已经很淡化了节点的概念，而对节点的处理是xsl的长处，其次rdf中是三元组，xpath等工具可能都用不上了。已经有人实现了用xsl显示rdf的工具包，但是我个人觉得对rdf/xml的显示最直接的方法是提取三元组并显示出来。另外一个我重点考虑的还是xsl可读性－比xml数据文件的可读性更差。其实我更倾向与如php中的html模板的方法，所见及所得。当然php中模板是在server端实现的。至于客户端的实现可以参考trimpathwww.trimpath.com
当然xml+xsl是一个可以称为标准的实现方法，我也不能只把我自己认为好的方法强加给用户而舍弃xml+xsl，只是目前我认为使用它可能带来很多麻烦而逐渐使我失去耐心。
目前我可能太专注于一些技术实现，而没有将系统架构讲清楚，希望以后能有互动的沟通，讲得清楚一点。
至于说尽量不用json存贮，请你给我一些理由，它可能对我很有帮助。谢谢

我考虑过使用acess数据库。目前使用一些新的技术，毫无疑问都会碰到很多问题，没有办法边干边学了，谁叫我们对它感兴趣呢。不想使用传统数据库主要从三个方面考虑：1 用户为个人，数据结构比较简单，安全、事务等要求比较低。数据分布式存贮，即每个用户的站点上基本上只存贮本人发布的信息，因此数据量不会很大。所以我觉得数据文件基本上够用了。2 用户所能申请并使用的数据库和网站的语言可能是多种多样的如sqlserver，mysql,php,asp,jsp等，如果使用传统数据库的话，我要都实现，工作量大了。3。传统数据库几乎不适合实现语义，xml数据库可能是一种选择，目前我还没有接触过它。
因为我没有把系统需求、系统架构说清楚，如何实现语义也没有提及，因此可能我和yanqx的理解有较大的分歧，但这不是问题，我们可以共同学习，越辩越明。

@prefix earl: <http://www.w3.org/2001/03/earl/0.95#> .
@prefix p3p: <http://www.w3.org/2000/07/p3pmodel/p3prdfschema#> .
@prefix : <http://myns.org/3/#> .

:G {:Validator  a earl:Tool, earl:Assertor;
   p3p:uri <http://validator.w3.org/html>;
   earl:operator :Sean .
:Sean earl:email <mailto:sean@w3.uk>;
   a earl:Person .
   
   }
   
:G2 {:MyPage  earl:testSubject <http://example.org/page> .
:fails earl:validity earl:Fails;
   earl:date "2001-03-17" .
:ULTest
   earl:test <http://w3.org/html4/testassertion123>;
   earl:testMode earl:Auto;
   earl:purpose "checking html4 dtd content model";
   earl:repairInfo
     [ earl:expectedResult <http://w3.org/tr/html4#ul> ] .
     
     }
以上文件在sever端读取到字符串trigExample中后在browser上可以使用 eval(TrigToJson(trigExample))来获得两个object：prefix(namespaces), graphs，从而获得所有的数据。

版权开放，欢迎转载 copyleft 2003, hax<hax@sjtu.edu.cn>.

========================
术语译名：

RDF model      RDF模型
RDF statement  RDF语句
literal        文字常量
namespace      命名空间

table          表
field          字段
========================

本页概述了当前在关系数据库里存储RDF的几种方法，
*THIS IS A REQUEST FOR COMMENTS*，请将您的想法投稿
到 (www-rdf-interest@w3.org)！

动机（Motiviation）
-------------------

我们需要永久存储和操作（大量的）RDF数据。一个可选的做法是使
用关系数据库技术。这个方法的主要优点是它提供了一个可升级的
通用方案。

准则（Criteria）
----------------

这个不完全的列表指出了数据库模式设计需要考虑的准则（无先后顺序）：

  * 可伸缩性：我们能存储和查询超过十亿(1B+)的triples吗？
  * 查询：支持哪一类的查询？它们可以被容易的公式化表述和处理吗？
  * 效率：查询的耗费多大？交付查询结果的耗费呢？
  * 优化：我们能如何处理refication？
  * 组织：怎样在存储数据之上建立关联？我们能对RDF models进行
    易分辨的混合并仍能确定triples来自何处吗？

以下的提议方案从不同方面满足上述准则。本页的维护者对可伸缩性
问题尤感兴趣。请将反映你需求的准则提交给我！

出版物（Publications）
----------------------

下面这个论文讨论了以垂直模式存储和查询稀疏的关系表，这与一些
提议方案的精神非常相似：

R. Agrawal, A. Somani, and Y. Xu: Storage and Querying of
E-Commerce Data, Proc. VLDB 2001, Roma, Italy, available as
http://www.vldb.org/conf/2001/P149.pdf

存储RDF的数据库模式
-------------------

（最近的投稿在前）

清晰的模型（Explicit models）
-------------------------------

贡献者：Brian MacBride<bwm@hplb.hpl.hp.com>

日期：2000/5/11

摘要：本表示法清晰的表现模型并使用了视图

数据库模式（Oracle）和作者的描述：

                sql = "CREATE TABLE RDFRESOURCE"
                        + "("
                        +   "Id INTEGER not null primary key,"
                        +   "NS INTEGER not null,"
                        +   "RoName varchar(255)"
                        + ")";

资源表保存所有的资源，Id是内部的标识符字段，NS是个指针，指向
namespace表的条目以给出资源的命名空间。RoName应该叫做‘localname’，
是Qname的局部命名部分。

                sql = "CREATE TABLE RDFNameSpace"
                        + "("
                        +   "Id INTEGER not null primary key,"
                        +   "NsName varchar(255)"
                        + ")";

命名空间表。

                sql = "CREATE TABLE RDFLiteral"
                        + "("
                        +   "Id INTEGER not null primary key,"
                        +   "VAL varchar (4000)"
                        + ")";

literals [hax注：可译作文字常量] 表。 4000字符的限制对当前目
标来说足够。[hax注：Oralce的可变字符串的上限是4000字节]
               

                sql = "CREATE TABLE RDFStatement"
                        + "("
                        +   "Id INTEGER not null primary key,"
                        +   "Subject INTEGER not null,"
                        +   "Predicate INTEGER not null,"
                        +   "ObjResource INTEGER not null,"
                  +   "ObjLiteral INTEGER not null,"
                        +   "Res CHAR(1) not null"
                        + ")";

Statement [hax注：可译作语句或陈述] 表。最初是单个对象字段，
可以有一个对象或者文字常量的ID。使用一个复杂的JOIN表达式来列
举陈述，但并不如期望的运行。可能是我对SQL经验不足。而这个工
作和感觉更“正确”。Res是一个标志以说明对象是资源还是文字常
量。

                sql = "CREATE TABLE RDFModel"
                        + "("
                        +   "ModelId INTEGER not null,"
                        +   "Statement INTEGER not null,"
                        +   "Asserted CHAR(1) not null,"
                        +   "Reified CHAR(1) not null,"
                        +   "primary key(ModelId, Statement)"
                        + ")";

数据库可以处理多个models [hax注：可译作模型]。这个表保存了每
个模型的语句列表。最初该表由语句表组合，但当执行集合操作时不
能工作。

Asserted标志说明该语句用于给模型作断言。
Reified标志说明该模型用于使模型具体化。
后者是留给未来实现的挂钩（hook）。具体化（Reification）没有
被实现，因此这个方法是未经测试的。

每个模型都是资源，并在资源表里有一个记录。ModelId字段是该资
源的标识符。这样，就可以写关于某个模型的语句。这里有一个模型
的类，这样可以在确认模型有效性时列出需要被加载的模式（schemas）。

                sql = "CREATE OR REPLACE VIEW RootModel"
                     +  " AS SELECT UNIQUE Id, Subject, Predicate,
                          ObjResource, ObjLiteral, Res, Asserted, Reified"
                     +    " FROM RDFModel, RDFStatement"
                     +    " WHERE RDFModel.Statement = RDFStatement.Id";

这创建一个人造的模型视图，包含数据库里所有的语句，无论语句在
哪一个“实际的”模型里。

视图被大量使用。每个模型都是一个视图，即一个在其他模型视图或
者RootModel视图之上的查询。因此每次Stanford API 调用一个创建
模型的操作——如某个查询，数据库里就创建一个新的视图。这必然
会导致一些对数据库的查询引擎来说异乎寻常的查询，而我就依靠数
据库的查询优化器来整理之。这里也存在因陈旧失效的视图被留在数
据库里而可能的应用崩溃问题。

                sql = "CREATE TABLE RDFKEYS"
                        + "("
                        +   "TableName char(10) not null primary key,"
                        +   "Key INTEGER not null"
                        + ")";
                sql = "INSERT INTO RDFKEYS (TableName, Key)
                       VALUES('Resource', 0)";
                sql = "INSERT INTO RDFKEYS (TableName, Key)
                       VALUES('NameSpace', 0)";

一个键发生表。可能可以使用序列器（sequencer） [hax注：Oracle
使用序列产生自动递增或循环的数字]，但看起来有点数据库特性相
关，至少不是我一开始想要的，尽管真的只需要一个发生器。

关于模式（schemas）有个问题。当前，模式像模型一样处理，并可以
输入到模式有效性校验器。没有尝试使用模式来定义一个更特殊的数
据库结构。