Example:

my $a = new RDF::Dispatcher;

# Connect to a new interface. Return the interface resource
my $b = $a->get_interface("RDF::Interface::Schema::RDF_syntax_19990222");

# Return the collection of all statements known to the interface
my $c = $b->get_model();

# Return the collection that is the sum of all statements from the
# connected interfaces
my $d = $a->get_model();

# Return the model that is the part of the $d model matching the
# arguments
my $e = $d->find(pred,subj,obj);

# Get a model from within the interface
my $f = $b->get_model( uri );

# Get a collection of all models contained in the interface
my $g = $b->get_all_models();

# Return a collection of all the subject resources from the model
my $h = $d->subjects;

# Sets the prefix for the model. Created resources and statements gets
# this prefix
$d->set_prefix( uri );

# Returns a collection of resources representing the interface
# prefixes. The interface only contains statements and subjects with
# these prefixes.
my $i = $b->get_prefix();



Let every object be a resource. Couple this resource to a
interface. Also couple it with a path of classes that can be used.
All objects will be dispatcher objects.  The dispatcher objects
AUTOLOAD module sets the local @isa to be used for the method lookup,
depending on the type of object, its interface, and what modules has
been declared.




----------------------------------------------------

Thoughts about the Resource objects connection to a interface.
Statements storeded in a DBI interface will have their resources also
stored in the DB. If you say that a specific class is a subClassOf
another class, this means that subClassOf is stored in the DB, even if
it is primarly handled by the RDFS interface.

The DBI interface will insert the node in the DB. It may copy some
information from the other interface, like the label. But it shouldn't
have to, since the DBI isn't the primary source of data about the
object.  The info will come from the primary source.

The node will point to a model and that model will hold information
about the origin of the information and then it was last updated. The
agent will be the URI for the server and the source will be the URI of
the interface.  The details of this has not been developed.

The object in the cache will be marked with the interface that handles
its storage/retrievel. Other modules could offer methods for the
object.

A search for a resource will use range of the object. The find method
for a model will search its contents, a find for a interface will
search the interface and a find for a RDF object will search all
connected interfaces. Which interface to call in a search is
determined by the requested URI and the interface base URIs. It should
first search the closest match and then continue with the more general
interfaces.  The DBI interface can hold everything and will thus
always be searched.

It's one thing to be the owner or home interface of a node, and
antoher thing to say something about the node or with the node. If we
want to know everything said about a thing, we will have to search all
interfaces that could give a part of the answer. But if we only want
to know whats said from a limited number or sources, we can restrict
the search to the interfaces that handles the models owned by the
source we are intrested in.

#The first parameter to any method should be the client object. This
#object holds info about the connected interfaces and perhaps other
#preferences. There should be possible to have many diffrent and
#perhaps specialized configurations and use them in combinations.

The object interface list is constructed from the client interface
list signature and the object URI.

#A object is called with the client reference as a argument. The client
#holds a compiled key representing the interface list. The object has a
#key that represent all its types and all applicable interfaces.  A
#jumptable is constructed for the combination of the client and object
#keys. Every new object finds out its applicable interfaces.

How theese interfaces are to be used for diffrent purposes has yet to
be explored. On a method invocation, all methods should return a
result object or string that should give the requested information and
also give a response code telling if the next interface on the list
should be called or not. (This could be the second value.)

A list of things an object would like to do:

 * get created / modified / deleted

 * List the arcs in a interface

 * List arcs in a model

 * Get the label (for which objects has the interface attributes?)

 * Which resources does the interface own?


----------------------------------------------------

Ngra tankar om frndringar i RDF-klasserna.

Databasen bestr i huvudsak av node och arc.

Node bestr av id, uri och literal. En boolen hller reda p om
objektet r en resource eller literal. En pekare kan finnas fr att
peka till en BLOB-tabell fr att hlla strre data. Ett type-flt kan
spara mnga lookups. Men d behvs ocks ett stt att avgra internt
id fr den arc som bakas in. Den skulle kunna vara id fr resource
+1. Dessutom behver man veta om resourcen har ytterligare typer eller
inte genom exempelvis ytterligare ett boolean-flt. Vi mste d ocks
hlla gonen p relationen mellan type och lresource /
literal-booleanen, samt melaln den och literal-fltet respektive
BLOB-pekaren. Med vrig info skulle man kunna klara sig utan den
booleanen, men det lnar sig att slippa se om resursens typ indirekt
r resource eller literal.

Arc bestr av id, pred, subj och obj. Dessutom mste den ha en uri
ifall arcen r importerad och redan har ett URI. Och eftersom vi vill
koppla alla arcs till en model kan detta ocks gras. ven hr fr vi
ha en imlicit uri fr den kopplingen. Det kan ocks vara intressant
att ha ett datumflt som anger tid fr arc statement.

Model kan anvndas fr olika sorters filtreringar av appliaktionen fr
operationer och presentationer. Fr scheman finns kopplingen mellan
model och namespace.

----------------------------------

Hr kommer en rapport fr wraf 0.21.

Har kmpat emot hunger, trtthet, lttja och depression fr att komma
vidare. Har inte jobbat med filerna p ett par veckor nu.

Version 0.21 r allts den nya versionen. Design bygger bland annat p
anteckningar frn vrat frra mte:
    http://paranormal.se/perl/proj/rdf/wraf/devel/latest/doc/wraf2.txt

Jag skapade ett enkelt testfall:
    http://paranormal.se/perl/proj/rdf/wraf/devel/latest/bin/w21a.pl

Som anvnder de moduler jag brjat p hr:
    http://paranormal.se/perl/proj/rdf/wraf/devel/latest/lib/RDF_023/


Har lagt in ett par kommentarer i kllkoden.

Testfallet ser allts ut shr:

1. Skapa dispatcherobjektet.

2. Koppla upp mot ett interface och spara interfaceobjektet.

3. Hmta den modell frn interfacet som motsvarar alla dess statements

4. Generera en lista ver alla subjects i modellen

5. Skriv ut resursens namn fr varje subject i listan.


Detta frefaller fr mig vara relativt greppbart.


Vad gller modulstrukturen har jag valt att utg frn RDF och RDFS som
en helhet. Jag skapat klasser fr att representera resursern och alla
dess varianter som jag mste eller vill specialbehandla.

En viktig speciell sorts resurs r "collection" som r en samling av
resurser. Ett specialfall av collection r model, som r en samling av
resurser av typen statement. Alla urval av resurser kommer att
retunera collections. Collection-objektet har de metoder som behvs
fr att komma t dess element.

De olika resursklassernas metoder kommer vid behov att anropa
understdjande funktioner i interfacet (eller interfacen) fr det
objekt som behandlas.  Det r upp till varje resursmetod att
kontrollera om interfacet fr objektet har registrerat en optimerad
funktion fr att skapa resultatet.

Det r allts tnkt att varje interface deklarerar sina tjnster och
att varje resurs r kopplad till en (eller mjligen flera) interface.

Resursklasserna behver  sin sida deklarera vilken sorts resurser de
vill hantera. Om man s skapar en resurs av typen model, ska denna
automagiskt hra till motsvarande klass och drmed f de metoder
klassen erbjuder.

Dispatcherobjektet bestmmer vilka moduler som anvnds. En
konfigurationsmodul kan ange defaultinstllningar. Hela installationen
skulle kunna behandlas som ett interface till en collection av
moduler. (Skulle kunna...)

Vi behver tnka lite p vad som hnder nr vi vill introducera nya
funktioner, som exempelvis versionshangering. Behvs det en hel
uppsttning nya resursmoduler? En fr varje sorts resurs som ska
versionshanteras?


S... Vad jag fastnat i, och varfr jag skriver, r att jag undrar vad
Interface och Module egentligen r fr en slags resurser. Vi har
Function, Interface och Module. En Module kan vara ett Interface och
ha en rad Functions.  Jag brjade med att lgga upp Module och
Interface som Collections. Men r de collections? r Module i stort
sett en samling funktioner? r Interface en samling resurser?  Jag vet
inte.  Collection kan ju ha extra data frrutom samlingen. Men skulle
man kanske istllet lta Module ha en collection snarare n att den r
en collection?

Vill reda ut det hr.


I vrigt har jag ju nstan kommit hela vgen i detta frsta
testfall.  Alla de viktigaste schema-uppgifterna frn RDF och RDFS r
inmatade statiskt i en hash i RDFS_200001.

http://uxn.nu/wraf/devel/latest/lib/RDF_023/Interface/Schema/RDFS_200001.pm

------------------------

Varje interface har en hash med types dr det fr varje type finns en
hash med metoder. Varje metod r en referens till en lista p de
funtkioner som ska anropas fr den metoden och typen.

Varje resurs har en lista p interface den anvnder. Fr varje sdan
lista finns en metodtabell som pekar p, fr varje typ, vilka
funktioner ett visst anrop ska g till. Finns inte metodtabellen
skapas den vid behov. (Varje interface kommer att ha en unik referens
som ndras med uppdateringar.) Varje gng ndring sker i interface
eller type nollstlls en pekare som pekar till en unik hash fr
kombinationen av interfaces och types.

Nr en resurs skapas skickas en referens till det aktuella
interfacet. Alla resources r tminstonne av type resource och fr den
typen ska det finnas en metod fr att ta reda p vilka andra typer
resourcen ocks r.

Det hr r en optimering av hastighet p bekostnad av utrymme. 

Fr nyckel och internt id anvnds en mappning av varje anvnd uri till
ett lpnummer. Dvs en uri-hash fr att sl upp id och en id-array fr
att sl upp uri. D denna enbart anvnds internt i programmet kan den
nollstllas vid omstart av program. Men om den blir stor kan den
implementeras som tv dbm som knyts till hash. Varje interface kan ha
sina interna id's, men denna r interna fr systemet i helhet.
Speciellt fr mappning av interface och typer till metoder och
eventuellt fr cache-funktionen, etc.

The list of types should be expanded and specialiced types should be
put first. The resource type should not be mentioned because all
resources is of that type. Subtypes should NOT inherit methods from
its more general type.
