Re: [DotGNU]GNU.RDF

[James Michael DuPont]

Looks good peter.
There are a couple of things that you might want to think about.

Isolation and abstraction.

The design of Database Tables are going to have to abstracted a bit.
Maybe you will want to hold values, integers, uris in the tables.

I would like to try and help out on this.

mike

--- Peter Minten <address@hidden> wrote:
> Peter Minten wrote:
> > 
> > Hi folks,
> > 
> > I'd like to propose a new project: GNU.RDF .
> 
> Addition.
> 
> First a little vocabulary change. The programs that only have read
> access to the
> store were called agents, now they are called extractors. The new
> definition for
> a agent is an extractor, manager or harvester (agents = extractors +
> managers +
> harvesters).
> 
> I've defined a major task list:
> 
> --- MAJOR TASK LIST ---
> 
> 1) Store design
> 
> The store is the heart of GNU.RDF, the whole RDF web of a server is
> stored in
> it. The major challenge with the store is creating an efficient
> database design
> to store the RDF web in. Then again a few minutes of thinking
> revealed this
> design (in pseudo SQL):
> 
> TABLE triples
> {
>       subject : subjects.pkey%type;
>       predicate : predicate.pkey%type;
>       object : object.pkey%type;
> }
> 
> TABLE subjects
> {
>       pkey : unsigned long; #2^64 = ~ 18 * 10^18
>       uri : strings.pkey%type;
> }
> 
> TABLE predicate
> {
>       pkey : unsigned long;
>       uri : strings.pkey%type;
> }
> 
> TABLE object
> {
>       pkey : unsigned long;
>       type : strings.pkey%type;
>       data : blob;
> }
> 
> TABLE strings
> {
>       pkey : unsigned long;
>       string : text;
> }
> 
> Note that this design is a little optimised for size. One could
> replace the 5
> tables by just the triples one. A lot of uri's would be duplicated
> however and
> since about every uri takes up more space than a long that would mean
> a lot
> bigger database (I'm guessing 2 or 3 times bigger).
> 
> Using the blob data type for the data field might not really be
> efficient,
> possibly a replacement by an unsigned long that can be a referal to
> multiple
> tables, depending on what type is. This approach would place strings
> and numbers
> not in blobs offering a speed improvement.
> 
> I don't know if this approach of few tables is very good for speed, I
> figure
> however that with due indexing it will work.
> 
> 2) Agent API
> 
> Data will need to be put in and pulled out of the store, in a secure
> way (only
> done by autherised programs). Agents will need to communicate
> securely with
> their clients. These are the goals for the agent API.
> 
> Note that the agents will not need to receive complete RDF in
> response to their
> queries but it should be possible. The queries must be specifiable
> using special
> RDF query functions or using plain old SQL (I see a lot of subqueries
> on the
> horizon :-).
> 
> 3) Basic agents
> 
> Some very basic agents will need to be provided.
> 
> 4) RDF editor
> 
> On the client side the RDF web must be browsable and editable (if
> auth allows
> it). To do this a visual RDF web viewer and editor must be created.
> The editor
> must have functions to hide/show certain resources based on the users
> preference. At least non-resource properties must be editable using a
> simple
> property table.
> 
> 5) GNU RDF vocabulary
> 
> The GNU RDF vocabulary will be the standardized way to store (nearly)
> all
> information about projects. The root of this namespace will be
> 'http://gnu.org/rdf'. Note that this does not mean gnu.org must have
> a rdf
> directory, RDF resources using Uniform Resource Identifiers, not
> Uniform
> Resource Locators.
> 
> A short list of important classes:
> 
> * Person
> * Project
> * Program
> * Package
> * Task
> * Bug
> * FeatureRequest
> 
> --- END MAJOR TASK LIST ---
> 
> Greetings,
> 
> Peter
> 
> 
> _______________________________________________
> Developers mailing list
> address@hidden
> http://www.dotgnu.org/mailman/listinfo/developers


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com