Michael Anderson - IETMs : An Interoperability Problem   Table of contents   Indexes   Michel Biezunski and Catherine Hamon - A Topic Map of This Conference's Proceedings
Michel Biezunski - Invisible HyTime
 Biezunski, Michel 
 High Text 
 		 Biezunski  Michel High Text, 
 

Invisible HyTime

 

Summary

 

A paradoxical situation and its remedies

 This talk is motivated by a paradox in which we are today: HyTime is not yet a hot issue, it's very difficult to get people attracted just by saying HyTime and at the same time it's the moment where real applications are starting.
 

Hide the scaffolding, Reveal the hidden beauty

 There are three aspects in HyTime:conceptual , political andtechnical . Scaffolding is the set of technicalities: a set of supplementary SGML features. The hidden beauty is the set of powerful concepts on which it relies. HyTime is looking ugly because it's new. As major scientific discoveries, the way it's expressed by the inventors has to be worked out and transformed before it becomes workable.
 

HyTime's new look

 AFDR 
 Architectural Form Definition Requirements 
 Hyperlink 
 		 Technical corrigendum : Separation between "SGML Extended Facilities" including AFDR and the HyTime's specific five modules for addressing, hyperlinking, measuring, scheduling, rendering.
 Even if it requires a lot of work and attention from the experts in charge of it, it is not a major upgrade, but just technical reorganization, from a user point of view.
 

The HyTime Decision

Information architecture - Choice
 		 The decision to choose HyTime as a base for representing information architectures can only be taken by people who understand the political and conceptual issues involved. Choosing HyTime is not only a question of getting the appropriate technology. Worst, it can be misleading to just rely on the available technology.
 The situation is not different from SGML at the beginning. SGML has never been a better technological solutions (cheaper, quicker, simpler, easier) than other available solutions. It doesn't mean SGML should be rejected though.
HyTime Tool
 

Is there such a thing called a HyTime tool?

 Tools are interesting if they fit user needs.
 What comes first? Tools or User needs? There is no simple answer. It depends of the kinds of users:
 Today, HyTime is only interesting for the second kind of users.
 The consequence is that only those who can invest in promising future technologies to emerge can be interested.
 But ... not a lot of users are satisfied with today's existing technologies in general. This is why the activity in the software industry remains so frantic.
SGML Technology
 

The SGML technology

 HyTime applications are built with SGML-based technology.
 HyTime is a part of SGML, and the SGML technology can be used for HyTime applications. Most existing HyTime tools today are SGML tools which is being specialized or extended to interpret the semantics provided by HyTime architectural forms.
 HyTime Engine 
 		 But this is true at the syntactical level, not at the end-user level. HyTime Engine and even Architectural Forms Engine do exist, but the question remains: what use can be expected from HyTime at all?
HyTime Application
 

What does "a typical HyTime application?" mean

 To which process(es) a typical HyTime application fits in ?
 Except for interchange purposes ("press a key and your database will export HyTime"), the question is for a user what advantage he gets from having a HyTime-compliant tool?
 The multimedia applications are not ready for HyTime yet.
 The first generation of SGML tools have been designed to accomplish a well-known process of publishing: SGML-conforming text editors, formatters, browsers have been created by respecting a well-known publishing process.
 What is the equivalent for the HyTime market?
 

Interchanging interconnected information

 Ilink 
 		 Focus will be now on one architectural form: independent link
 HyTime provides new, unheard-of, sometimes not-thought-of, types of user interaction that can be applied in different fields. HyTime is so wide and so ambitious in its scope that it can practically do anything. But this is also discouraging. By definition, users are not looking for potential, they are looking for usefulness. This paper will focus on single architectural form out of about 70, the independent linking feature of HyTime, which covers the work we have been doing since about 3 years in this field.
 Three aspects will be discussed: the conceptual side, the political side, and the professional side, before presenting the fundamental principles on which we have designed one specific application.
Linking versus Addressing
 

The conceptual side: Linking is different from addressing.

 Anchor 
 Hyperlink 
 		 This is a major breakthrough compared to the traditional hypertext approach ("click and see"). It describes what is related and why it is related. If we are not able to know what's at the other "end", it doesn't work. For 2 reasons: there is no such thing as a "start" and an "end". A number of things are related, and it's possible to restrict traversal rules for example in only one direction, but it is meaningless to try to say where is the origin and where is the target when for example 5 different objects are related together. They just happened to be related, HyTime says. The impact of this is tremendously important: it means that in order to interconnect information, one must know by advance what is the role played by what is becoming an anchor. Anchors can be anything, they don't have to be modeled as anchors. They are just "anything that can be addressed using a HyTime address". And as a HyTime address can point to anything, it means that every single piece of information is a potential anchor.
 Entity-Relationship Model 
 		 2) More than an entity-relationship model
 HyTime ilinks include the entity-relationship model used in databases. makes information visible once it is interconnected. It is like a database scheme and it prepares the long-term starting merging between the document world and the database world, already starting with SGML. HyTime adds to the entity-relationship model the addressing capabilities.
Ilink - political side
 

The political side: knowing / learning what others are doing.

 Architectural Form  
 DTD, Document Type Definition 
 		 It is a direct consequence of the conceptual side. One can only connect to something else by knowing / learning what others are doing. Why? Because the anchrole attribute is mandatory. A HyTime link is no more than an SGML architectural form that provides the knowledge of the semantics of any relation. Now the question arises of which part of the information set one is in control of. At least one need to have to knowledge of what is the information which one is relating to. This is similar to the DTD requirement in SGML. Prior to create any document instance, one must think about the structure. It's a "think before doing anything" kind of requirement. However, putting semantics into the relation itself means that it's possible to add alternative views on information regardless of what it was intended for. This is the consequence of the fact that HyTime allows to address anything, and that the semantics is in the link. Therefore, one can create as many views as desired into an information set.
Ilink - Professional side
 

The professional side: New skills required

Address Integrity
 DTD Design 
 DTD, Document Type Definition 
 Reference 
 		 Address integrity is a technical issue (for writers, for computer scientists, for database administrators, for system administrators, for network/Web administrators, for publishers, for librarians, etc.). It's important that the reference is correct. Knowing how to express correctly either a bibliographic reference, or a computer identifier is a technical issue, which is fulfilled by skilled people in the different fields. Using computers should on the long term help resolve addresses in a way which is more comfortable than the way it is done by traditional referencing. It requires a completely different set of skills to not only know what other people are doing, but how they are doing it in a certain way. One needs to be in a more powerful position to do so, because some people might not appreciate that others look with so much attention into their reserved domain. But interconnection of information has a price, and this is the real issue involved. HyTime only makes it visible. This is parallel to what happened with SGML. The DTD design is something that has to be done by information owners rather than by computer scientists. The information owners have gained more control by using SGML. Using the HyTime ilink feature gives them an even greater control.
 

Research-development still needed

 CApH 
 DTD, Document Type Definition 
Information Architecture Modeling
 MID 
 Topic Map 
Topic Map Architecture
 Topic Navigation Maps 
 		 HyTime modeling is a challenging task, because it involves changing the way we think about the very nature of information. The experience of the Topic Map architecture is interesting to recall. It starts with a user requirement from Unix vendors who wanted to interchange indexes, glossaries, thesauri, and after two years of meetings abandoned for the main part the HyTime way to concentrate on a classical SGML DTD. But the group continued to work, and the resulting architecture is now becoming an international standard, and it's deemed to success, although it might still take some time before practical implementations will be demonstrable. The other planned directions of work of the CApH group are very ambitious too: modification history, natural language, access policy, geographic information systems, are items which have been discussed as possible future architectures based on HyTime. It's possible to add to that specific domains, such as medical information or legal information management, that have their own requirements, including scheduling information in time and space. Another direction showing the potentialities of HyTime is the work made by the MID group on a language which describes among other things the ways a document can interact with its users.
 

A shared effort

 CApH 
 SGML Architecture 
 		 Development of HyTime-based architectures take therefore a lot of work, time and resources, and are probably not under the reach of small companies, or even companies which want to have an immediate implementation. It's best fitted for those who have a long-term perspective in mind, and can at the same time accommodate the existing technologies for doing what they need today and prepare more powerful information management approaches for tomorrow. This seems somewhat impractical unless consortiums are formed, on a professional or international level, to make this happen. The CApH group has not been able to meet for the last year and a half because of lack of resources of those involved, more or less on a benevolent basis. It's time to think on a future that can be shared together, and start to merge ressources on projects that are in the interest of the community as a whole. HyTime has everything within it to satisfy these needs. The only thing needed now is to find people enough motivated to support this process.
 

A new user interface: Make HyTime comfortable to use

 User Interface 
 		 A view on information is a user interface. The tools to make it work are part of that interface, but are not the interface itself. Because HyTime is an international standard, a lot of tools can be built using various technologies, including all levels of SGML purity and non-SGML technologies, such as databases.
 

The traditional hypertext user interface

 Reference 
 		 This interface is based on the notion of a reference . A reference is a uni-directional type of link which contains addresses and sometimes some semantics.
 HTML, Hypertext Markup Language 
 		 To create a link: start from the origin, highlight the target, and a smart application will put the address of the target right in the origin, with the appropriate markup for a link. Examples are SGML id-idref referencing, and HTML hypertext references (HREF):
 <A HREF="another_document"> or, if the application is more sophisticated:<A HREF="another_document # a_location_in_that_other_document">
 

Why are HyTime ilinks different from other links?

 An ilink is a relation between a set of anchors. Each anchor can in turn be made of a set of addresses. The two levels of groupings are different. This is a requirement imposed by the way the standard defines the ilink architectural form.
 

A user interface should :

 

What should be hidden from the user?

 Addressing 
 		 Addressing mechanisms
 

What should be shown to the user?

 Semantics of linking
 

A user interface for ilinks should then:

 Take care of the management of IDs (automatic invisible process)
 Be able to locate information transparently just by supplying the context of the SGML tree (or grove).
 Implement built-in traversal rules, allowing the user to navigate within an aggregate, depending of the value of the aggloc attribute. If this value is aggloc, traversal is possible from the aggregate to each of its member, whereas if the value is agglink, traverse is possible like within a pull-down menu, i.e. from the aggregate to each of its members, and from one member to the next and vice-versa.
 

Creation of a link

 In the hypertext (or contextual) way. Be at the origin. Highlight the target.
 For an ilink way, it does not realistic to think about a universal type of user interface, because the reason why there are ilinks and the way they can be implemented is widely open. Therefore, this depends on the application.
 The motivation for designing wide-open types of applications is to allow technology to be built to fit general needs that have been identified.
 Topic Map 
 		 The Topic Navigation Map architecture is an example of those. It allows information owners to describe the equivalent of indexes, glossaries, thesauri and cross-reference by building a knowledge base called a Topic Map.
 Ilink 
 Topic Map 
 		 In the Topic Navigation Map architecture, there are only two types of ilinks:
 User Interface 
 

User interface for topics in a topic map

 A typical user interface for a topic map would then contain the features needed to declare an object as the anchor of a given link (i.e. a given topic. The process is very similar to the one used while indexing a document.
 The question whether this process should be done automatically versus manually is an implementation issue, not an interface issue.
 

On-line help for interactive entry

 Supplementary tools are needed to help users who need to enter manually the above information.
 Topic Relation 
 User Interface 
 

User interface for topic relations

 User Interface 
 

Features of the user interface

 In order to facilitate the ease of use, the interface should contain features that are automatically triggered either during the process of the creation (interactive mode) or after it (batch mode).
Michael Anderson - IETMs : An Interoperability Problem   Table of contents   Indexes   Michel Biezunski and Catherine Hamon - A Topic Map of This Conference's Proceedings