Menu
▾
▴
zeusagent-developer
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(10) |
Aug
(18) |
Sep
|
Oct
(27) |
Nov
(2) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Habib L. <hab...@et...> - 2002-01-17 17:01:11
|
Hi I'm trying to build a small agent application with Zeus. I'm willing to create an agent that performs a simple Search in the DF and send a message to all the agents corresponding to the description. I can't understand how this works on ZEUS. I don't want to have any coordination protocol, i'm just willing to basically register the agent type with the DF, search for a certain type of agent and send to the agent i found a message. Can anyone help me because I understood that if an agent wanted to communicate with another, this had to be described in the Agent Building toolkit in agent coordination. Thank you for your help. |
|
From: <sim...@bt...> - 2001-03-03 20:02:44
|
Chaps, I am about to release 1.1 (in the next few days at least...) unfortunately sourceforge is screwed again, and I cannot now check stuff into the CVS. Which means that no one can preview the release... If anyone has any objection to me just taking the plunge and releasing the new version (as a beta..), or if you need more info before commenting, please let me know. I know that this is a bit "high handed" but I am under pressure here to get this release out.... here is the header I will put on the release notes: >> This release is being made for two reasons: * The open source principle is "release early, release often" and it is a while since we released anything. Things are turning into a bit of a "death march" and I feel the need for fresh eyes and comments, hopefully once this stuff is in the public domain I will get lots of help with it! * I promised a 4/03/01 release: here it is! However, the first thing to say is that this is BETA code - please use it with caution. The unresolved issues are laid out in this document. There were two major objectives of the work for this release of Zeus. * To provide a FIPA compliant ACC for Zeus so that agent platforms that are implemented with Zeus can talk to platforms that are implemented to FIPA specs - such as FIPA-OS and JADE. * To improve the Zeus API * More examples * Several side projects were also integrated: * A new OntologyDb with an interface to SQL schemas via meta-data (courtesy of Dr. Jaron Collis - ja...@bt...) * Some patches were applied to the TaskWriter and TaskContext classes (coutesy of Herr Max Scheidt ma...@or...) * The RETE engine was partially rewritten to provide extensibility << I would send you the rest of the notes, but I haven't written them yet! Si . y Dr. Simon Thompson, Intelligent Business Systems Research Group, BT Exact Research, Adastral Park. 01473 605531 (phone) 01473 642459 (fax) www: http://innovate.bt.com/people/thomps65/index.htm British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. |
|
From: Jaron C. <jar...@se...> - 2001-01-15 19:27:20
|
> If anyone has anything to contribute, now is the time! OK, I'll commit the completely new files. They work ok and won't affect anything anybody else has done. The changed files will have to be branched though, is that done by using the winCVS fork option? Never done this before, anybody else? Jaron |
|
From: <sim...@bt...> - 2001-01-15 19:14:41
|
Alot of work has been done on the current CVS of Zeus since the last release. Jaron has implemented the OntologyEditor connection to SQL thingy (technical term) I have built a IIOP interface (FIPA-Acc) which works a bit (I think that the envelopes are no good....) I have also fiddled with the threading a bit. This was a nasty experience, I can tell you, and I am not sure if it was a good idea. Some new examples have been added. I will be working on things a bit more for a few weeks, mainly to re-architect and refactor to make the API a bit easier, and to clean up some of the mess that I have made recently. I think that Jamie has some more examples to contribute, and I think that the documentation needs to be revisited to reflect recent changes. Then I am going to go for another release. If anyone has anything to contribute, now is the time! In the meantime please download the new jar file and have a go with it, or give me any feedback that is appropriate. y Dr. Simon Thompson, Intelligent Business Systems Research Group, BT Exact Research, Adastral Park. 01473 605531 (phone) 01473 642459 (fax) www: http://innovate.bt.com/people/thomps65/index.htm British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. |
|
From: Jaron C. <jar...@se...> - 2001-01-05 12:20:18
|
Hi Chris, > Has anything happened on this front recently? Are you still > interested? There's slow movement occuring on this front, I'm definitely still interested in it, to my mind Enterprise Java provides the best foundation for agent software. I'm producing a new ResourceDb at the moment. I decided against trying to modify the code you sent me, i.e. adding JDBC to the ResourceDb - it was getting far too hacky. Instead, and in the spirit of the new year, the ResourceDb has gone on a crash diet. * All planing resource management code is shifted to a ResourceUtils class * Storage of facts is delegated to a class implementing the new ResourceDbModel interface; there's currently two: - HeapStore : which stores facts in heap memory as normal - DatabaseStore: which stores facts via JDBC persistently As a result the ResourceDb is about 20% of its previous size, it has the same methods, but serves now as an interface between other agent components and the storage model. This approach is much easier to understand, modify and extend. I'll tidy the code and upload the story so far to SourceForge in the next few days. Jaron |
|
From: <sim...@bt...> - 2000-12-20 11:23:48
|
Just to let you know that the complete deletion of the CVS tree at Sourceforge is nothing to do with any cack handedness on the part of project admins, and that we are actively persuing them for a fix. Aaarrrrghhhhhhh. Si. y Dr. Simon Thompson, Intelligent Business Systems Research Group, BT Exact Research, Adastral Park. 01473 605531 (phone) 01473 642459 (fax) www: http://innovate.bt.com/people/thomps65/index.htm British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. |
|
From: <sim...@bt...> - 2000-12-18 13:47:49
|
Hi, I have checked a new document into the CVS tree (under Zeus Documentation) which is Zconcepts.doc. This is a set of interesting conceptual diagrams and text which has come out of LEAP, and I think might help people get there head around Zeus a little better. Perhaps you guys could have a look and tell me what you think. I have attached it to save you the trouble of getting it out of CVS as.... The sourceforge site is comprehensively broken - our CVS tree cannot now be browsed via html, and the stats tracker is down. I have complained, but we will have to wait for a fix, I am afraid. Wincvs still seems to work though. Si. <<Zconcepts.doc>> y Dr. Simon Thompson, Intelligent Business Systems Research Group, BT Exact Research, Adastral Park. 01473 605531 (phone) 01473 642459 (fax) www: http://innovate.bt.com/people/thomps65/index.htm British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. |
|
From: Jaron C. <jar...@se...> - 2000-11-16 11:02:41
|
Hello again folks, After a brief pause to tend to Servista matters I'm back on the case. And after due consideration my plan is to take a knife to the ResourceDb and split it up a bit. The ResourceDb class is going to be simplified so it becomes a view. If this gets too complicated I'll split the code into view/controller classes. I feel the interface to the ResourceDb should be as simple as possible, so developers aren't scared to look at it. Storage is going to be removed from ResourceDb and given to a new class, tentatively called ResourceDbModel, which will handle storage in either memory or through a DB connection. The code Chris sent used an alternative arrangement, based on inheritence rather than aggregration. I prefer the latter, but am open to suggestions. Jaron |
|
From: simon t. <sim...@ya...> - 2000-11-02 17:14:10
|
Hi Chaps, I have requested that Sourceforge modify the directory structure of zeusagent cvs so that zeus/1_04 is removed, and 1_04 is renamed as sourcecode. Unfortunately it seems that the sourceforge servers ban you from doing these changes in person. I hope that this is what everyone wants.... Si. __________________________________________________ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ |
|
From: simon t. <sim...@ya...> - 2000-10-31 18:35:46
|
> I assume this will give us one obvious 'current > version' directory, > which we don't have to rename everytime the version > number changes? Ohhh meeeiowww. I've had a very bruising day, you beast. But I have to admit, naming it 1.04 was a dumbassed thing to do. Mea cupla. Si. --- Jaron Collis <jar...@se...> wrote: > > > I think that we should retain one CVS tree for > > enterprise zeus and zeus1.1 and branch to handle > the > > development process. > > > > This leaves us able to merge and release later on. > > > If you think that's the path of easiest maintenance > then go for it. > I assume this will give us one obvious 'current > version' directory, > which we don't have to rename everytime the version > number changes? > > J > _______________________________________________ > Zeusagent-developer mailing list > Zeu...@li... > http://lists.sourceforge.net/mailman/listinfo/zeusagent-developer __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ |
|
From: Jaron C. <jar...@se...> - 2000-10-31 17:29:38
|
Hi folks, Stage one is done: I've modified the OntologyEditor to import tables and columns. And the new information can be saved in a .ont file. I'll upload the new stuff to Sourceforge soon. So, next item on the agenda is modification of the ResourceDb so facts derived from the database can be read and written. I was thinking of writing the modifications myself, but then Chris sent me a modified ResourceDb his team had written (cheers Chris). I'm going to spend the next day or two understanding how it works and how it squares with my own mental model, but it looks very promising. An interesting feature of their approach is that facts do not store whether they are persistent or not, the ResourceDb keeps track of what's been mapped to a JDBC connection. I feel it's important the data remains in the DB, with the ResourceDb just holding a pointer to it. So Chris's team's approach is similiar to my own thinking. If anyone wants to look at what Chris & co have produced, tell me and I'll post the relevant java files. Jaron |
|
From: Jaron C. <jar...@se...> - 2000-10-31 17:24:07
|
> I think that we should retain one CVS tree for > enterprise zeus and zeus1.1 and branch to handle the > development process. > > This leaves us able to merge and release later on. If you think that's the path of easiest maintenance then go for it. I assume this will give us one obvious 'current version' directory, which we don't have to rename everytime the version number changes? J |
|
From: simon t. <sim...@ya...> - 2000-10-31 16:46:09
|
Chaps, I think that we should retain one CVS tree for enterprise zeus and zeus1.1 and branch to handle the development process. This leaves us able to merge and release later on. The alterantive is a fork in the cvs, which will mean a merge by hand later on, which could be very tedious. What do you think? Si. __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ |
|
From: simon t. <sim...@ya...> - 2000-10-27 12:27:12
|
Ok, Sourceforge is denying me permission to send the attachment, and denying me access to the list in order to give permission. I will check JB into the sourceforge site as soon as they have fixed my cvs account, which they have horlixed. Ho Hummmm Si. __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ |
|
From: simon t. <sim...@ya...> - 2000-10-27 09:16:32
|
here is JB, which I should have distributed before: This is due to the nice people at HP in PA (Dick Cowen and Martin Griss), so kudos and thanks to them. I have been using it to build all the Zeus distributions, but you might need to fiddle with it to get it to work on your environment. Hope it helps. Si. --- Jaron Collis <jar...@se...> wrote: > > > I've been trying to compile the zeus system, and > I'm running into a few > > problems. There are half a dozen package errors > which are trivial to sort > > out, but then there seems to be a more substantial > problem with the > > organisation of the visualiser package. > > Ooops, the zeus.visualiser.control package contains > incomplete code, so > won't compile correctly. > Easiest way round it is to delete the class files > with your zeus/visualiser > directory and compile Visualiser.java > Any java file that doesn't get compiled after that > can be deleted safely > (I think the few involved are in the control > package). > > > I'm stuck in the DoCommandUI.java file. Details in > code attached using the > > handy java -> html feature in JBuilder4 - pretty > eh? > > Yes, very nice. > > > But it raises the interesting question of what one > should do when > > one finds package declaration errors for example - > I'm new to this open > > source stuff (and being a bit lazy just asking > like this I suppose :) - > > instead of investigating first.) > > Nah, always ask first, we can tell you things (like > .control.* is > incomplete) > that would take you ages to infer. > > Jaron > > _______________________________________________ > Zeusagent-developer mailing list > Zeu...@li... > http://lists.sourceforge.net/mailman/listinfo/zeusagent-developer __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ |
|
From: Jaron C. <jar...@se...> - 2000-10-26 17:14:01
|
> I've been trying to compile the zeus system, and I'm running into a few > problems. There are half a dozen package errors which are trivial to sort > out, but then there seems to be a more substantial problem with the > organisation of the visualiser package. Ooops, the zeus.visualiser.control package contains incomplete code, so won't compile correctly. Easiest way round it is to delete the class files with your zeus/visualiser directory and compile Visualiser.java Any java file that doesn't get compiled after that can be deleted safely (I think the few involved are in the control package). > I'm stuck in the DoCommandUI.java file. Details in code attached using the > handy java -> html feature in JBuilder4 - pretty eh? Yes, very nice. > But it raises the interesting question of what one should do when > one finds package declaration errors for example - I'm new to this open > source stuff (and being a bit lazy just asking like this I suppose :) - > instead of investigating first.) Nah, always ask first, we can tell you things (like .control.* is incomplete) that would take you ages to infer. Jaron |
|
From: Craig A. <cra...@ho...> - 2000-10-26 16:58:58
|
Simon, Jaron I've been trying to compile the zeus system, and I'm running into a few problems. There are half a dozen package errors which are trivial to sort out, but then there seems to be a more substantial problem with the organisation of the visualiser package. I'm stuck in the DoCommandUI.java file. Details in code attached using the handy java -> html feature in JBuilder4 - pretty eh? Actually I was trying to get a compiling system so that I could do some debugging in the Agent Generator to get a better grip on the stuff Jaron's working on. But it raises the interesting question of what one should do when one finds package declaration errors for example - I'm new to this open source stuff (and being a bit lazy just asking like this I suppose :) - instead of investigating first.) Thanks chaps. Craig |
|
From: Jaron C. <jar...@se...> - 2000-10-24 18:34:45
|
> > Of course this assumes that persistent data originates from outside the > > ontology editor, but I think that's always going to be the case anyway. > > This seems a fair assumption - will we close any doors > to future development using this approach? None that I can think of. > I think that a relational ontology can be expressed in > terms of classes, but a class based ontology contains > things that can't be expressed as a relational > ontology - basically sub classes being related to > tables related to the super class and other new tables > (possibly) as well. I think we are ok though, because > we just state the obvious that if you want an oo > schema storing it in a relational database is pretty > much out of the question... OK, that pretty much covers the outstanding issues in my mind. I'm currently adding JDBC support to the OntologyEd, and will be able to start modifying the Fact class soon. I'll keep you informed. J |
|
From: simon t. <sim...@ya...> - 2000-10-24 17:18:35
|
--- > > Of course this assumes that persistent data > originates from outside the > ontology > editor, but I think that's always going to be the > case anyway. Db's have > much > better data modelling tools than we can ever hope to > build. This seems a fair assumption - will we close any doors to future development using this approach? > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/Enterprise%20Zeus/s > ketches/ontEd.gif?rev=1.1&content-type=image/gif&cvsroot=ZeusAgent > > The general idea being that the user forms a > connection to the database, and > the table/columns to import and the OntologyEd > creates equivalent facts of > the > most appropriate matching type. > Nice, although the button label should be "Import Selected" because the table has columns in rows - if you follow me, and this sort of label is the kind of thing that I have spent weeks stareing at in the past until I realised that they didn't mean columns in the table, but columns in the database.... But then I am quite thick. > One issue raised is that of naming. Say I import > surname from a table called > customer, should I just store that in the ontology > as customer.surname? > That would make it easier to map facts back to the > tables they're grounded > in. > This seems sensible. > There may be other issues related to database > schemas being relational > whilst > our ontology is class-based. If you can think of > anything, tell me. > I think that a relational ontology can be expressed in terms of classes, but a class based ontology contains things that can't be expressed as a relational ontology - basically sub classes being related to tables related to the super class and other new tables (possibly) as well. I think we are ok though, because we just state the obvious that if you want an oo schema storing it in a relational database is pretty much out of the question... > Si. > > > _______________________________________________ > Zeusagent-developer mailing list > Zeu...@li... > http://lists.sourceforge.net/mailman/listinfo/zeusagent-developer __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ |
|
From: Craig A. <cra...@ho...> - 2000-10-24 08:28:51
|
> > Hmmmm, > > My last message seems to have been lost in the ether. > So I'll repeat it... > > My plan is to use JDBC metadata rather than a SQL parser to implement > the Db-to-Ontology mechanism. Remarkable - on the train home last night I was thinking that this would be a pretty neat solution. > > So, first port of call is the OntologyEditor, which needs some way for the > user > to specify the database, tables and columns to import. My idea is to create > an > extra tab panel, which will look something like this: > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/Enterprise%20Zeus/s > ketches/ontEd.gif?rev=1.1&content-type=image/gif&cvsroot=ZeusAgent > Can't follow the link, but the approach seems sensible to me. > One issue raised is that of naming. Say I import surname from a table called > customer, should I just store that in the ontology as customer.surname? > That would make it easier to map facts back to the tables they're grounded > in. > Seems sensible. > There may be other issues related to database schemas being relational > whilst > our ontology is class-based. If you can think of anything, tell me. Just to clarify - are we planning to store the Ontology in DB tables? A fairly standard way of mapping is class.properties<->table.fields, where the fields mapping gets all the properties of the entire class hierarchy, which makes the table bigger, but it's normally still manageable. |
|
From: Jaron C. <jar...@se...> - 2000-10-23 14:14:47
|
Hmmmm, My last message seems to have been lost in the ether. So I'll repeat it... My plan is to use JDBC metadata rather than a SQL parser to implement the Db-to-Ontology mechanism. The general idea is to do a "select * from sometable", load the results into a ResultSet and then use the ResultSetMetaData to create the matching ontology concepts. Of course this assumes that persistent data originates from outside the ontology editor, but I think that's always going to be the case anyway. Db's have much better data modelling tools than we can ever hope to build. So, first port of call is the OntologyEditor, which needs some way for the user to specify the database, tables and columns to import. My idea is to create an extra tab panel, which will look something like this: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/Enterprise%20Zeus/s ketches/ontEd.gif?rev=1.1&content-type=image/gif&cvsroot=ZeusAgent The general idea being that the user forms a connection to the database, and the table/columns to import and the OntologyEd creates equivalent facts of the most appropriate matching type. One issue raised is that of naming. Say I import surname from a table called customer, should I just store that in the ontology as customer.surname? That would make it easier to map facts back to the tables they're grounded in. There may be other issues related to database schemas being relational whilst our ontology is class-based. If you can think of anything, tell me. Cheers, Jaron |
|
From: Craig A. <cra...@ho...> - 2000-10-23 10:08:25
|
Re 1 & 2. - Yes it seems there is no perfect solution. i.t.o a useful general purpose IDE though, I'd suggest an export for both as preferable to an import as the starting point. This for 2 reasons: i) it's easier to implement :) (no SQL parser required) ii) it fits in with what I imagine most developers would expect to find in an agent builder IDE, certainly when developing an application from scratch it's fairly common to have to take an existing ERM and "enter" it into an application framework IDE. Adding an import feature is something I would suggest for a later phase. > Message: 3 > From: "Jaron Collis" <jar...@se...> > To: <zeu...@li...> > Subject: RE: [Zeusagent-developer] Re: Persistent Facts Update > Date: Thu, 19 Oct 2000 11:26:14 +0100 > charset="iso-8859-1" > Reply-To: zeu...@li... > > > > > 1) SQL->ONT support in the Ontology Editor > > > > 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.. > > There's no reason why we couldn't do it this way. My suggestion was > based on the assumption that the database schema would exist before > the agents were created. I didn't think it as likely that the schema > would be created inside the ontology editor and exported. > So which should I implement, import or export? > > > > > 2) DB->Fact conversion > > > 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. > > It's related to issue #1 - do we assume the values in the database > tables exist before the agents are run, or do we write them into the > tables after we finish using the ontology editor? > > > 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. > > It's a good point. Persistent data should spend most of its time in the > database, not the memory heap of the agent's VM. And this is especially > important if big tables are concerned. The fact access mecahnism should > be able to manage this transparently. > > > > > 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. > > That's true, you might want to query more than one DB. I might remove > references to ExternalDb from the ResourceDb though, and just let users > access ExternalDb through their own ZeusExternals. > > > > > 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. > > Might move onto your original suggestion of Interbase then! > MySQL's main advantages are that it's small, quick and easy to install. > It'll do whilst I work out these import and export mechanisms. > > Any other design thoughts? > > Jaron > > > > --__--__-- > > _______________________________________________ > Zeusagent-developer mailing list > Zeu...@li... > http://lists.sourceforge.net/mailman/listinfo/zeusagent-developer > > > End of Zeusagent-developer Digest_______________________________________________ > Zeusagent-developer mailing list > Zeu...@li... > http://lists.sourceforge.net/mailman/listinfo/zeusagent-developer |
|
From: Jaron C. <jar...@se...> - 2000-10-19 10:23:59
|
> > 1) SQL->ONT support in the Ontology Editor > > 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.. There's no reason why we couldn't do it this way. My suggestion was based on the assumption that the database schema would exist before the agents were created. I didn't think it as likely that the schema would be created inside the ontology editor and exported. So which should I implement, import or export? > > 2) DB->Fact conversion > > 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. It's related to issue #1 - do we assume the values in the database tables exist before the agents are run, or do we write them into the tables after we finish using the ontology editor? > 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. It's a good point. Persistent data should spend most of its time in the database, not the memory heap of the agent's VM. And this is especially important if big tables are concerned. The fact access mecahnism should be able to manage this transparently. > > 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. That's true, you might want to query more than one DB. I might remove references to ExternalDb from the ResourceDb though, and just let users access ExternalDb through their own ZeusExternals. > > 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. Might move onto your original suggestion of Interbase then! MySQL's main advantages are that it's small, quick and easy to install. It'll do whilst I work out these import and export mechanisms. Any other design thoughts? Jaron |
|
From: Craig A. <cra...@ho...> - 2000-10-19 08:21:38
|
> 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 |
|
From: Jaron C. <jar...@se...> - 2000-10-18 19:25:00
|
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 |
1 message has been excluded from this view by a project administrator.
