Re: [xtm-wg] lazy processing vs. extended XLink and BOS processing

["Steven R. Newcomb" <srn@techno.com>]

[Peter Jones:]
> I think our difference of opinion here concerns, how an arbitrary
> BOS is constructed, where it is constructed, who controls TM
> construction, and how you use/point at bits of it, and where the
> unresolved links fall depending on what you can see from where you
> are looking at it. (OK, that's a pretty long list I admit.)

> 1) How an arbitrary BOS is constructed:

> I think there's a discrepancy between the power of the server and
> the power of the user client here, which is where the gist of my
> drive on this point lies. If it is possible for the servers to hold
> "hyperdocument lookup tables for inverse relationships within
> arbitrary bounded object sets" for the whole of the WWWeb then
> that's fine by me.

I believe such a thing to be possible, and to be possible almost
immediately to the same extent that it is already possible for web
crawlers to provide navigation via keyword for "the whole of the
WWWeb".  The usual problems with network/server bottlenecks apply, and
the usual solution -- local cacheing -- also applies.

The whole idea of merging disparate topic maps would be impractical
without the underlying concept of merging hyperdocument groves
("hyperdocument lookup tables for inverse relationships within
arbitrary bounded object sets").  I think you're simply correct to be
concerned about the nuts and bolts of this merging process.

> 2) Who controls TM construction?

> There is a discrepancy between intranet knowledge management with
> controlled vocabularies in controlled (secure) environments and
> 'folks on the WWWeb' building their own TMs for their site
> resources. How do all these public TMs fit together to make a
> coherent lookup table across the WWWeb -- in the near future not
> light years off when there's World Peace, energy for free, etc.?
> You also cannot standardise topic construction or scope assignment
> (like restricting free speech); public TMs require gradual community
> development, like inventing a new language.

Yes and no.  At first, HTML didn't require gradual community
development; it required that a few people make a gift of it to the
world.  Only then, with HTML already at work, could the world adapt to
HTML enough to make HTML better adapted to the world's needs.  I think
the situation with topic maps is similar.  We have to complete the XTM
Spec in such a way that conforming TMs, as you put it, can "fit
together to make a coherent lookup table across the WWWeb".  That's
the way 13250 works, and there's no reason why the XTM Spec can't work
that way, too.  Contrary to what you say, I would argue that we can
and must standardize the syntax and semantics of topic maps, in order
to preserve the opportunities for merging.  What we *can't* do is to
standardize limitations on the semantics of topics.  (Nor does anybody in
Topicmaps.Org want to, as far as I can tell.)  We must also provide
for the development of communities around sets of topics, and the
development of sets of topics around communities.  13250 does that
with the notion of "public subjects", and so can the XTM Spec.

Ultimately, it's up to the XTM Spec to allocate control over the
construction of TMs.  We have to allocate some control to the XTM
Spec.  The rest of the control should be allocated to the authors of
TMs.  The result must be that any XTM-conforming TM is constrained to
be understandable as an XTM-conforming TM, and therefore is
constrained to be useful for all the purposes that we, who write the
XTM Spec, decide that all TMs must be useful for.

> [...] I was attack[ing] [...] what I see as
> being [a] definite problem.

I think that at some deep level, you and I agree about what the
problem is.  The solution I'm after will meet the following
criteria, among others:

* People who create and maintain topic maps can unambiguously specify
  the boundary between what's included in the topic map, and what's
  not included.  There are two aspects to this: (1) the topics (and
  the topic characteristics) that are included, and (2) the resources
  that are included.  Without such a perimeter specification, it will
  be impossible to tell whose world view we're navigating, and it will
  be impossible for topic map authors to express their world views
  unambiguously.  Of course, it is not required that any user or
  search engine service pay any particular attention to such perimeter
  information, but I believe it is required that the perimeter be
  unambiguously specifiable.  I personally believe that search engines
  that ignore it will necessarily offer less valuable services than
  those that pay attention to it and help end users apply this
  perimeter information intelligently.

* People who provide topic-maps-based web navigation services
  (services that today are usually and misleadingly called "search
  engines") can allow their users to aggregate user-selected topic
  maps to form arbitrary bases from which they can seek navigational
  assistance.  Yes, this will require that web crawlers produce new
  kinds of output, and for that output to be employed in new ways.
  Personally, I see those changes as a good and necessary side effect
  of the XTM Specification.  I don't foresee that all search engines
  will change overnight, and that's OK with me.  All we're trying to
  do with the XTM Spec, as I see it, is to open some doors beyond
  which there are new, more promising evolutionary spaces for the
  WWWeb to grow into, to increase its general usefulness, and to
  improve the productivity of humankind.

* People who use aggregated topic maps for navigational assistance on
  the Web can know whose un-aggregated topic map provided the
  navigational assistance for any given hop, and they can hide and/or
  draw special attention to available hops on any basis, including on
  the basis of which topic map(s) (and/or topic map author/providers)
  provided the information.  A topic map is merely an expression of
  the topic map author's opinion as to the structure of a bit of
  knowledge.  We need to make sure that users can tell whose opinions
  they're using, and how those opinions fit into the author's system
  of opinions, as that system is expressed in the author's topic map.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 359 8160
fax    +1 972 359 0270

405 Flagler Court
Allen, Texas 75013-2821 USA

------------------------------------------------------------------------
Add the interactive dimension to your web pages.
Use the MozquitoTM Factory with your editor and form the web today! 
Form the Web today - visit:
http://click.egroups.com/1/5771/4/_/337252/_/964110507/
------------------------------------------------------------------------

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com