RE: [Tm4j-developers] Drill-down topic maps

[Kal A. <ka...@te...>]

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 26 June 2001 08:19
> To: tm4...@li...
> Subject: Re: [Tm4j-developers] Drill-down topic maps
>
>
> On Mon, 25 Jun 2001 12:17:15 -0700
> Jack Park <jac...@th...> wrote:
>
>
> > But, what about an occurrence that happens to be stored in your local
> > persistent store?  How do you reference it?  Particularly, how do you
> > reference it such that others could, at a minimum, write and
> ask you for a
> > copy--given that you might have published the topic map on the
> web or sent
> > it off for merging elsewhere.
> >
> > Right now, I am using typed occurrences and I am willing to make my
> > persistentXTM implementation smart enough to check type before
> accessing an
> > occurrence.  Kal's interface suggestion looks interesting.  Can it be
> > viewed as a general enough solution that we could then generate
> PSI's for a
> > variety of occurrence types, turning an XTM engine into a kind
> of grove engine?
>
> We would need some lookup service that tells us which topicmaps
> are around
> there and what topics they 'export' for external use. The export
> set of topics
> could be managed via a scope, i.e. all topics in a special
> export-scope are
> available for external use. And we would need a protocol for topicmap
> engine communication, e.g. Soap.
>

For "topic map content types" this would work. For other content types,
resolving the locator would involve a different interpretation of the
fragment ID, and it would be nice to have some pluggable way of handling
occurrences of any type or locator notation (in the topic map) and of any
resource content type. However, I'm not sure that this is something which
should be addressed by TM4J - I would prefer to see the development of a
generic content addressing framework (such as a grove engine) as a separate
project and integrate TM4J with that. Does anyone know of such a thing ?

> Having said this, I would suggest the following interfaces:
>
> public interface TopicMapProviderFactory {
>     public TopicMapProvider createTopicMap( Properties );
> }
>
> public interface TopicMapProvider {
>     public TopicMap getTopicMap();
>     public String getURL();
> }
>
> These two interface are necessary to intergrate a topicmap into a system.
> With getTopicMap() I get the map handled by this provider. I'm not sure
> if we need getURL() since TopicMap already has a getBaseURL() method.
>
> public interface TopicMapManager {
>     public void initialise(Properties) throws TopicMapManagerException();
>     public TopicMap getTopicMap(String sourceURL);
>     public Collection getTopicMaps();
>     public registerProvider( String providerFactoryClassName,
> Properties );
> }
>
> The TopicMapManager manages all TopicMapProviders known by a system. The
> registerProvider() method adds a provider to the manager by using the
> given factory class.

This is a nice model, it would allow me to combine both in-memory
(file-based) topic maps and topic maps from a persistent store and from
other sources (perhaps a "RemoteTopicMap" implementation over SOAP !)

<snip!>
>
> What about that ?
>

I would be happy to go with this. I'm on the road at the moment but will be
back home in a couple of days and able to get something started on this.

Cheers,

Kal