Menu
▾
▴
ztm-devel — This is a mailinglist for discussions of development of ZTM
You can subscribe to this list here.
| 2004 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
|
May
(6) |
Jun
|
Jul
(1) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Arnar L. <arn...@bo...> - 2004-08-05 11:45:28
|
I have branched ZTM 2.5 in sourceforge CVS. You can retrieve it using the ZTM-2_5-BRANCH. This branch is closed for anything but bugfixes and documentation. The trunk is now open for surgery. I consider 2.5 feature-complete (wrt. the goals we set that is :-) ). What remains is some testing of the installation-routines and some howto documentation. (I expect to upload beta 2 to Sourceforge tonight.) As I have mentioned earlier, the immediate goal for ZTM 2.6 is internationalization and unicode use. We will reimplement all templates in TAL/METAL and add internationalization (i18n). The default language will be English. We will include a Norwegian translation. There are other features we are considering, but right now I am inclined to keep the set of new features low so that we can get 2.6 out early this fall. Opinions? Requests? Wishes? -- Arnar -- Arnar Lundesgaard | Konsulent Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Arnar L. <arn...@bo...> - 2004-08-04 12:29:00
|
On Wednesday 04 August 2004 14:08, bernard.chabot wrote: > Ok, I could easely create a folder named "my topics" > I can see 2 names on each topic : > - the second one with a "x-zope-id" type > - the first one without type > > ... and I could't set any type to the first name The first one is used as the topics title (a CMF construct). This is the one you must edit. Simply change the value, and the catalog should be updated. I don't know why you couldn't add a type to the basename. That sounds like a bug, so I'll check it out. > > The templates are in Norwegian though. Internationalization is planned > > for ZTM 2.6. > > By pity my English is bad, and my Norwegian is nothing ... and I can't find > any english-norweegian dictionary. I think I'm going to wait 2.6 version ! > Any idea for the release date ? I'm really impatient :-) Well, no promises beyond "when its done". :-) Hopefully we wlll find time to complete this within the next three months. I'll post to ztm-devel once the TMS is i18n-ified. My plan is to cut a second beta this weekend, and at the same time branch off 2.5. After this the CVS trunk will be open for surgery. 2.5 is done minus one feature that I just need to check in. the beta period is just to get some of the other developers to test it. (HINT HINT @ Stian, Andreas & Tom :-) ) The primary goal for 2.6 is internationalization and unicode support, so I will try to get that done early before we add any features. We might even resist adding features in 2.6 if this doesn't take too long time. If were lucky you may have something to play with by the end of the month, but I am notorious at missing open-source deadlines so don't count on it. :-) > PS : Do you plan to write a How To like "Hello World for ZTM" ? Something > which easely allow to create basic topic, association, role and occurrence > types ... and some topics Yes. We have created some simple view-templates (that may be used by visitors). The text on the frontpage will describe how to set up a simple topicmap with topictypes for persons, organizations, articles and files in your browser. (Topic Map based images is supported by a different component that I will check in once I've had time to fix a few remaining issues.) It will be based on the edit form of the topicmap which lets you easily construct basic ontologies. -- Arnar -- Arnar Lundesgaard | Konsulent Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Arnar L. <arn...@bo...> - 2004-08-03 16:01:57
|
On Tuesday 03 August 2004 17:41, Bernard Chabot wrote: > Well, I was able to create 2 topic types under '[portal]/system/topictypes' > ... and to set them as "Topictype" ... > ... and I see them now in the "Available topic types in topicmap:" > ... and able to instanciate them ! Great. > I have also create 1 association type and 2 role types ! > > When I create a topic (I can't find any folder for for the simple topic ?!) We just stick them wherever we like inside the portal. Just create your own folder-hiearchy. When you "instanciate" the topic types, what you are really doing is creating entries in the portal_types component. Since you are apparently not using the TMS (ztmdefault) method of adding new portal types, you need to be certain that the type-system allow you to add the new types to folders. (You can do this in portal_types, or let the TMS do it for you.) > ... I've got this following text when I try to give it a type : > > => the search only say [topic] instead of the <nameOftheTopic> Well, you haven't given your topics any basenames, or the basename is empty. Try editing the basename. I guess it should be extended to fall back on the topics zope-id if no basename can be found. > I also have different icon for topic for different type ... > ... and some error when I whan to "edit" the topic > See after : > > ============== > Site Error > An error was encountered while publishing this resource. > > Debugging Notice > > Zope has encountered a problem publishing your object. > Cannot locate object at: > http://localhost:8080/test/system/bernard/content_edit_form This looks like a bug, though I am not exactly sure where it comes from. We rarely use the system withouth the TMS, which is where 'content_edit_form' comes from. You can fix it in the portal_types component if you do not wish to install the TMS components yet. Simply replace all occurrences of content_edit_form with ztmtopic_edit_form. > It's true, it's a kind difficult without documentation ... > ... hope you could translate your "HowTo" soon :-) Indeed, as it stands now you still need to know CMF quite well. The TMS templates makes all this a bit easier though, so I recommend that you try to install the "Topic Management Tools" if you haven't yet. The templates are in Norwegian though. Internationalization is planned for ZTM 2.6. -- Arnar -- Arnar Lundesgaard | Konsulent Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Arnar L. <arn...@bo...> - 2004-08-03 14:12:17
|
On Tuesday 03 August 2004 15:59, you wrote: > Hello Arnar, > > Fine. Thanks for your tips. It works fine now ! > But I can see any topic type under the section "Available topic types in > topicmap:" ... > ... even if I use the "Update all" button !! > > Is it normal, or may I create my self some topic type (and where) before ? Yes. The available types list is populated by instances of a special topic called topictype. I think you can find it under '[portal]/system/topictypes'. You need to a create a topic that is an instance of of this topic. The new topic type can be created anywhere, but I would suggest '[portal]/system/topictypes' simply as a place to collect them all. When you have created the topic, just use quick-select in the Topic Edit (ztmtopic_edit_form) to add the type. (If you install the portal_topicmanagement tool, you should already have 'File' as a topic-type IIRC.) Unfortunately the documentation is somewhat lacking and what we have written is in Norwegian. We have started writing a default frontpage that will explain how to proceed with building a ZTM site, but no ETA yet. We ought to set up a Wiki somewhere to document these things, but let's do it on this list for now. -- Arnar -- Arnar Lundesgaard | Konsulent Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Arnar L. <arn...@bo...> - 2004-08-03 13:03:22
|
On Tuesday 03 August 2004 13:17, Bernard Chabot wrote: > Hello Arnard, > > I have installed the last version of ZTM (ZTM-2.5-Beta1-no_NO) on my > computer (windows XP) Wohoo! :-) Beware that the no_NO part means that a lot of the templates in the TMS=20 (ZTMDefault) are in Norwegian. You should be able to understand their purpo= se=20 though, and the core templates for the engine are in English. (I've fixed a couple of bugs since Beta 1, and I'm planning on releasing Be= ta=20 2 this weekend.) > I have also installed python 2.3.4 and Py XML 0.8.3 for python 2.3 > But have got this message when I go to the portal_topicmaps page of my > portal > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > It appears that Python's XML package. is not installed on this machine, at > least not a correct version or one that can be reached from ZTM's current > runtime environment The PyXML package is required in order to import XML > TopicMaps. > > You can still use ZTM without any other reduced functionality, but the > setup routine below will only create some folders. > > Language =A0English Norsk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Is there any special thing to do ? Setting a variable for exemple ? Yes, you need to make PyXML available to the version of Python that Zope us= es.=20 I believe you can find the path to the version in Zope's Control Panel. IIRC, the binary version that comes with Zope is usually installed under '\bin' in Zope's SOFTWARE_HOME variable which is probably something like "C:\Program files\Zope-2.7." So Zope does probably not use the Python version you downloaded from=20 python.org. PyXML looks in the windows registry for Python versions where it can instal= l=20 itself. Unfortunately, the binary python version that comes with Zope is no= t=20 added to the windows registry. If you check the folder where you installed Python (probably C:\Python23), = you=20 will find a folder named _xmlplus under C:\Python23\Libs\site-packages or=20 similar. You need to copy this _xmlplus folder and all its content into Zope's=20 site-packages folder. Most likely: =A0 =A0 "C:\Program files\Zope-2.7\bin\Lib\site-packages\" Then you need to restart Zope. (Drop by #ztm on irc://irc.freenode.net to chat with me directly if this=20 doesn't work.) =A0 -- Arnar =2D-=20 =A0Arnar Lundesgaard =A0| =A0Konsulent=20 Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo=20 Tlf. +47 23 40 60 00/61 22 =A0| =A0Faks: +47 23 40 60 01 =A0| =A0Mob: +47 9= 8 23 80 36=20 http://www.bouvet.no =A0| =A0a...@bo...=20 |
|
From: Arnar L. <arn...@bo...> - 2004-07-24 23:11:11
|
Hi, I have just uploaded ZTM 2.5 beta 1. (Finally!!) This should be a fairly stable release and already in production. I've made some changes to the setup code recently so there may be issues but I believe I have tested everything. ZTM is now feature-complete for the 2.5 version. Hopefully we will go gold sometime in the next forthnight, but that depends on the amount of testing and feedback we receive. One issue with this release is that the templates in the topicmanagement-layer are all hardcoded in Norwegian and not internationalized. This will unfortunately not be fixed until ZTM 2.6. Please try it out and give us some feedback. It should be very easy to set up by now. -- Arnar -- Arnar Lundesgaard | Consultant Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Fax: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: <ben...@id...> - 2004-05-25 08:29:48
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Arnar L. <arn...@bo...> - 2004-05-13 10:48:02
|
On Thursday 13 May 2004 05:15, you wrote: > Hello Arnar, > > I saw your posting in sourceforge ztm-devel=A0on the status of ZTM on 18 > march and was wondering if you are close to another release yet? Yes we are. The current CVS is stable, and will be in production on two portals shortly. It is still somewhat fickle to install, so some minor work on finnishing th= e=20 installation and setup routines remains. Then there will be another beta, and finally a release with some=20 documentation. Right now I am in the final phase of a long-running project, so early June = is=20 the current target. One issue with the upcomming release is that it targets the Norwegian marke= t.=20 Some of the templates in the ZTMDefault module need to be translated into=20 English. Another company has volunteered to internationalize ZTMDefault, bu= t=20 this will not be part of the 2.5 release. We haven't decided how to handle this yet, but there will perhaps be an=20 internationalized 2.5 at a later date. -- Arnar =2D-=20 Arnar Lundesgaard | Consultant Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo=20 Tlf. +47 23 40 60 00/61 22 | Fax: +47 23 40 60 01 | Mob: +47 98 23 80 3= 6=20 http://www.bouvet.no | arn...@bo...=20 |
|
From: Arnar L. <arn...@on...> - 2004-05-12 00:59:28
|
[I'm a bit tired now (02:47 here) so I hope that this mail doesn't miss the mark too much. Please drop by #topicmaps on irc.freenode.net if you wish to discuss this in any more details.] On Monday 10 May 2004 17:17, Dylan Jay wrote: > If I win this tender then I would work on this integration as it will be > needed for the project but given my company is new-to-non-existant I'm > wouldn't be in a position to sponsor others unfortunatly. That is ok, any help is appreciated. > > We've been slowly refactoring ZTM into two products. ZTM2 is the core > > topic map engine, and ZTMDefault is our content management product. > > > > The basic idea would be that Plone replaces ZTMDefault. A new product > > called ZTMForPlone (or PloneForZTM ;-) ) would integrate the to codebases. > > > > The key area of integration is likely top be differences between > > Archetypes and ZTM. Without having studied it I would guess that having > > ZTM as a form of AT storage would be a sensible approach. > > This confuses me even more. I apologize. I did not take the time to write down a good answer, and assumed that this was a technically inclined question. ZTM is difficult to describe, because portals using it can be modelled every way the topic map can be. They can also vary wildly depending on the customers requirements. While there are no canonical ZTM portals, the ones we have built so far share many common traits. > I think the problem is I that I don't really understand what functionality > ZTM has (I'm barely coming to grips with topic maps itself). The core concept of ZTM is to use content management techniques to administer ontologies and knowledgebases. This way we try to make it possible for the common user to capture rich knowledgestructures in a tool they can relate to. This is done by making the topics themselves the content, and not some meta-navigation-framework. We try to design our portals so that the user through immediate visual feedback will be encouraged to explore the possibilites afforded by using rich structures like topic maps. Hopefully they will in time introduce new relationships and content types by themselves. In the current ZTM implementation there is one topicmap per CMF-portal. This is a restriction that could be lifted, but we have not needed this so far. You talk alot about multiple topic maps that are supposed to co-exist and be merged in your email. We have choosen to have one topicmap, where all topic map elements are implemented as CMF content-types. This way you can publish topics, associations, names etc... They key here is that all topicmap items can be administered by a workflow. > What I'm going to do is write out a whole lot of use-cases of what I think > ZTM could be or at least what Plone+TopicMaps could be. This will make it > easier for us to discuss as people can just point out where ZTM differs from > what I'm imagining. > > Publishing a new document > ------------------------------- In ZTM when you create new content, you create a topic object that is given a topic type (another topic) based on the type of content you wanted to create. The topic type works as a blueprint for what occurrences the new content will have, and what relations it should have to content of other types. The data on the topic type is part of the ontology for the knowledgebase of the portal, and is used to dynamically generate forms where the user enters text and other values for the content. These data are stored in data-occurrences on the topic. Most content is related to other content in some way, so the same template contains forms for easily creating associations between topics. A common example is that most articles have an author, so the editing form will have a field for creating associations between the article and topics of type person. Every topic will have different views. One view for editing, one view for previewing, another for visitors, yet more for various collapsed forms. Navigating the topicmap can be thought of as a fisheye view. You most of the time focus on a single topic, but in this view (depending on the templates) may display nearby topics or perform wide searches. If the user is not authorized to publish content on the site, s/he will have to send the topic to approval. This works the same way as workflow in Plone, where unpublished content is available to priveledged users. > At the moment publishing content is about submitting the content and > metadata together. I was thinking publishing with TM could be a two step > process. > 1. User creates content objects and enters in all the content > 2. User submits content for publishing. > 3. User creates mini-topicmap object. (possibly via a document action) > 4. User edits new topicmap adding occurrences which point to the new > content. The UI is orientated to adding occurrences to the new document but > doesn't prohibit adding new topics, new types, and occurrences to other > documents. Basically this mini-topicmap represents a bunch of changes to > the much larger overall topicmap and could be relating one or many > documents into the "overall scheme". In addition existing topics can be > found and somehow used. These have their unique id recorded so there is no > problem with merging later on. > 5. User submits the topicmap. > 6. Reviewer will review the content > 7. Reviewer will allow it to be published. Since no occurrences exist for > this document this step doesn't mean much as the document won't be linked > into any navigation or topic searching at all > 8. Reviewer will review the mini-topicmap. They will check the quality of > all the additions of topic, occurrences etc. > 9 TM is accepted and published. Doing so merges the TM into overall TM and > thus dynamic navigation and TM searches will include the new topics and > occurrences and thus link the document into the website. (I don't know if > this merging would take the form of physical merging of the miniTM object > into a global TM object or rather magic indexes glue the miniTM into a > large TM-network which overall constitutes the global TM. I prefer the idea > of the later option as it is more consistent with a distributed approach > and allows different contributions to be taken down easily if need be) In ZTM there is one topicmap, where the different topicmap elements > User browses to document > ------------------------------ There is no "omnigator" or similar metaphors in use here. When a visitor (anonymous user) browses the sites s/he navigates from topic to topic. A topic is represented as a HTML page most of the time, with links to other related content. The related content can be predefined searches, directly or indirectly related content, found via inferencing, external feeds, manually configured lists etc... A hyperlink can in many instances be though of as following an association. The templates are specially designed for each customer and for each individual content type. Most pages are fairly similar though and we re-use many interaction-design/usability patterns. All our customers want a unique graphical look'n'feel (a brand if you like), so this is a way to make each site unique. An import point to remember is that users aren't really interested in the topic map per se, they want to find something. The information in the topic map is simply used to help them find it in various ways. Documents that are located outside the portal are represented by a topic with a Subject Locator. This topic then represents the resource, but can still be part of workflow and reused by other topic map content. > 5. User clicks on a related document. (What is shown for breadcrumbs now?) For most of our portals we have chosen other patterns for showing position than breadcrumbs. > Administrator connects Topic (or type hierarchy) to portal > -------------------------------------------- We have templates for maintaining the ontology. > Facet filtering (this prob has another name) > ---------------- We use the term facet maps. Se http://facetmaps.com for examples. > Topic maps can handle faceted classification I think so facet filtering > type interface should be offered somehow (eg like dealtime.co.uk). We have not yet built anything like this in ZTM, but we have done so in a topic map portal built using Ontopias Knowledge Suite. > 1. Admin creates ordered list of types which they consider orthogonal. > (Perhaps admin has some control over what is considered the top of the type > hierarchies and how much of the hierarchy is selected). This is contained > in another tool perhaps, or maybe someobject is created which represents > the search form. There could be a need to make many forms each > corresponding to a different topic like in dealtime. Perhaps there is some > mechanism to override the display of a topic navigator for a particular > topic such that you could say, "use this facet filtering form when > displaying this topic" or "display topic as just an occurrence list" or > "display topic as just subtopics following type X with other related topics > on the side"? 2. User enters this form and is presented with dropdowns or > other widgets to select topics from each type hierarchy. A list of > occurrences is shown sorted by something or rather. We choose what to display by building templates. For an earlier version of ZTM we constructed a solution where one could construct pages TTW, but we found it to be restrictive. > 3. User picks one or two topics and hits search. A filtered list of > occurrences are available. Further topics can be selected and the list > further filtered. Some mechanism list breadcrumbs can show what has already > been selected and allow the user to revise that choice. Our topics often do not contain many occurrences, so this approach has not been required by us. It is definately possible to implement in ZTM. > Searching > ----------- > Offer the choice of topic search, document search or topic and document > search? ZTM does not currently have a topicmap query-language. We use pluggable indexes in ZCatalog to search both topic maps and documents at the same time. > Offer advanced screen which is similar to Facet filtering except that > results don't include further facet selections We have not written any forms for faceted search. > Glossary/thesaurus > ---------- > User can browse search a big list of all the topics with a summary of > related topics under each. Clicking on a topic displays the topic > navigator. Yes. We use this pattern a lot. > Architecture > ------------- > - As I see it archetypes don't really come into any of this. Occurrences > use links. These links could use the AT reference machinery to overcome > broken links but I don't see there is much gain. Using a TM should mean you > can control all navigation without moving the content so there should not > be need to move it. Occurrences can be both URIs and inline data. I merely illustradet the issues with archetypes because you asked about a possible Plone integration. I assumed that the reason you wished to integrate with Plone was to use it's extensive infrastructure and other products. > - Content objects don't need to be touched in the slightest. Perhaps the > only thing that would be needed is a document action to create a miniTM > with that document as the initial context. > > - I think the idea of lots of miniTM being glue via an index into the > overall TM is a good idea but not sure how it would work in practice. In ZTM the content is most of the time part of the topic map. (It's kind of addictive, if we can't have it in the topic map we want it to be managed by it.) There should not be a problem with this approach. We use it for uploaded files and images, but there is almost always a topic representing the resource not just a link. > - I see somekind of view objects being created which represent search forms > and thesauri etc but I'm not sure where they should live - content space, > inside a tool, or inside a skin? Skins would be nice since it would be nice > to have different views for different people or groups. However that isn't > the kind of stuff that lives in skins now. (I think this is a bad feature > of plone however since it would be nice to customize actions, navigation > etc at a skin level. but I digress). We currently use CMF skins extensively. While we choose to stay close to CMF, there are no technical obstacles to implementing a different view/template framework. We have sketched frameworks where the templates to a larger degree is rendered from topicmap content. > So perhaps someone could point out where ZTM or other endevours differ and > then I might have a better idea of how much work I have to do. It depends on what your ambitions are. ZTM is a requires a bit of Zope/CMF Zen and topic map TAO to grok. We are working to make it easier to set up and use, but this is a long process and not an endstate. I belive that seeing a ZTM portal in action might be the best way of understanding. It is not complex, but there is a lot of Zope and content-management infrastructure that obscures the view. ZTM is also currently a bit rough and targeted at the Norwegian marked. This will remain true for ZTM 2.5 when finnished, but we are hoping to work on internationalization for ZTM 2.6. Thank you for your interest in ZTM. -- Arnar |
|
From: Dylan J. <me...@dy...> - 2004-05-10 15:17:54
|
----- Original Message ----- From: "Arnar Lundesgaard" <arn...@bo...> To: <ztm...@li...> Sent: Monday, May 10, 2004 8:03 PM Subject: Re: [Ztm-devel] ZTM Plone integration > On Monday 10 May 2004 04:19, Dylan Jay wrote: > > I'm submitting a tender based on Plone for a CMS for a regional heath > > authority here in Australia. I think that ZTM is what I'm looking for to > > enable Plone to be useful in managing 7000+ docuuments. In order to submit > > the tender I really need to know how possible this kind of integergration > > is, how much work I would need to do and what plans there already are from > > such work. > > There are no plans that I am aware of at this moment. There has been quite a > bit of interest and questions from several parties around the world, but no > one has stepped up to sponsor it or assist in the implementation. If I win this tender then I would work on this integration as it will be needed for the project but given my company is new-to-non-existant I'm wouldn't be in a position to sponsor others unfortunatly. > > What is would ZTM-Plone integration actually look like? > > We've been slowly refactoring ZTM into two products. ZTM2 is the core topic > map engine, and ZTMDefault is our content management product. > > The basic idea would be that Plone replaces ZTMDefault. A new product called > ZTMForPlone (or PloneForZTM ;-) ) would integrate the to codebases. > > The key area of integration is likely top be differences between Archetypes > and ZTM. Without having studied it I would guess that having ZTM as a form of > AT storage would be a sensible approach. This confuses me even more. I think the problem is I that I don't really understand what functionality ZTM has (I'm barely coming to grips with topic maps itself). What I'm going to do is write out a whole lot of use-cases of what I think ZTM could be or at least what Plone+TopicMaps could be. This will make it easier for us to discuss as people can just point out where ZTM differs from what I'm imagining. Publishing a new document ------------------------------- At the moment publishing content is about submitting the content and metadata together. I was thinking publishing with TM could be a two step process. 1. User creates content objects and enters in all the content 2. User submits content for publishing. 3. User creates mini-topicmap object. (possibly via a document action) 4. User edits new topicmap adding occurrences which point to the new content. The UI is orientated to adding occurrences to the new document but doesn't prohibit adding new topics, new types, and occurrences to other documents. Basically this mini-topicmap represents a bunch of changes to the much larger overall topicmap and could be relating one or many documents into the "overall scheme". In addition existing topics can be found and somehow used. These have their unique id recorded so there is no problem with merging later on. 5. User submits the topicmap. 6. Reviewer will review the content 7. Reviewer will allow it to be published. Since no occurrences exist for this document this step doesn't mean much as the document won't be linked into any navigation or topic searching at all 8. Reviewer will review the mini-topicmap. They will check the quality of all the additions of topic, occurrences etc. 9 TM is accepted and published. Doing so merges the TM into overall TM and thus dynamic navigation and TM searches will include the new topics and occurrences and thus link the document into the website. (I don't know if this merging would take the form of physical merging of the miniTM object into a global TM object or rather magic indexes glue the miniTM into a large TM-network which overall constitutes the global TM. I prefer the idea of the later option as it is more consistent with a distributed approach and allows different contributions to be taken down easily if need be) User browses to document ------------------------------ 1. User clicks on navigation tree item or global action (what happens once the a topic is opened? Is it's children all of a predefined relation type?) 2. Topic map navigator is displayed. This would be something like Omnigator where occurrences are shown along with related subjects. (Perhaps portlets can play a part in this so administrators can use portlet control to control the topic navigation display) 3. User clicks on further topic. (Not sure what the bread crumbs should show here. Either some kind of browsing history or some kind of path following the type that was browsed along. Certainly shouldn't show physical structure at all). 4. User eventually gets to document. A "what's related" portlet would show various related documents and topics under headings defined by the types perhaps. (not sure how administrators would control the ordering or filtering of this. Perhaps some global ordering of which are the important types.) (What is shown for breadcrumbs now?) 5. User clicks on a related document. (What is shown for breadcrumbs now?) Administrator connects Topic (or type hierarchy) to portal -------------------------------------------- Actions would just be urls to the topics I suppose. Navigation portlet could be replaced by somekind of topic portlet which is an ordered list of initial topics (or even types), or alternatively navigation portlet could be used as is with some kind of special link object which links into a topic in the topic map. Facet filtering (this prob has another name) ---------------- Topic maps can handle faceted classification I think so facet filtering type interface should be offered somehow (eg like dealtime.co.uk). 1. Admin creates ordered list of types which they consider orthogonal. (Perhaps admin has some control over what is considered the top of the type hierarchies and how much of the hierarchy is selected). This is contained in another tool perhaps, or maybe someobject is created which represents the search form. There could be a need to make many forms each corresponding to a different topic like in dealtime. Perhaps there is some mechanism to override the display of a topic navigator for a particular topic such that you could say, "use this facet filtering form when displaying this topic" or "display topic as just an occurrence list" or "display topic as just subtopics following type X with other related topics on the side"? 2. User enters this form and is presented with dropdowns or other widgets to select topics from each type hierarchy. A list of occurrences is shown sorted by something or rather. 3. User picks one or two topics and hits search. A filtered list of occurrences are available. Further topics can be selected and the list further filtered. Some mechanism list breadcrumbs can show what has already been selected and allow the user to revise that choice. Searching ----------- Offer the choice of topic search, document search or topic and document search? Offer advanced screen which is similar to Facet filtering except that results don't include further facet selections Glossary/thesaurus ---------- User can browse search a big list of all the topics with a summary of related topics under each. Clicking on a topic displays the topic navigator. Architecture ------------- - As I see it archetypes don't really come into any of this. Occurrences use links. These links could use the AT reference machinery to overcome broken links but I don't see there is much gain. Using a TM should mean you can control all navigation without moving the content so there should not be need to move it. - Content objects don't need to be touched in the slightest. Perhaps the only thing that would be needed is a document action to create a miniTM with that document as the initial context. - I think the idea of lots of miniTM being glue via an index into the overall TM is a good idea but not sure how it would work in practice. - I see somekind of view objects being created which represent search forms and thesauri etc but I'm not sure where they should live - content space, inside a tool, or inside a skin? Skins would be nice since it would be nice to have different views for different people or groups. However that isn't the kind of stuff that lives in skins now. (I think this is a bad feature of plone however since it would be nice to customize actions, navigation etc at a skin level. but I digress). So perhaps someone could point out where ZTM or other endevours differ and then I might have a better idea of how much work I have to do. Dylan Jay --- http://www.meetmemap.com - makes giving directions easy http://www.pretaweb.com - Update-it-yourself, low cost websites http://www.eatmanifesto.com - against all dumbing down of food http://www.subjectivise.com/StockPhotography |
|
From: Arnar L. <arn...@bo...> - 2004-05-10 09:57:05
|
On Monday 10 May 2004 04:19, Dylan Jay wrote: > I'm submitting a tender based on Plone for a CMS for a regional heath > authority here in Australia. I think that ZTM is what I'm looking for to > enable Plone to be useful in managing 7000+ docuuments. In order to submit > the tender I really need to know how possible this kind of integergration > is, how much work I would need to do and what plans there already are from > such work. There are no plans that I am aware of at this moment. There has been quite a bit of interest and questions from several parties around the world, but no one has stepped up to sponsor it or assist in the implementation. This may be because ZTM 2.5 hasn't been finalized yet, though it should be very shortly. Our current goal is early in June, but it depends on actual work. One issue for ZTM 2.5 is that we had to reduce scope to target the Norwegian market. This is because many of the templates in the ZTMDefault product are written in Norwegian. All templates in ZTM2, the core engine, are written in English (IIRC). There are currently plans to internationalize ZTMDefault (by a different company than mine), but that will not be part of 2.5. > What is would ZTM-Plone integration actually look like? We've been slowly refactoring ZTM into two products. ZTM2 is the core topic map engine, and ZTMDefault is our content management product. The basic idea would be that Plone replaces ZTMDefault. A new product called ZTMForPlone (or PloneForZTM ;-) ) would integrate the to codebases. The key area of integration is likely top be differences between Archetypes and ZTM. Without having studied it I would guess that having ZTM as a form of AT storage would be a sensible approach. > Having not yet been able to get ZTM to work Sorry about that, the current CVS HEAD is having some final surgery before the freeze. It is just minor changes and fixes, but when one doesn't know the product.... :-( > I'd also very much like to see some use-case that describe how it works. All current ZTM installations are to varying degrees information portals that use ZTM as a CMS. Unfortunately most of what we written is in Norwegian. I don't have time right now to dig up what we have written in English, so I will have to get back to you later. > As part of this tender I also have to list reference sites that have used > the technology I propose in a similar way. I am very interested in finding > out how similar some of the existing ZTM installations are? I will try to compare these portals in a later mail. -- Arnar -- Arnar Lundesgaard | Consultant Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Fax: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Dylan J. <me...@dy...> - 2004-05-10 02:20:05
|
I'm submitting a tender based on Plone for a CMS for a regional heath authority here in Australia. I think that ZTM is what I'm looking for to enable Plone to be useful in managing 7000+ docuuments. In order to submit the tender I really need to know how possible this kind of integergration is, how much work I would need to do and what plans there already are from such work. What is would ZTM-Plone integration actually look like? Having not yet been able to get ZTM to work I'd also very much like to see some use-case that describe how it works. As part of this tender I also have to list reference sites that have used the technology I propose in a similar way. I am very interested in finding out how similar some of the existing ZTM installations are? Dylan Jay --- http://www.meetmemap.com - makes giving directions easy http://www.pretaweb.com - Update-it-yourself, low cost websites http://www.eatmanifesto.com - against all dumbing down of food http://www.subjectivise.com/StockPhotography |
|
From: Arnar L. <arn...@bo...> - 2004-03-18 16:23:35
|
Hi, ZTM is quite stable and improving rapidly. We've integrated all the features we wanted from the different branches into the sf.net CVS. We've made it faster, and a lot simpler to configure and develop with. I'm hoping to package another alpha sometime next week. It will hopefully be the last one. Going forward, these are the tasks that I'd like to finnish before we enter a feature freeze for ZTM 2.5. (I'm not sure all of them are worth doing, but if we don't do them before 2.5, it might be hard to do them later when we need to make an upgrade path.) 1. Change tm_serial from strings to integers. 2. Rename the ZTM2 module to ZTMCore. 3. All Topic Map objects registered with the Topic Map they belong to. 4. Interfaces that document ZTMCore. 5. All templates should be UTF8, and we should only use unicode internally 6. Move the SearchableText, Templates and Editing methods out of the core. Once we enter the feature freeze, we need to write documentation for how to install, configure and develop on ZTM. -- ZTMDefault still needs work on the templates. We especially need internationalization (i18n), but this is not as important for ZTMCore. 1. All templates should be i18ned. (using PlacelessTranslationService) 2. All templates should be rewritten in ZPT (Already started) 3. Optimize and tighten the skin, and choose some simpler colours. It's hard to give an ETA on when these things could be finnished, especially since I'd like the HEAD branch to be stable for a little while forward. I'll probably do the refactorings in a CVS branch. This is of course subject to change, and feedback is welcome. -- Arnar -- Arnar Lundesgaard | Consultant Bouvet AS, Sandakerveien 24C D11, PB 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Fax: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Arnar L. <arn...@bo...> - 2004-02-26 12:50:20
|
On Tuesday 24 February 2004 12:41, Andreas Johnsen wrote: > I tried - and succeeded to install ZTMCore-2.5a1 on Windows XP. But to > make the installation procedure less cumbersome (at least for us Windows > users) I have the following requests for enhancements: Great, I'll follow up on these in CVS. > 1. All text files (e.g. Readme, Install,...) should have .txt extensions Done, except COPYING which is the GPL licence. Most Python packages do not use a .txt ending, but as long as were internally consistent... > 2. The newline character(s) is not compatible with Notepad. Get a real editor!! :-) I will see if it is possible to convert the files to windows \r\n fileending. > 3. I installed and used PyXML 0.8.3 from SourceForge with no problems > (except from problems with where to install it: > $SOFTWARE_HOME/lib/python/xml I have added some extra text, but we will likely move from PyXML to libxml in the near future. The two reasons are performance (libxml is very fast) and RelaxNG validation. (XTM1.1 is going to be based on RelaxNG). I have also hinted at the issue where PyXML picks up the wrong python installation. > 4. The BTreeFolder2 product has to be installed. Yes, that's what it says in README.txt. I have added a test for BTreeFolder2 during Zope initialization, and written an extra step in doc/INSTALL.txt > 5. It may be very elementary, but a step is missing between step 4 and > 5; Step 4.5 Start/restart Zope. Added in CVS. > 6. In step 7 the "setup tab" should be changed to "install tab". Fixed in CVS > 7. The topic_icon.gif is broken. This is a dependency on ZTMDefault... Not sure how we're gonna fix it, except with another monkeypatch. :-( > 8. I managed to create new topic types, but when I tried "Update all" in > the [my portal]/portal_topicmaps I got an error: "Error Type: > AttributeError > Error Value: 'str' object has no attribute 'getBaseName'" This is > probably due to the missing HOWTOs? Nope, that's a bug that has been fixed in CVS. -- Arnar -- Arnar Lundesgaard | Konsulent Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Andreas J. <and...@bo...> - 2004-02-24 12:42:18
|
I tried - and succeeded to install ZTMCore-2.5a1 on Windows XP. But to make the installation procedure less cumbersome (at least for us Windows users) I have the following requests for enhancements: =20 1. All text files (e.g. Readme, Install,...) should have .txt extensions =20 2. The newline character(s) is not compatible with Notepad. =20 3. I installed and used PyXML 0.8.3 from SourceForge with no problems (except from problems with where to install it: $SOFTWARE_HOME/lib/python/xml=20 =20 4. The BTreeFolder2 product has to be installed. 5. It may be very elementary, but a step is missing between step 4 and 5; Step 4.5 Start/restart Zope. 6. In step 7 the "setup tab" should be changed to "install tab". 7. The topic_icon.gif is broken. 8. I managed to create new topic types, but when I tried "Update all" in the [my portal]/portal_topicmaps I got an error: "Error Type: AttributeError Error Value: 'str' object has no attribute 'getBaseName'" This is probably due to the missing HOWTOs? =20 BR, Andreas |
|
From: Arnar L. <arn...@bo...> - 2004-02-04 07:59:42
|
Hi, this email is the first ZTM change proposal. Change proposals will be = part of our ongoing work to open up the development process and improve the = quality of our methods. It is inspired by zope.org's fishbowl process, and will = hopefully improve the quality of the ZTM codebase by forcing us to consider = changes more thoroughly. The process may be somewhat heavy, but the scope of the intended = proposals should be of a size that they should be carefully considered. This means that we still need a method for suggesting/contributing minor improvements to templates and code. There are several things we are hoping to achieve with this process: 1. Feedback, discussions, opinions and improvements of proposals. =20 2. Documenting and describing larger changes and developments. =20 Hopefully these proposals will become well-documented a history of the architectural discussions and decisions of ZTM. 3. Generate interest in the future of the ZTM project. We need to formulate and communicate our visions of what ZTM is and = can become. 4. Assist development of a ZTM roadmap. 5. Display that ZTM is under development and maintainence. 6. Attract sponsorship of feature development. 7. Make it possible for new people to contribute =20 =20 Other parties are invited to write or request proposals for issues they = have=20 with ZTM. We will probably set up a WikiWikiWeb somewhere to serve as an incubator = for ideas like this one. -- Arnar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Proposal 1:=20 A specialized TypeInformation for topic types. Technical description: A TypeInformation (TI) is the kind of object that is created under the portal_types component and represent the various content types in the portal. If you visit the portal_types component in the Zope Management = Interface (ZMI), you will see that there are two standard TIs; Factory Type Information and Scriptable Type Information. These objects describe = how to create content objects, what templates they use, metadata etc..=20 You can see what they offer by studying existing TIs in your browser. Problem description: To introduce a new portal type, one currently creates a new topic and manually sets it as a instance of the topic 'topictype'. Next one = navigate to the portal_topicmaps tool and run the script that creates new TI = entries under portal_types based on topictypes from the topic map. =20 This process is fairly simple, and has improved the usability of ZTM enormously. It has also made us see ZTM as RAD tool, and having tasted = that we want more of it. =20 The problem is that portal types and TIs are disconnected from topic = types. When something changes in the topic maps system ontology, the TIs are = not updated. Since TIs partially represent the same concepts (subjects) as = the topic types, we should have one place to go to for changes. =20 This is especially noticable during development when one want often = want to change a type, rename a method, use different templates etc... =20 Secondly, portal_types contains configuration that is stored outside = of the topic map. This means that although Zope has builtin marshalling, it = cannot be exported and imported easily by an automatic setup. The format = (pickle) is propietary and not easy to keep under revision control. =20 Another issue is internationalization (i18n). The standard TI's have = some issues here. Topic Maps already contain a brilliant structure for = supporting different languages, and we want to use that. Suggested solution: We introduce a new TI called TopicTypeInformation (TTI). The = portal_topicmap tool is extended to monitor introduction, changes and deletion of = topic types, and manage the TTIs. =20 A TTI will have a direct reference to the topic type it represents, = and subscribe to relevant events. Title, Description, portal_type, constructor, templates and other configurables will be retrieved directly from the topic type. This way = we can support i18n by using scope. =20 The TTI will clean up any changes in the topictype in relation to the Content Management Framework (CMF), especially the portal_catalog. =20 =20 The advantage of automatically building portal_types will allow us to remove crufty setup code, and move us closer to the goal of supporting = throw-away-databases in our development process. The advantage being that configuration is moved into the topicmap which can and should be=20 put under revision management. =20 We have been annoyed by the need to configure and depend on objects = being available in the ZODB instance. We believe supporting "throw-away development" can improve the quality of our products and promote = reuse. =20 =20 Historically ZTM development has followed the OO approach. We were subclassing ZTopic for all kinds of content and introduced the "Innholdstype" concept on forbrukerportalen.no to avoid duplicating = code. =20 About 16 months ago Tom Bech and I discussed this annoyance, and we = realized that this limitation could be removed by properly using the = portal_types component. =20 This suggestion is an extension of that thinking and the fact that we = have seen it work so well for ITU and later projects. =20 =20 A smaller advantage is that Topics now always has the meta_type = 'Topic', and a portal_type that matches the topictype. This makes a lot of code = easier to write. =20 =20 Topics can now change types, or even have multiple types. (Not sure = how useful that is, roles might be a more correct way of modelling. Use = Cases wanted.)=20 =20 Risks: Why do we want to make it easy to create new content_types? Will this = not make it to easy to create imprecise content types that are not easy to correct? First of all it makes ZTM a RAD tool. Ideally a usability expert can = sit down with at web designer and build a website totally Through The = Web (TTW). There is a danger that content type overload can happen, but I think = that it is a good thing to have this opportunity. But more likely is that users will feel empowered by this and start = using a wider range of topic map features. We now also have the posibillity to let contributor suggest new = content types, new association types, new roletypes, new occurrencetypes = etc.. We think that will let implementors create better ontologies that = can more easily be adapt to changes by non-developers. By not subclassing ZTopic, we need to put code elsewhere. This means = that certain components need to be more complex and need more = infrastructure. This is a job we have already started and it is mainly a refactoring = job. I think it also avoids a lot of code redundancy. These changes mean that we will have to rethink the way we handle = templates, but that will be a proposal of its own. Certain operations in large topicmaps may need to change large = portions of the database. This may surprise users, and can lead to usability = issues. One doesn't change the system ontology that often in production, and = this will usually be done by users that know the system. =20 The main issue here is catalog-updates and that can be mitigated. It requires us to hook into the internal ZCatalog datastructures which is not exactly a maintainable thing to do. We don't want to go beneath the ZCatalog API, but if there is no = other way... (We already do a bit of this.) Thoughts, comments? -- Arnar |
|
From: Arnar L. <arn...@bo...> - 2004-02-02 21:32:10
|
> Bernard Chabot wrote: > > ... and I dont understand *where* I can change > > the <portalname>/system/topictypes/topictype > > to http://psi.emnekart.no/ztm/core/#topictype Stian Danenbarger replied: > There is no http://psi.emnekart.no yet, and for testing purposes you = might > consider ignoring this. However, if you REALLY want to play around = with > PSIs, let me know, and I'll send you an update on how to do it. I think you can safely ignore this issue in the alpha release. The new = (unfinnished) import/export code imports the Subject Indicator = correctly. I have not updated the documentation accordingly. I have registered this in the tracker, and fixed it in CVS HEAD. This was my first OSS release ever, so I hope you'll cut me some slack. = :) -- Arnar |
|
From: Arnar L. <arn...@bo...> - 2004-02-02 13:58:09
|
Andreas just complained that he couldn't unpack the released .tar.bz2 file on MS Windows using "normal" applications. I have therefore uploaded a .zip version, which hopefully adresses this shortcoming. Future releases will be made in the following fileformats: 1. .tar.bz2 -- A bzip2 compressed tarball 2. .tar.gz -- A gzipped tarball 3. .zip -- A zipped directory I don't think we need to release self-extracting archives yet, but if there is a current need I am willing to consider it. (or give others upload permissions :-) ). -- Arnar -- Arnar Lundesgaard | Consultant Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Arnar L. <arn...@on...> - 2004-02-01 16:54:48
|
I just tagged, packaged and released ZTM2.
This is the first release from the ZTM project, and is a snapshot of the
current state of CVS. A lot of testing remains before we can go beta.
The goal is to make regular releases going forward, hopefully every two, three
weeks.
We also need to discuss what features should be added to ZTM 2.5 before we
branch and start a featurefreeze.
The following things are on my list for the core engine:
1. Convert parts of the API to use PSIs
The current API uses topic names, which is too brittle since we do
not honour the Topic Naming Constraint.
It should be possible to keep this backwards compatible.
The 'getTopicByName' is a potential performance killer in larger
topicmaps.
2. Singleton Locator and runtime merging
For historic reasons, merging is currently a weak point in ZTM. We
have deviced a potential architecture that will make ZTMs runtime
merging compliant with the TMDM.
I'll try to do a writeup on the architecture so we have something to
discuss.
3. ZMI frontend for editing the topicmap.
When we are developing we often switch between ZMI and the
ZTMDefault. Not a big problem given tabbed browsing, but it should be
improved.
4. Finnish the import/export code.
It is currently useable, but it needs work on merging and import.
I tried to import some of the XTMs from topicmaps.org, and while it
was imported correctly, the id's and positions were wrong.
5. Refactor the setup code.
The setup code needs some work, and should be moved out of the
portal_topicmaps tool.
Oh, and you need to start bugging me about writing changelogs. :-)
-- Arnar
|
|
From: Arnar L. <arn...@on...> - 2004-01-28 21:14:45
|
1. Install of the 'portal_topicmanagement' tool:
This currently requires that the "CMF BTree Folder" type is registered in
the portal_types component.
You can add this by navigating to portal_types in ZMI and adding a FTI. It
should be one of the first in the list.
ZTM will be updated to throw an error if CMF BTree Folder is not
available and autoinstall it in portal_types if it is available.
2. Folder-type needs the folderContents method
We have chosen to register actions slightly different than the standard CMF
setup, but the current setup tools does not set this up correctly.
Actions with the id folderContents must be added to "CMF BTree Folder" and
"Folder".
3. PSIs are not imported correctly with the current import code.
The current import methods are two years old, and have not been maintained.
We are currently rewriting XTM export/import. Untill that has been finnished
one must add the following PSI to /portal/system/topictypes/topictype:
http://psi.emnekart.no/ztm/core/#topictype
Autocreation of portal types in portal_topicmaps depends on the availability
of a topic with this PSI.
(This change was part of the attempt to ongoing update the ZTM API to be
less topicname-based.)
-- Arnar
|
|
From: Arnar L. <arn...@bo...> - 2004-01-27 17:49:17
|
I just imported ZTMDefault into CVS. ZTM2 is the topic map engine. ZTMDefault is the central part of the topic management skin. We still have some products like DisplayLists and Images to clean up and release. The code is fairly stable, although it might have some undocumented dependencies. I tested a setup with this version yesterday, so it should work OOTB. It will be further cleaned up as we progress with the reimplementation of forskning.no. Our current working goals for ZTMDefault is to make it easier to install, move some TTW editing code from ZTM2 and cleaning up the templates. -- Arnar -- Arnar Lundesgaard | Konsulent Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |
|
From: Arnar L. <arn...@bo...> - 2004-01-26 13:10:52
|
test -- Arnar Lundesgaard | Konsulent Bouvet AS, Sandakerveien 24C D11, Postboks 4430 Nydalen, N-0403 Oslo Tlf. +47 23 40 60 00/61 22 | Faks: +47 23 40 60 01 | Mob: +47 98 23 80 36 http://www.bouvet.no | arn...@bo... |