RE: [xtm-wg] XTM Requirements (Was RE: Is this valid per HyTime? - topicmapmai l thread)

[Peter Jones <peterj@wrox.com>]

Hi,

I'm a bit concerned that my second and much more important point about the
coordinate attributes that Jack was suggesting got lost in the shadow of the
discussion of user interfaces, so I'm going to spell things out here.

>Won't having fixed coord numbers in a given map risk
>privileging certain views?

The point being: Coordinate systems are all about position. People and
groups frequently attach great importance both to position and control of
positioning. I worry that in allowing placeholders for values in a
coordinate system in our XTM documents, attaching those to topics
themselves, that we are introducing a doorway through which the Dogs of
Political and Wayward Vested Interests can slip.
For example:
Who will control the positioning of topics in the public infosphere?
Will a large vendor (who just happens to dominate the TM Browser market) be
able to financially and legally protect the assignment of their corporate
topic, Acme Inc., to (1, 1, 1)?
Will interest groups like the Creationists/Darwinists manage to gain control
over all topic maps relating to evolution to the disadvantage of other?
Likewise, could this also be a mechanism for censorship, topics that are
uncomfortable for certain regimes with appalling human rights records simply
being banished to infinity in those countries?

The technical work we are doing here might have very big implications for
the future.

End of Public Service Announcement.

best
Peter

-----Original Message-----
From: Wrightson, Ann [mailto:Ann.Wrightson@sweetandmaxwell.co.uk]
Sent: 29 June 2000 13:41
To: 'xtm-wg@egroups.com'
Subject: RE: [xtm-wg] XTM Requirements (Was RE: Is this valid per
HyTime? - topicmapmai l thread)


v. good point re user interface and size of topic map - I reckon that we'll
see a range of different interface metaphors (i.e. meaningful visual
structures with interactive behaviour in the GUI) being used as appropriate
with differently structured topic maps. 

Scopes and types, for instance, because they are so general, could be used
to represent various modelled-domain concepts which could/should be
represented in different ways.

Ann W.

-----Original Message-----
From: Peter Jones [mailto:peterj@wrox.com]
Sent: 29 June 2000 12:39
To: 'xtm-wg@egroups.com'
Subject: RE: [xtm-wg] XTM Requirements (Was RE: Is this valid per
HyTime? - topicmapmai l thread)


Hi,

Thanks to Kal and Ann for stepping in with some views there. I was gunning
for Kal's approach (although not very eloquently, I know ;). My
understanding of Jack's reasons for proposing these coordinate attributes
(gleaned from his messages) was that he wanted them mainly so that they
could be used to drive visual graph (I hope I'm using the right terminology
here -- nodes and arcs in a visual view(?)) representations of TMs in user
interfaces. If I've misinterpreted you here Jack, then I apologise.
>I must somehow make TMs appear visually in the same
way
> that Concept Maps are presented and constructed in classrooms around the
> world today.
(My education in England was devoid of Concept maps so I don't know exactly
what this means.)
I am at present unconvinced of the utility of user interfaces that operate
with visual graph representations of the TM itself. I am of the opinion that
using the TM itself _as_ the interface rather than to drive the design of an
interface is a mistake. Very few, if any, people have minds that allow them
to rapidly suck lots of information out of the '3-D' shadow ( what i meant
by 'spatial') of a hyperdimensional TM. There is a mismatch between user
capability and the representation here. As a corollary: How big are the
topic maps that you envisage appearing in these interfaces? 50 topics? 100
topics? 5,000,000 topics?

Hence my view (modulo Ann's remarks) that using these 'spatial'
representations of TMs in interfaces in this way will be limited to those
folks that wish to write applications that do that --   a limited sub-domain
of the folks applying topic maps to resource sets.

>I am trying to help standardize just one of
>the many presentation mechanisms for TMs
But I am questioning whether this should indeed be standardised as core to
the use of TMs, as most uses of topic maps will not require any visual
representation of the TM itself as I see things but only views of the
information in the resources the TM points at/aggregates. Hence my desire
for some mechanism that will allow me to plug-in/plug-out this functionality
relevant to a domain of operation IF it is agreed that there is really a
need for these attributes at all.

What do these attributes _really_ _do_ for what you envisage, Jack? Is it
just (to be really cynical here, sorry) that you want to avoid having an
algorithm on the server side that optimises the spatial coordinates of the
topics prior to serving them up to an applet -- a time/bandwidth worry? 
Corollary aside: Won't having fixed coord numbers in a given map risk
privileging certain views?

Hope that helps clear up what I driving at.

best,
Peter

-----Original Message-----
From: Jack Park [mailto:jackpark@verticalnet.com]
Sent: 28 June 2000 18:59
To: xtm-wg@egroups.com
Subject: Re: [xtm-wg] XTM Requirements (Was RE: Is this valid per
HyTime? - topicmapmai l thread)


Hi Peter,

Help me out here. What means "domain specific"?  And, where does 'spatial'
come from?  And, what are the core purposes of a topic map?  Guess I'm
missing something here. I always thought that a topic map was about
navagating an information space. I am trying to help standardize just one of
the many presentation mechanisms for TMs.  Why should that be pluggable?

Jack

From: Peter Jones <peterj@wrox.com>
> Hi Jack,
>
> I guess what I want is that the functionality that you require should be
> 'pluggable', since it is domain specific, IMHO.
> It does not seem to me to be crucial to the core purposes of a topic map.
>
> What if i want to merge one of your 'spatial' topic maps with an ISO 13250
> one?
> Why would I want to have to deal with all the overhead of parsing an extra
> six attributes (not #REQUIRED => #IMPLIED | known defaults, which is as
good
> as XML gets here), when I could just set my PJsTMSAXParser to ignore
> namespaced attributes instead, or not validate against certain public
domain
> parameter entity includes?
>
> Give me pluggable.
>
> best
> Peter
>
> -----Original Message-----
> From: Jack Park [mailto:jackpark@verticalnet.com]
> Sent: 28 June 2000 17:09
> To: xtm-wg@egroups.com
> Subject: Re: [xtm-wg] XTM Requirements (Was RE: Is this valid per
> HyTime? - topicmapmai l thread)
>
>
> Comments below.
> From: Sam Hunting <sam_hunting@yahoo.com>
>
> > [ Peter Jones writes]
> > >
> > > Your x,y,z attributes look to me like something I would only want if
> > > I chose to look at a topic map in that way: application specific.
> > > I.e. something that you could quite easily add in the form
> > >
> > > jackpark:x="120" jackpark:y="234" jackpark:z="456"
> > >
> > > so that they would be of use to you, but could be ignored by
> > > conforming processors.
> >
> > Actually, Jack proposed attribute syntax:
> >
> >     <topic x="120">
> >
> > *not* namespace syntax ("jackpark:x:).
> >
> > Before advocating namespace syntax for XTM please, if you are not
> > already doing so, follow the current namespace discussions at W3C.
> > http://www.xml.com/pub/2000/05/17/deviant.html is a good starting
> > point.
> >
> > S.
> >
> > P.S. I'm torn between  (a) rejecting them entirely, as a conceptual
> > morass, and (b) trying to hijack them to put them to good use. Frankly,
> > in practice namespaces pollute the very notion of generic identifier
> > with processing information, I'm inclined to alternative (a). Lie down
> > with dogs, get up with fleas.
>
> I did not conceive of any namespace in the specification I proposed. And,
my
> original thinking was that the values would not, in any way, be #REQUIRED.
> And, in particular, a "jackpark" namespace has really no place in this
> discussion. To narrow the focus of my proposal to that of a specific
> instance (me), is, IMHO, to miss the whole point I believe I was trying to
> make.
>
> As it turns out, I am very much involved in the development of TMs from
the
> visual aspect. I am sure Benedicte Le Grand will have much to say about
this
> as time goes on, but my view, at present, is simply to bring TMs into the
> classroom. To do so, I must somehow make TMs appear visually in the same
way
> that Concept Maps are presented and constructed in classrooms around the
> world today.  I have stated before that CMs are something akin to TMs on
> steroids.  Perhaps that is a bit misleading. In any case, I believe that
we
> have the opportunity to take TMs all the way to the bottom of K-12
> curriculae if we include the ability to model the visual aspect as well as
> the structural and (eventually) semantic aspects of some universe.
>
> Oh, and BTW: I forgot to mention the dimensions of the topic visual.
Thus,
> I am now proposing something along these lines:
>     <topic> name="sometopic" ...other stuff.... x="10" y="20 z=""
width="20"
> height="12" depth="" >
>
> If the values are not declared, the dtd won't cause the parser to holler.
>
> My personal vision is that an API can fall out of the final specification
> such that implementations of all kinds (applications) can be constructed
and
> still interoperate. Thus, I don not see the application-specific issue in
> the same way as as Peter does. My opinion, FWIW, is that the addition of
> graphical attributes to our topics does not make the specification any
less
> clean than it would otherwise be.
>
> Thus, I respectfully maintain my submission of these extensions to the
> standard.
>
> Jack Park
>
>
> ------------------------------------------------------------------------
> Replace complicated scripts using 14 new HTML tags that work in
> current browsers.
> Form the Web today - visit:
> http://click.egroups.com/1/5769/4/_/337252/_/962208428/
> ------------------------------------------------------------------------
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
> ------------------------------------------------------------------------
> Create professional forms and interactive web pages in less time
> with Mozquito(tm) technology.
> Form the Web today - visit:
> http://click.egroups.com/1/5770/4/_/337252/_/962210793/
> ------------------------------------------------------------------------
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com


------------------------------------------------------------------------
Create professional forms and interactive web pages in less time 
with Mozquito(tm) technology.
Form the Web today - visit:
http://click.egroups.com/1/5562/4/_/337252/_/962215250/
------------------------------------------------------------------------

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

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

------------------------------------------------------------------------
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/5563/4/_/337252/_/962278713/
------------------------------------------------------------------------

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

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

------------------------------------------------------------------------
Replace complicated scripts using 14 new HTML tags that work in
current browsers.
Form the Web today - visit:
http://click.egroups.com/1/5769/4/_/337252/_/962282625/
------------------------------------------------------------------------

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

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

------------------------------------------------------------------------
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/5563/4/_/337252/_/962377776/
------------------------------------------------------------------------

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

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