Re: [Ztm-devel] ZTM Plone integration

[Arnar L. <arn...@on...>]

[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