Re: [topicmaps-comment] multilingual thesaurus - language,scope ,and topic naming constraint

["Thomas B. Passin" <tpassin@comcast.net>]

[Lars Marius Garshol]
>
> * Lars Marius Garshol
>
> * Thomas B. Passin
> | It's easier for me to see this as a potential problem than to know
> | what to do about it.  Or maybe someone can explain why it is a
> | non-issue.  Perhaps it means only that the granularity of a topic
> | map is the whole map itself.  But who wants to have import giant
> | maps into their little one?
>
> You're making lots of usage assumptions here that I can't follow. I
> haven't yet seen this to be a problem, but I'm open to the possibility
> that there might be one. If you could explain what you think that is
> I'd like to hear it.
>
> | Perhaps we need a Rec analogous to xinclude, so we can import a
> | topic or a small set of topics without having to import an entire
> | map.
>
> Why?

Suppose I have a web site (or it could be a processsor that would do
something further with the information).  I want to link to some information
in your topic map.  Perhaps I want to get information on how to cook a
goose, let us say. I don't want to view a representation of the information,
I want to do some more topic map processing on my system, connecting the new
information to information on geese that I already have. How can I do this?

1) I reference topic IDs in your map.
2) I import your whole map.
3) I extract part of your map with a topic map query language.
4) I extract a relevant fragment of your map

1) I may reference a topic in your map by its uri, but I can't do much with
that unless I can also reference all the other topics and associations in
your map the that given topic links to.  I also have to be able to retrieve
them if necessary.  We don't have a well-defined way to allow that.  Also,
your URIs may change if you merge other maps, so my links, if I could
establish them, may not continue to work.  So I cannot be sure I can update
my information from you.

2) I do not want to import your whole 100 MB map to get information just
about the cooking of geese, which may only amount to 30 KB, say.

3) This is probably the intended way of doing the task, but I'm concerned
that any such query would not return enough context information to make the
topics useful for me - that is, to merge into my map.  For example, a query
might return an association of a goose topic with cooking information, but
not about what classes the "goose" topic and association topic are.   If we
have removed the names from being children of the topics, as in PMTM4, we
may not even get the name of the "goose" topic unless we craft a more
complex query.

You may argue that I should examine the query results and query again for
any more information I need, but that could easily become a resource and
time-intensive recursive activity both for me and for your server.

4)  This would be where an xinclude-like ability would come in.  It's not
necessarily the same as an ordinary query, because it would include as much
context as necessary for the recipient to make proper use of the returned
information.

I welcome anything which can show me how this kind of operation will not in
fact incur serious difficulties of the kind I sketched out above.  Note that
none of this applies to the case where a person looks at some results in,
say, html format, such as in the Ontopia demo system.  It applies, rather,
to the case where I want to do something further in the way of topic map
processing.

Cheers,

Tom P