[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC