- From: li wei <hot_bee@hotmail.com>
- Date: Tue, 11 Jul 2000 15:29:02 +0200
- To: <www-rdf-interest@w3.org>
- Message-ID: <20000711132746.82946.qmail@hotmail.com>
hello: I just read your page Storing RDF in a relational database, and feel the explicit mode of Brian McBride is resonable and natural, however no solution about storing reified statements and storing statement about another statement. I attempt to solve the problem with a complement and revises to the Brian's model. Here, thanks a lot for Brian's instruction and correcting on some misunderstanding on RDF of mine. Not for work related to RDF, I would not have touched RDF Specifications for about 1 month, here the solution about RDF storing is all from the intuition, maybe include some errors, I send it just for further discussion and correcting, anyway I am still a novice in RDF. Below is my database structure about RDF storing: To store RDF Schema and Models in our database, in this draft solution,we build 5 tables to describe all the information in RDF Schema and Models, NameSpace table, Resource table, Literal table, Statement table and M_S table. The functions of these 5 tables are introduced briefly below: 1.. NameSpace talbe is used to save namespace of each resource in RDF Schema and Model, use a table to save all the Name Space in one table can save space greatly. Fields Name Type Description ID Integer Auto-increased (Primary Key) NameSpace Char(255) Store the text of a name space URI b.. Resource table is used to save all the resource in Schema and Models, with reference from column NS_ID to column ID in NameSpace, all the resource can be restored easily. Fields Name Type Description ID Integer Auto-increased (Primary Key) NS_ID Integer Refers to the column ID in NameSpace table LN Char(255) The local name of a resource if exist Type Char(1) A flag to denote it is a Class, Property, Schema or Model. *Note: I set a column named type to the Resource table, which is used to denote the type of a resource, its value can express 4 different type: Class, Property, Schema and Model (Instance of Schema). Because all four above can be resource, but sometimes it seems hard to differ which type a resource is, especially for Schema and Model (instance of schema), for Schema itself is a RDF Model and defines many properties and classes which may be some instances of classes or subProperty of properties defined in another schema, then from the lines in Model, one can hard to say it is a Instance or a Schema. so I think the author of Model can assign it to be a Schema or not as his original wish. Each property, class, Schema and Model is treated as a resource, so it will be a record in the Resource table, when the resource is parsed to save into the table, our program will divide a URI with refragment '#' into two parts, the first part will be saved to NameSpace table, and the later part is saved in column LN in Resource table. e.g: a Resource "http://www.myWeb.com/reference.html#Content" will be saved separately as "http://www.myWeb.com/reference.html" in NameSpace table and "Content" in column LN of Resource table. c.. Literal table retains all the literals appeared in RDF Schema and Models: Fields Name Type Description ID * Integer Auto-increased (Primary Key) Literal Char(255) Stores the text of a Literal d.. All the statements appeared in RDF Schema and Models are saved in this table: Fields Name Type Description ID * Integer Auto-increased (Primary Key) Subject Integer See *Note Predicate Integer Refers to column ID in resource table Object Integer See *Note Tag Char(1) Denotes the the object is a literal or resource. 5.. M_S table expresses the relationship between statements and Models Fields Name Type Description Model_ID Integer Refers to the column ID in Resource table Stat_ID Integer Refers to the column ID in Statement table Asserted Char(1) A asserted flag Reified Char(1) A reification flag Pos Char(1) Denotes the position of reification in a statement about another. *Note: 1. Every statement in Model will be expressed by one entry in statement table, and the same time, an entry in M_S table, which is used to express its belonging Model. and from the "Asserted", "Reified" and "Pos" Column of M_S entry, it also denotes whether it is asserted, reified, and whether it is a statement about another. 2. To a normal statement, column subject, predicate and object save the corresponding value of the statement. However, when storing a statement about another, The value in columns Subject or Object store the Statement ID. For example: a statement: Ralph Swick says that Ora Lassila is the creator of the resource http://www.w3.org/Home/Lassila results in a triple {attributedTo, fact, "Ralph Swick"} here the fact is the reification statement of "Ora Lassila is the creator of the resource http://www.w3.org/Home/Lassila" The statement above is expressed by the line 2 in Statement table, the value in column Subject is the statement ID of the reified fact. ID Subject Predicate Object Ref 001 001 002 008 1 002 001 (Note, here it is the ID in Statement table, not the ID in Resource table 003 004 1 However according to the line in [4.1] in Model and Syntax Specification A new resource with the above four properties represents the original statement and can both be used as the object of other statements and have additional statements made about it. I use the column Pos in M_S table to denote that the reified fact statement is a Subject or an Object in the statemnt about the fact. Then according to the value 'S' or 'O' in column Pos, one can get the ID of the reified fact statement from column Subject or Object in Statement table. below shows the content in M_S table of the example above: Model_ID Statement_ID Asserted Reified Pos 005 001 0 1 0 005 002 0 0 S With this way, the verbosity of storing reification and statement about others is avoided. Caution: One should not retrieve statements from Statement table directly, because the same record in Statement table may express different real meaning by accident: a normal statement in a model, and at the same time, a statement about a reified fact in another model. So, only from the Pos column in M_S table, can one restore the right statement back. In view of that a same statement can appear in different model, and also the same one can be asserted or reified in one model but not in another model, the column "Asserted" and "Reified" are posited to M_S table in stead of Statement table to lessen verbosity. 3. The column tag denotes the object is a Resource ID or Literal ID, to a statement about another, it denotes the value in non-reification statement column is a Resource ID or a Literal ID. Li Wei 11/7/2000
Received on Tuesday, 11 July 2000 09:28:18 UTC