Re: an idea

Hello!

> (i saw a lecture from somebody who worked on microcosm (now part of
> http://www.multicosm.com/) (Yet another "blargh blargh we invented
> hypertext before cern aren't we great" type things) but one of the
> fundamental things about microcosm was that by default links between
> entities were externalised and held in linkbases, such that links aren't
> an intrinsic part of the data (this is especially useful for
> applications where the links aren't navigational)).

A very good idea, this would make the whole link framework much more
flexible and easier to change.

> basically
>
> 1) define a canonical namespace for gpe namespace data (may as well use
> URI syntax, thats what its there for)
> i.e. gpe:///todo/13212/ etc...
> *host specification is intentionally left null, as thats a different
> problem, basically assume all names are relative to the current device
> for now*
> where the ID can just be the uid to the main entity in the link class.

Hmmm well... basically this sounds good, but i don't really know how to
use it where. OK, this is good for reading data that is already stored in
the gpe database, but much less useful to change this data.

> 2) allow for binding between a gpe URIs and mechanisms for viewing those
> objects (there should be a default protocol->application binding
> mechanism anyway)

This would be the "reading case" - i this way it would be easy to use
a user defined application to handle a particular set of data. For an
application like "gpe-today" as suggested in CurrentThingsToDo wiki this
would be great. It would make sense to start developing this
framework together with "gpe-today" or a similar project as a kind of
working example.

> 3) have a library that manages linking in a sensible way so it can be
> internalised for specific applications
> links can then be stored in the database in a two (or three or four if
> you want to account for things like direction and annotation, or have
> 'types' of links (like meetings etc)) where you just have pairs of URIs.

I think types of links are the better choice, using this approach it's
easier to decide what kind of link you have how to handle it. If we'd
add the information to identify linked data (e.g. adding a field to store
the name of a field containing an unique id) the linkage framework would
be nearly independent from data layout. On the other hand it would be
possible to define a database scheme to define these id fields. This
approach will at least save some space.

To make it short: Keeping link framework away from the rest of the database
makes life easier and gpe better ;-)

greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: 0271-771091-14 | Fax:0271-771091-19
and the reality of tomorrow.            florian.boor@kernelconcepts.de | boor@unix-ag.org
[Robert Hutchings Goddard, 1904]        6C 44 30 4C 43 20 6B 61  16 07 0F AA E6 97 70 A8