Graph Elements schema

[Aaron J. Seigo]

klink/SCHEMA prescribes a basic schema for the graph elements. i decided to 
try and create an implementation that might be workable. the result can be 
seen in klink/storage/copula.sql ... it's a postgresql database schema with a 
very small sample data set ... there is documentation at the top of the file, 
which i duplicate here:

COPULA v0.1

 Copula is a latin word meaning to "band, tie, link". As such it seemed an
 appropriate name for this experimental schema.

 This database schema represents a fleshing out of the "Graph Elements"
 section of the design documented in klink/SCHEMA. It ends with a simple
 set of data and queries which hopefully help to demonstrate how the database
 schema is meant to work.

 This is only a draft concept meant to encourage further thought on the
 issues and challenges at hand.


 DESIGN CONCEPTS

 There are three distinct representations attached to a discreet set of data
 (e.g. a document). These are monaforms, infons and locations. These are held
 together in a mesh.

 INFONS
 An "infon" is a discrete item of information. These are individual concepts
 drawn from a larger set of data (e.g. a document or a set of metadata). They
 may include concepts such as "artist" as well as specifics such as
 "Ani DiFranco".

 MONAFORMS
 A monaform is a root item that allows us to easily enter the infon relations
 given a desired perspective. If we are interested in audio files, we would
 start navigating infons from the Audio monaform.

 LOCATIONS
 A location is, at its essence, a URI with an associated mimetype. A location
 may be linked to zero or more infons.

 MESH
 The mesh table contains the set of links that lead from monaforms to infons,
 from infons to other infons and from locations to infons. A link always has
 an infon as a destination, but only one of a monaform, an infon or a location
 as a starting point.

 THE THREE LAYER STRUCTURE OF THE MESH
 This creates a three layered structure that looks, in one mapping, like this:


 Monaforms            Audio                   Books
 =======================|=======================|==
 Infons                 |                       |
         /-----/----/---|            /----/-----|
      Album Title Genre Artist    Title Genre Artist
                          \                     /
                          \-> "Ani DiFranco" <-/
=====================================^==============
                                     |
 Locations "file:/home/music/Ani Difranco/Ani DiFranco - Circle of Light.mp3"
====================================================

 STORED PROCEDURES
 A few stored procedures are provided from finding infons. primeInfon returns
 the infon(id) of an infon that is the destination point from a monaform.
 findInfon returns the infon(id) that is the destination point from another
 infon. It is possible to locate "Ani DiFranco" in the above mesh with either

      select findInfon(primeInfon('Audio', 'Artist'), 'Ani DiFranco');
      select findInfon(primeInfon('Books', 'Artist'), 'Ani DiFranco');

 These are simply convenience procedures to make writing some queries easier.
 It is anticipated that other stored procedures will follow, including,
 perhaps, the following:

      locationInfons -> return a set of infons that are destinations of a
                        a given location
      relatedLocations -> given an infon, return a set of locations
                          associated with it
      siblings -> given an infon that is the destination of a specified infon
                  return a set of infons that are also destinations

 I hestitate to write these before the need for them is manifest, however.

 OPEN QUESTIONS

 how to handle anchors?
    are they each individual, unique locations?
    should there be a tree-relationship between locations and sub-locations?
        where would this exist? the locations table? another table?

 should links be weighted?

 how should the properties found in the SCHEMA file be merged with this?

 dynamic navigation API
    what would an API allowing one to move from infon to infon look like?
    this really is the question answered, in draft form, but the current
      klink API proposal but from the opposite end of technology. while the
      API looks at it from the application developer perspective, this schema
      peers into it from perspective provided by the details of storage.

 SETTING UP THE DATABASE

 Here's the recipe i used, alter to taste:
 postgres at linux:~> createdb copula
 postgres at linux:~> createlang -d copula plpgsql
 postgres at linux:~> psql copula
 copula=# \i copula.sql

--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050130/fee8b736/attachment.pgp