[Zeusagent-developer] Re: Persistent Facts Update

[Craig A. <cra...@ho...>]

> 1) SQL->ONT support in the Ontology Editor
>    What this means is you can import a SQL create table command into
>    the Ontology Editor and get an equivalent ontology created for
>    you. This requires a simple SQL parser - anybody seen one?

Are you sure you need to do it this way?
I'm not particularly familiar with the details, but it sounds like hard work
parsing your own SQL, Is there any reason why the ontology metadata
shouldn't be stored in metadata-tables and the application specific ontology
entered into the tables at design time & extracted at run-time. This would
have the advantage that the "IDE" could ship with a set of SQL scripts to
create the framework database, and the definition of ontologies and facts
would be a matter of entering data through the IDE, not writing raw SQL..

> 2) DB->Fact conversion
>    This mechanism allows agents to read stored data in tables and
>    convert it into a fact object.
>    QUESTION: Do we assume all persistent facts exist in the database
>    before the agent is run for the first time?

Not sure I know exactly why this is an issue, but certainly the
agent/framework should be able to handle lack of appropriate data
gracefully. Also I can envisage the potential need (scalability?) for the
agent to be able to query the fact database after initialisation. What if
the fact database was very large for example - it might not be sensible to
load all the facts on initialisation, but rather only those it needed for
the execution of the current task. I'm not completely sure I've grasped the
point here though.

> QUESTION:
> If we encapsulate database-backed facts in the ResourceDb there's
> no point in the ExternalDb interface, is there? I'm tempted to remove
> it - any thoughts on the matter?

Could it be useful for anything else? Certainly I could imagine agents
wanting to query databases external to the fact database.

> I'm using mySQL as my database platform. It's quite good
Everyone says it's very good at what it does, but I've not used it,
precisely because the last time I checked it didn't support transactions,
this may have changed by now and is not relevant to your current work of
course, but we'll need an alternative at some point fairly soon.

----- Original Message -----
From: "Jaron Collis" <jar...@se...>
To: "Zeus Dev" <zeu...@li...>
Cc: "Craig Arnold" <cra...@di...>
Sent: Wednesday, October 18, 2000 8:27 PM
Subject: Persistent Facts Update


> Hi folks,
>
> Here's the latest progress on the DB-based fact stuff.
>
>
> Design Issues
> -------------
>
> The way I see it, there's 3 facilities necessary:
>
> 1) SQL->ONT support in the Ontology Editor
>    What this means is you can import a SQL create table command into
>    the Ontology Editor and get an equivalent ontology created for
>    you. This requires a simple SQL parser - anybody seen one?
>
> The process that converts a data schema into an ontology is the
> vital component as it will also be used for...
>
> 2) DB->Fact conversion
>    This mechanism allows agents to read stored data in tables and
>    convert it into a fact object.
>    QUESTION: Do we assume all persistent facts exist in the database
>    before the agent is run for the first time?
>
> 3) Fact->DB conversion
>    The write mechanism, providing a means of converting facts into
>    the corresponding tables, columns and values.
>
> QUESTION:
> If we encapsulate database-backed facts in the ResourceDb there's
> no point in the ExternalDb interface, is there? I'm tempted to remove
> it - any thoughts on the matter?
>
>
> Progress
> --------
>
> I'm using mySQL as my database platform. It's quite good.
>
> I've created a class called zeus.ext.DbConnector, which is intended as
> the JDBC bridge between agent and DB. The hard part will be writing the
> create(), read(), update() and destroy() methods, as they rely on the
> ontology<->table mapping mechanism I mentioned earlier.
>
> So, if there's any thoughts on the subject let me know.
>
> Jaron