Automatic hyperlinking on multimedia by compiling link specifications5794257Abstract A link specification and an electronic manual is provided to an auto linker which in conjunction with a run-time media engine provides hyperlinked manuals. The auto linker comprises a link generator for generating links and a link verifier for checking and modifying the links that are generated. The run-time media engine comprises an event handler and a script interpreter and handles the user interaction. Through the interaction of the hyperlinks from the auto linker with the run-time media engine the hyperlinked manuals are produced. Claims We claim: Description FIELD OF THE INVENTION
______________________________________
<LINK (link-type,name›,comments!) Source Destination
Include* Exclude*> where:
link-type:= REFER .vertline. CHAIN .vertline. OUTLINE .vertline. COMPUTE
Node:= (content-type, file-pointer, anchor-point)
Source:= Node
Destination:= Node .vertline. Destination+ .vertline. (Node
Destination+)
Include:= (+ Source Destination)
Exclude:= (- Source Destination)
content-type:= TEXT/SGML .vertline. IMAGE/TIFF .vertline. GRAPHIC/CGM
.vertline. . . .
anchor-point:=
match-string/ context-tag
.vertline.
match-string// context-tag
.vertline.
computational scripts
/* `/` means match-string is directly contained within
the context-tag */
/* `//` means match-string is contained within the
context-tag */
match-string:= "SELF" .vertline. "content-string"
{regular-expression}
content-string: =
strings allowable in TEXT/SGML
.vertline.
content-string defined for other content types by
<STRING . . . >
context-tag:=
<ENTIRE>
.vertline.
(context-tag ›D-!OUTSIDE match-string)
.vertline.
content-type-dependent-tag
.vertline.
content-type-dependent-context
.vertline.
(context-name = context-tag)
.vertline.
context-name
content-type-dependent-tag:=
tags allowable in TEXT/SGML
.vertline.
tags defined for other content types by <TAG . . . >
content-type-dependent-context:=
contexts-in-TEXT/SGML
.vertline.
contexts defined for other content types by <CONTEXT
. . . >
contexts-in-TEXT/SGML:=
(context-tag WITH attribute-constraints)
.vertline.
(context-tag ›D-!OUTSIDE context-tag)
.vertline.
(context-tag ›D-!INSIDE context-tag)
.vertline.
(context-tag AFTER context-tag)
.vertline.
(context-tag BEFORE context-tag)
.vertline.
(context-tag AROUND context-tag
attribute-constraints:=
attributename = NULL
.vertline.
attributename > attributevalue
.vertline.
attributename = attributevalue
.vertline.
attributename >= attributevalue
.vertline.
attributename < attributevalue
.vertline.
attributename <= attributevalue
.vertline.
attribute-constraints+
______________________________________
The link types, REFER, CHAIN, OUTLINE and COMPUTE are defined as follows. REFER cross references explicitly or implicitly refer to other information, and are the most common in service manuals. "See table", "refer to figure", "as shown in chapter", and "see section" are all examples of explicit cross references that are often found in service manuals. Other information pertaining to tools, materials, or procedures can be linked using REFER cross references. The following is an example of hyperlinks from document numbers in a table-of-documents to documents.
______________________________________
<LINK (REFER, "Go to Starting Page", /* Access to
Documents from Table of Documents*/)
(TEXT/SGML, manual.doc, "%x"/ ((<ENTRY> WITH colname = "2")
INSIDE (<Table>OUTSIDE (<Title > OUTSIDE "Table of
Documents"))))
(TEXT/SGML, manual.doc, "SELF"/ (<DocHeader>
BEFORE(<DocNum> OUTSIDE "%x")))>
______________________________________
The language formally described above is used to specify enough information so that hyperlinks can be generated automatically. The example above specifies a REFER link which links entries in a Table-of-Documents to the starting point of the appropriate document. The variable, "%x" is used to match each source that is found with the appropriate destination. The context-tag which follows is used to narrow down the search and to help insure that the correct information is found. The destination specification uses the keyword SELF to specify that the context-tag is actually the destination. CHAIN cross references consist of more than one cross reference. Usually, the intermediate reference is in a table. For instance, suppose it is desirable to link a component number with the appropriate part-list document for that component. Also suppose that the component numbers are listed in a table along with the part-list document number to refer to. A chain link is needed to go from the component number in the text to the component number in the table to the part-list document number in the table to the actual part-list document. OUTLINE cross references arise from the structure of the service manuals. Users may need a brief overview of structural information such as a table of contents, list of figures, list of tables, list of citations, list of warnings, list of repair steps, list of help notes, etc . . . . Access to a table or figure could be gained by clicking on a title in the overview. Help information or emergency contact information such as names and phone numbers of on-call experts should be available at all times. Special hot-buttons or an overview menu can quickly access this information. COMPUTE cross references are used to call external procedures which can compute the destination of a reference based on the context in which the manual is being used. For example, to retrieve some product information from a database, some routines could be called to access and query the database. This is important for database information that is changed frequently or for accessing the latest update information. For the non-TEXT/SGML media, allowable strings, tags, and contexts need to be defined for each content-type. This specification mechanism uses strings to indicate the anchorable information units (AIUs) (or hotspot areas) for non-textual media. The strings can then be used for pattern matching against the match-string in the <LINK . . . > specification for identifying AIUs in non-textual media. This mechanism provides a method to uniformly specify anchor-points (i.e., match-string/context-tag or match-string//context-tag in <LINK . . . > specifications) for both textual and non-textual media. String specification, a mechanism for describing contents of new media types, defines allowable string patterns which will eventually indicate Anchorable Information Units (AIUs) in a content-type media. A string-program shall be provided to generate AIUs from a given string in the pattern. For example, suppose we have a string-program that can identify an area of interest based on its relationship to some text in a CGM vector-based graphics file. This area can be a surrounding area of the text together with an area pointed to by a graphical arrow from the text. Then, the program and the following specification can be used: <STRING "%x" GRAPHIC/CGM textual-area-of-interest> to specify a match-string that can indicate that area inside of a graphics file. If a wire trace program can be provided for schematic drawings, we can specify an allowable string pattern "%c/%p" (standing for AIUs of wire trace along any component c and its pin p). We can use: <STRING "%c/%p" GRAPHIC/CGM wire-trace> to specify that a certain wire should be traced. This mechanism can incrementally add the capability of information access on non-textual media based on available identification programs to build AIUs for hyperlinks. Suppose that both images and 3D CAD models for a particular complex piece of equipment exist. Further suppose there is a string-program (called visible-parts) that can overlay the 3D CAD models on the image and identify the visible parts in the image. Then, it is possible to associate an area on the image with its part name and specify a part in an image as an AIU by: <STRING "%x" IMAGE/TIFF visible-parts> Tags, a mechanism for describing structure of contents of new media types, provide a way of labeling objects in a content-type media. For example, a <TITLE> tag in a text file indicates that the following text is in a title. The advantage of tags is that they can provide a structure for the content. Tag specification defines allowable tags for a content-type media. For content-type TEXT/SGML, the tags defined in an SGML DTD can be directly used in a <LINK . . . > specification because the containment relationships between the tags and the match-strings are clearly defined. If tags are to be used in other content-type media then the tags must be defined. The requirement is that a tag-program shall be provided to determine if a match-string is contained within a tag or directly contained within a tag (i.e., to provide interpretation of the notation "match-string/<tagname>" and "match-string//<tagname>" in the <LINK . . . > specifications for this content-type). The following is an example of linking component related information.
______________________________________
<LINK (REFER, "Inspect Component")
(TEXT/SGML, manual.doc, "%x"/<COMP>)
(GRAPHIC/CGM, SurveyOfComponent.cgm, "%x"/<ENTIRE>)
(TEXT/SGML, manual.doc, "SELF"/ (<DocHeader>
BEFORE(<DocNum> OUTSIDE "3.6-%x-9423")))>
______________________________________
This example demonstrates the use of multiple destination points which need to be accessed simultaneously. The source is a Component number. It is known that Component numbers are tagged with <COMP> in the document. The first destination is an overview graphical diagram that contains the Component number. With the "textual-area-of-interest" string-program, that number and the related area can be highlighted to show the area of interest. The second destination is the Component document. In the specification of the second destination, the knowledge about document numbering schemes is taken advantage of. Context, a mechanism for describing the relationships of the structures of new media types, provides a way to specify constraints and relationships among tags. For example, <TITLE Type="Figure"> INSIDE <CHAPTER> shows a constraint (Type="Figure") and a hierarchical relationship (<TITLE> within a <CHAPTER>). The contexts in content-type TEXT/SGML, such as Inside, Outside, After, Before, etc., are clearly defined. If contexts are to be used in other content-type media then the contexts must be defined. The requirement is that a context-program shall be provided to check the constraints of any legal tags. A context-tag program provides an interpretation of contexts on allowable tags in the <LINK . . . > specification. The flow diagrams for evaluating the specification language to generate links and to verify the generated links are shown in FIGS. 4 and 5. In FIG. 4, the electronic mail and the link specification are inputted into box 40 where the generator variables are initialized. At decision block 41 a determination is made as to whether there is a next link. If there is not a next link the link generator stops. If there is a next link, the link statement is parsed in block 42, for getting the source and destination patterns and contexts. In block 43, the manuals are searched for locating the places which satisfy the source patterns under the source context. In decision block 44, if a place is not found, the flow returns to decision block 41. If a place is found, the manuals are then searched for locating the places which satisfy the instantialized destination pattern under its context by binding variables found in sources. This takes place in block 45. In decision block 46, if a place is not found, the flow once again returns to decision block 41. If a place is found, in block 47, there is a collection of all sources and corresponding destinations for describing hyperlinks in a Manual Pool. FIG. 5 describes the flow chart for the link verifier and insertion. Links from the Manual Pool (FIG. 4) are inputted into block 50 where verification choices by link type, link name, or link statements are marked. All link instances which satisfy the verification selection are collected in block 51. At decision block 52 a determination is made as to whether there are any more links. If there are no more links, the link verification stops. If there are more links, in block 53, one link is obtained from the collection. A decision is then made in decision block 54 as to whether the link is OK. If the link is not OK, then in block 55, the current link is marked in the form (-source destination) for exclusion and the flow then returns to decision block 52 where a determination is made as to whether there are any more links. If the link is OK, then the link is inserted into a manual and a decision is made, in decision block 56, as to whether any additional links should be included. If no additional links should be included then the flow returns to decision block 52. If additional links should be included, then in block 57, new links in the form (+source destination) are collected for inclusion and inserted into the manual. The flow then returns to decision block 52 where a determination is made as to whether there are any more links. Tags are defined by <|ELEMENT tag . . . > in SGML DTDs. For example, chapters, sections, tables and figures in SGMl documents are often associated with tags Chapter, Section, Table and Figure respectively. They generally could also have titles which are tagged with "chapter title", "section title", "table title" and "figure title" tags respectively. However, tags for non-textual information are not defined in SGML documents. The present invention will take advantage of the tagging mechanisms provided by the file format or publishing system in order to locate hotspots (sources) and destinations in service manuals. Tags can be used to help specify, search for, and locate service manual contents in different contexts such as tables, headers, figures, etc. If no tagging mechanisms are provided, some specifications must be written for "user-defined" tags to get context information from the contents. Suppose the entire service manual is stored in plain ASCII text. Then it will be necessary to write some code to analyze the text and extract some context information. For instance, a string of numbers separated by periods followed by a string of all capital letters probably indicates a heading or subheading so that the text can be tagged with a heading or subheading tag. Tags are also used in graphics to identify a group of related objects. For example, a group of line segments could be associated with a "house" tag. The present invention includes two important features. The link specification described by the specification language compiled by the link generator can UNIFORMLY describe the needed hyperlinks on different content-type media for required information access and the system can systematically generate the hyperlinks once the needed hyperlinks are adequately specified. The mechanism to INCREMENTALLY specify Anchorable Information Units (AIUs) on non-textual media using <STRING . . . >, <TAG . . . >, and <CONTEXT . . . > is particularly useful because there is no general solution to identifying objects in non-textual media, and thus there are no standard ways to represent AIUs for non-textual media. Without recoding the link generator, the present invention provides a solution to specify/generate AIUs on a variety of media and formats in an extensive manner based on the best identification programs that are available. Currently in the prior art, hyperlinks are created manually or in a restrictive manner on texts. It is not intended that the present invention be limited to the software arrangement, or operational procedures shown disclosed. This invention includes all of the alterations and variations thereto as encompassed within the scope of the claims as follows. Examples of Link Specifications follows:
______________________________________
<STRING "%x" GRAPHIC/CGM textual-area-of-interests)
<LINK (REFER, "See Figures", /* See Related Figures */)
(TEXT/SGML, manual.doc, "see figure %x"//<ManualSet>)
(TEXT/SGML, manual.doc, "SELF" / (<Figure> OUTSIDE
(<Title> OUTSIDE "figure %x")))>
<LINK (REFER, "See Tables", /* See Related Tables*/)
(TEXT/SGML, manual.doc, "see figure %x"//<ManualSet>)
(TEXT/SGML, manual.doc, "SELF" / (<Table>OUTSTDE
(<Title>OUTSIDE "table %x")))>
<LINK (REFER, "See Reference Docs", /* Access to Related
Docs for Repair Instructions and Scheds */)
(TEXT/SGML, manual.doc, "%x"/((<ENTRY>WITH colname ="1")
INSIDE (<Table>OUTSIDE (<Title > OUTSIDE"Reference
Docs")))
(TEXT/SGML, manual.doc, "SELF" / (<DocHeader>
BEFORE(<DocNum>OUTSIDE "%x"))>
<LINK (CHAIN, "Find Drawing Documents", /* Check Drawings
from Component Numbers */)
(TEXT/SGML, manual.doc, "%x"/<COMP>)
(TEXT/SGML,manual.doc, "%x"/ ((<ENTRY> WITH colname ="3")
INSIDE (rowname = (<ROW>INSIDE <ComponentSurvey>)))
(TEXT/SGML, manual.doc, "%y"/(<ENTRY> WITH colname = "4")
INSIDE rowname))
(TEXT/SGML, manual.doc, "SELF"/ (<DocHeader>
BEFORE(<DocNum> OUTSIDE "%y")))>
<LINK (CHAIN, "Find Part List Documents", / * Check Part
List Docs from Component Numbers */)
(TEXT/SGML, manual.doc, "%x"/<COMP>)
(TEXT/SGML, manual.doc, "%x"/ ((<ENTRY> WITH colname =
"3") INSIDE (rowname = (<ROW>INSIDE <ComponentSurvey>)))
(TEXT/SGML, manual.doc, "%y"/((<ENTRY> WITH colname ="5")
INSIDE rowname))
(TEXT/SGML, manual.doc, "SELF" / (<DocHeader>
BEFORE(<DocNum> OUTSIDE "%y")))>
<LINK (OUTLINE "Repair Schedules Outlines", /* Overview
Repair Instructions and Schedules*/)
(SYSTEM/VIEW, TOC , "Repair Inst&Schedu"/<menu-item>)
(TEXT/SGML, manual.doc, "SELF"/(<Title>INSIDE
(<InstHeader> INSIDE <RepairInst>)))
(TEXT/SGML, manual.doc, "SELF"/(<Title>INSIDE
(<SchedHeader> INSIDE <RepairSched>)))>
<LINK (OUTLINE "List of Phone Help", /* Qverview All Help
Phone Numbers*/)
(SYSTEM/VIEW, TOC, "Phone Help"/<menu-item>)
(TEXT/SGML, manual.doc, "Telephon %x"//<ManualSet>)>
<LINK (OUTLINE "List of Figures", /* Overview All
Figures*/)
(SYSTEM/VIEW, TOC, "Figure Overview"/<menu-item>)
(TEXT/SGML, manual.doc, "SELF"/(<Title>INSIDE
<Figure>))>
<LINK (OUTLINE "List of Tables", /* Overview All
Tables*/)
(SYSTEM/VIEW, TOC , "Table Overview"/<menu-item>)
(TEXT/SGML, manual.doc, "SELF"/(<Title> INSIDE <Table>))>
______________________________________
|
Same subclass Same class Consider this |
||||||||||