INTERNET-DRAFT Don L. Jewett Intended Status: Informational Abratech Corp. Expires: December 17, 2015 June 15, 2015 THE FORWARDLINK-PROTOCOL: ENHANCED INTERNET-LINKAGES FOR READERS/SCHOLARS Filename: draft-dljewett-forwardlinkprotocol-00 Abstract *Short* Description: This Protocol automates creation and storage of Internet Links and BackLinks, together with enhanced MetaData, by individual, independent WebSites. The MetaData is displayed to Readers in SortableTables. The information in the SortableTables will be used by Readers to decide whether to follow Links and BackLinks that they encounter in using the Web, and will speed development of Knowledge based upon Web- Information. The Categories in the Tables are guided by the interests of the Readers, and differ between WebSites hosting different topics. The Protocol is designed to be implemented on individual WebSites; it does not require a centralized server nor top-down supervision. *Longer* Description: The FL-P (ForwardLink-Protocol) provides new communication conventions by which two WebSites exchange information and MetaData to provide easy and useful means for Article-Readers to decide whether to follow a Link from one Article to the another. A *RetroLink* takes the Reader to a citED Older-Text, from a citING Newer-Text. A *ForwardLink* takes the Reader to the citING Newer- Text, from a citED Older-Text. (NOTE: The words "Older" and "Newer" apply to the *Text*, *not* to the *Article* or *WebSite*. The adjectives "Forward" and "Retro" refer to the point-of-view of the Reader *when reading* the text that contains the Link. The necessity for this new terminology is explained in the body of the proposal.) Text-specific and Article-specific MetaData are presented to the Reader in SortableTables whose organization is determined by the Reader. The Reader's choices in data-categories and sorting are saved in Cookies on the Reader's Computer. These features aid the Reader in organizing the information of the SortableTables so as to decide whether to follow a displayed Link or not. These features increase the Reader's efficiency in searching for information on the Don L. Jewett Expires December 17, 2015 Page 1 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Web. ForwardLinks will significantly increase the utility of the Web for scholars, thus enhancing Knowledge creation based upon Web- Information. Additionally, ForwardLinks will *increase the value* of open-access, online archives (of both Publishers and Libraries). Such archives, will, over time, collect increasing numbers of valuable ForwardLinks that point to newer developments in a field, which is critical information for further progress. ForwardLinks are based upon "human judgments of importance". For example, ForwardLinks may well occur between two Articles that do *not* share *any* duplicate words or phrases. Such Linkages *cannot be discovered* with *present WebSearch techniques*. Status of this Memo This document is an Informational Internet-Draft. Whether any parts of this memo should be considered as an addition to some Internet standard may be considered in the future. Distribution of this memo as an Internet-Draft is unlimited if accompanied with correct attribution and cited as "work in progress". It can be cited as an Informational RFC when it is published as such. Comments (both negative and positive) are solicited and will be carefully considered. Comments should be emailed to the author at don.jewett@ucsf.edu, or at dlj@abratech.com. Further development of these ideas and related open-source software, and a means to voluntarily contribute to the open-source project, may be found at http://forwardlinkprotocol.org . This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html Don L. Jewett Expires December 17, 2015 Page 2 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology of this document . . . . . . . . . . . . . . . 8 1.2 New Terminology and Abbreviations for the ForwardLink-Protocol . . . . . . . . . . . . . . . . . . . 9 1.3 Stylistics . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4 A Comment on the Complexity . . . . . . . . . . . . . . . . 11 1.5 Funding acknowledgement and disclaimers . . . . . . . . . . 12 2. Title & Body . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1 Overview of Protocol Presentation used here . . . . . . . . 12 2.2 The Reader's Use of ForwardLinks . . . . . . . . . . . . . 13 2.3 Sortable Tables of Text and WebSite MetaData . . . . . . . 19 2.4 A Socio-Technical Loop Adapting MetaData to User Needs . . 22 2.5 Creating a RetroLink/ForwardLink Pair . . . . . . . . . . . 23 2.5 MetaData Categories . . . . . . . . . . . . . . . . . . . . 41 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 43 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 44 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.1 Normative References . . . . . . . . . . . . . . . . . . . 45 6.2 Informative References . . . . . . . . . . . . . . . . . . 46 7. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.1 AppendixA (List of Required Elements) . . . . . . . . . . . 46 7.2 AppendixB (Software Modules & HTTP-URL Lines) . . . . . . . 55 7.3 AppendixC (Possible MetaData SupraCategories & Categories) . 57 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 Don L. Jewett Expires December 17, 2015 Page 3 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 1. Introduction This Internet Draft is written in a style that conforms to Internet Draft Standards, but *also* incorporates extensive usage-descriptions that are *necessary* because in order to understand the reason for some of the Protocol requirements, there is need to understand the goals of the Protocol, as well as the requirements and consequences at a human level. The Protocol is intended to be part of a World-Wide Web consisting of distributed nodes and distributed links, where Links (in *both directions* and with *enhanced MetaData*) are available on *every* node. Such a Web is necessary in order to enhance Knowledge- development built upon freely-accessible Information, but such a Web is not yet available, nor is it likely to develop under present rules, protocols, and methods. The growth of information on the Web is so fast that even powerful crawlers cannot keep up, and the percentage of scholarly online papers covered by commercial indexing is decreasing [Larsen2010]. The amount of scholarly information that *should* be readily found on the Web was estimated by Bjork, et al. (quoted in [Larsen2010]) that in 2006 alone, 1,350,000 articles were published in peer-reviewed journals. This is about 3,700 articles per *day*. This volume overwhelms our older system based upon printing on paper, but provides the conditions under which a distributed effort becomes needed, and may well be successful. For scholars, the Web should be a collection of independent (distributed) Articles that are linked by *ideas*. Present linkages do not meet these criteria. <> Don L. Jewett Expires December 17, 2015 Page 4 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Ideas expressed by language can be seen to "clump" into a hierarchy of structures of increasing size, as follows: Letters (sounds) Words Phrases Sentences <--- The level of expression of ideas Paragraphs Pages Articles (Chapters) Journals (Books) Compendia (Review-Articles or Books that Summarize) From the above list, one can see that the natural *size* to refer to an idea (after it has been understood) is the *Sentence*. Yet the present Web is indexed on *Words or Phrases* (too small), and WebSite-based WebLinks usually carry the Reader to a new *Page* or the start of an *Article* (both too large). These limitations are removed by the ForwardLink-Protocol, where the Linkages are from *Sentence-to-Sentence*. (Provision is also made for Linkages that are *Text-to-Text*, such as when multiple sentences, long phrases, figure numbers, or spreadsheet cells are Linked.) A common form of WebLink is the URL (Uniform Resource Locator), a form of "WebSite-Address" which, among other functions, can provide means to locate pages, or parts of pages, for display. However, from the Reader's point of view, finding *scholarly citations* using present-day WebLinks has major weaknesses: 1) The URL usually points to a *whole* Article or to a *page* in an Article, whereas the Reader is better served by being taken to the *CitED Text* or the *CitING Text*. This is especially true for a WebLink from an Older-Text to a Newer-Text because if the Link from the Older-Text does not specify the CitING Newer-Text, time is lost by the Reader in trying to understand why the Link was created in the first place. 2) Present-day WebLinks do not provide sufficient MetaData information to help scholars in deciding whether or not to follow a Link. At present the Link must be followed before it's usefulness to a given Reader can be ascertained-- often a waste of time. The presently-used WebLink *names* are *extremely* confusing. The names were initially for *technical users*. Non-technical *internet- users* are not likely to understand that a "BackLink" is something pointing *forwards-from-the-time-of-the-material-being-read*. This problem is diagrammed in Fig.1. Since the ForwardLink-Protocol is directed towards the non-technical Reader, a *new terminology* is necessary and has been created (listed in Section 1.2). Don L. Jewett Expires December 17, 2015 Page 5 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.1A Title: Relative-Time from the Reader's Point-of-View, when reading. NB: The symbol "-C-" near the center is intended to show a vertical line passing over a horizontal line. Direction of Increasing Time ---------->------------>------------> "Now"'s The Reader's "NOW" from "Now"'s Past what is being read (TextB) Future | | | | v | ___v___ | | / TextA \<-RetroLink to TextA--C---+ | | ^ | v | | F_TextB_R | | | v v +---ForwardLink to TextC-->\_TextC_/ - - - - - - - - END Fig.1A - - - - - - - Fig.1A Legend: The Text-Content of a Reader's "Now" is determined by the material *being read*, *not* by the Reader's *own* time. In "real time", TextB is newer than TextA, but is older than TextC. Link-Icons are present before and after TextB (where the RetroLink- Icon is "R" and the ForwardLink-Icon is "F" to serve as indications to the Reader that TextB has such Links (with MetaData). (For further description, see Section 1.2 and/or Step(2.6) TechDetail after Fig.2.) Fig.1B Title: Temporal Relationships in TextB's Links Direction of Increasing Time ---------->------------>------------> TextB's RetroLink __________________________________ / TextA TextB \ is the *OLDER*, is the *NEWER*, CitED-Text CitING-Text TextB TextC is the *OLDER*, is the *NEWER*, CitED-Text CitING-Text \_________________________________/ TextB's ForwardLink - - - - - - - - END Fig.1B - - - - - - - Don L. Jewett Expires December 17, 2015 Page 6 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.1B Legend: A *RetroLink* takes the Reader *to* an Older-Text, whereas a *ForwardLink* takes the Reader *to* a Newer-Text. The terms "Older" and "Newer" provide information *only* about the *relative* time of publication of each *Text*, and do *not* indicate any absolute time. This is clear considering TextB, which is both "Newer" and "Older" depending upon what other Text it is compared to (by Linking). One way of remembering the *functional usefulness* of these Links, is as follows: 1) A RetroLink points *to* what *was* important. 2) A ForwardLink points *to* what *is* important, next. For scholarly Readers, ForwardLinks are *exceptionally useful* for these reasons: 1) ForwardLinks lead the Reader to newer material related to the topic of the material they are reading. The judgement as to the importance of the relationship was done by a human (the Author of the Newer-Text), and may be based upon factors that cannot be evaluated by computers at present (if ever). Such factors are often explained by the Author in extended Text. 2) ForwardLinks are based upon *ideas* rather than being based upon the words or phrases that are the basis of presently- available WebSearches. These ideas are created by, and used by, humans, as they develop knowledge. Such ideas (and their labels and explanations) are *fluid*, being created when needed, and dying out if not used by a community of scholars. 3) ForwardLinks demonstrate the contribution of older work to newer findings. 4) ForwardLinks transcend inter-disciplinary barriers since requiring Articles in different disciplines to have words-in- common (as needed by present Keyword-Searching) is a barrier to discovery. 5) A ForwardLink allows the Reader to find Newer-Material which has been judged *by a human author* to be linked to what the Reader is reading, and the ForwardLink takes the Reader to the *Text* in which the author describes the linkage and/or its bases. 6) ForwardLinks are immediately available on WebSites conforming to the ForwardLink-Protocol. No jumps to other databases is required on the part of the Reader. That is, with the ForwardLink-Protocol, the *ForwardLink and its MetaData* are available *on* the WebSite the Reader is reading. It is worthy of note that present 3rd-Party databases cover *less than half of academic WebSites*; this means that a *very large number* of articles are *not* served by these commercial operations [Larsen2010]. Further, for one database, submission of "Cited-by" MetaData can only be done by participating *publishers*. Thus, the present situation excludes single, unique Don L. Jewett Expires December 17, 2015 Page 7 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 WebSites devised by individuals or by organizations unable to pay the fees. These problems are corrected by the ForwardLink- Protocol. 7) The ForwardLink-Protocol provides Links that are *fully operational* even though *both* WebSites are changing *content* during development. This is possible because the Texts are found by a search for the *wording*, rather than to a *location* on the WebSite. Furthermore, in the Protocol, it is a Text's WebSite which provides the specific search parameters necessary to find the Text. So long as the Text's WebSite maintains a database "Version Control" or "WebSite History" that can be searched, a Text can be *found* even if it has been *deleted* from the current-display of the Article. This can be important to judge the flux of idea-relationships during times that terminology changes, and may be important regarding issues of priority. 8) ForwardLinks *increase the scholarly-value* of an online Archive over time if the Archive collects, stores, and displays the Links, even though the archived *content* itself does *not* change. That is, *old content* becomes *more valuable* as new MetaData-Information is collected. A full collection of ForwardLinks for a given *Text* can be exceptionally valuable to a scholar. Knowing this, Readers will be motivated to utilize the old archive as "the place" to find ForwardLinks. In consequence the value of the constantly-updated archive increases for Readers, as well as for the *Archive's Sponsors*. This fact should encourage Archivists to adopt the ForwardLink-Protocol for existing and future online archives. 9) One last advantage to be noted is that the ForwardLink- Protocol is compatible with the Dublin Core standardization efforts [DublinCore]. The MetaData transmitted in the ForwardLink-Protocol could be configured to conform, at a future time, to the Dublin Core, and also to with work with some of parts of the "Semantic Web", which formalizes Web names and relationships. 1.1 Terminology of this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Requirements phrased in the imperative as part of algorithms (such as "include ALL of the ForwardLinks" or "determine the MetaData- Categories to be displayed, and their order") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) used in describing the algorithm. Don L. Jewett Expires December 17, 2015 Page 8 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Conformance requirements phrased as algorithms or specific steps not using these words can be implemented in any manner, so long as the end result is equivalent. 1.2 New Terminology and Abbreviations for the ForwardLink-Protocol To prevent misunderstandings which were readily discovered when describing this Protocol to others, a New Terminology as been created. While this may be bothersome to someone trying to skim this Protocol, Readers following Protocol-details will find that, when consistently used, the New Terminology *avoids confusion*. Some names have been shortened by omitting some letters and/or using a Camel-Font. New Terminology || Comment and/or Abbreviation (alphabetical order) ActiveArchive || An online Archive in which || MetaData *changes*, but Content || *does not* change. || (compare PassiveArchive) FL-P || Abbr. of ForwardLink-Protocol ForwardLink || A new term for "BackLink"; || see "Rejected Terminology" below ForwardLink-Icon || At the *start* of Cited Text: || a Helm Symbol (Unicode || U+2388 or UTF-8 E2 8E 88). ForwardLink-Protocol || Abbreviation = FL-P ForwardLinkProtocol-Icon || The Protocol-Icon in text is || >>FL-P<< || A better icon may be found at || http://www.ForwardLinkProtocol.org or || http://www.WebCompendia.org ID || Abbr. of "Identification" (*not* || "Internet-Draft") LinkPair || A shortened form of || "RetroLink/ForwardLink Pair". MetaData || "Metadata" in Camel-Font. Newer-Text || NewerText-WebSite || Abbr. in Figures as "NwrTxt-WbSi" Older-Text || OlderText-WebSite || Abbr. in Figures as "OldrTxt-WbSi" PassiveArchive || An online Archive in which neither || Content *nor* MetaData change. || (compare ActiveArchive) Don L. Jewett Expires December 17, 2015 Page 9 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 RetroLink || A new term for "Link", to imply || "Backwards-in-time" (see || "Backlink" and "PastLink" || in Rejected Terminology, below) RetroLink/ForwardLink Pair || RetroLink-Icon || At the *end* of CitING Text: 3 || asterisks in triangular array || (Asterism symbol) || (Unicode U+2042, UTF-8 E2 81 82). ------------------- Rejected Terminology || Reason for rejection (alphabetical order) BackLink || A technical term that confuses || non-technical Readers, since they || interpret the Link to go || "Backwards-in-Time" from what they || are reading. A new term || "ForwardLink" is used instead. || Note that a RetroLink is *not* a || BackLink. FutureLink || A term already in use on the Web. Metadata || A trademarked term (with an initial || upper case character). See Camel- || Font "MetaData", above. PastLink || Not used because "FutureLink" || unuseable. (see RetroLink, above) Reference || "Citation" is better, and more || easily used, as are CitING and || CitED. "Referencing" and || "Referenced" are awkward. || All of the following pairs, || though perhaps grammatically || correct, are uncommon and unclear: || Citor, Citee || Linkor, Linkee || Pointor, Pointee || Referror, Referee WebCite || Can be confused with "WebSite" || when spoken. ------------------- Don L. Jewett Expires December 17, 2015 Page 10 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 1.3 Stylistics A Camel-Font is used on some words so as to make frequently-used words distinctive. Nouns are capitalized when a *specific* thing are being referred-to, in contrast to a *general*, non-specific thing. Nouns that are acting as adjectives are hyphenated to the modified noun. Multiple adjectival nouns are hyphenated together, or joined together in Camel-Font. When an abbreviation is first introduced, the abbreviation is given, followed by its full name in parentheses. If the Reader knows the abbreviation, the parenthetical expansion is ignored. If the Reader does *not* know the abbreviation, the use of the abbreviation informs the Reader of something that is not understood, but whose meaning is immediately available parenthetically. This is the reverse sequence to the standard method for RFC's. The standard method is non- intuitive because usually parentheses indicate some additional information that may be safely ignored during rapid reading. But if the parenthetical abbreviation is neither read by, nor known by, the Reader, then later in the article, when the abbreviation is again used, the Reader who does not know the abbreviation must go back in the text to find the abbreviation within parentheses, sometimes on a different page. It would be nice if this proposal could be created in a *sans serif* font, since such a font is easier to read on a computer screen. No way was found to do this. Sorry. 1.4 A Comment on the Complexity The ForwardLink-Protocol is complex. Indeed, so is the World-Wide- Web. The benefits of the Web did not become apparent until Browsers were widespread. The same is undoubtedly true of the ForwardLink- Protocol -- software for the Protocol is necessary before the Protocol becomes useful. There seems to be a threshold in increasing complexity that must be passed in order that simple-sounding goals can be made sufficiently attractive to encourage general use. The goal of providing ForwardLinks on the Web is relatively simple. However the goals of making ForwardLinks *easy to use* and *time-efficient* for Readers has markedly increased the complexity. If asked "Why not just propose a Protocol for ForwardLinks alone and forget the MetaData?", one reply is: "A Protocol without MetaData and SortableTables would Don L. Jewett Expires December 17, 2015 Page 11 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 *not* provide sufficient features to motivate spontaneous spread to WebSites and Archives, nor to bring forth further improvements." 1.5 Funding acknowledgement and disclaimers The development of the Protocol described in this Internet-Draft was supported in part by the National Library of Medicine of the National Institutes of Health, under a Small Business Research Grant award to Abratech Corp., number R43LM10734-2. The content of this Internet Draft is solely the responsibility of the author and does not necessarily represent the official views of the National Institutes of Health. Abratech Corporation has no claims to any of the parts of the ForwardLink-Protocol that may be new or original. The content of this Informational Internet-Draft is placed here under the provisions of the IETF (see "Copyright and License" Section above Table of Contents) and any residual rights not so covered are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Further developments may be listed at http://www.ForwardLinkProtocol.org . There is no connection whatsoever between the Content of this RFC, the ForwardLink-Protocol, nor any of its terminology, processes, or activities with the activities or products of The Metadata Corporation, or the FutureLink Corporation, or any other person or entity who has valid trademarks containing, or related to, any of the terms used, or processes described. 2. Title & Body THE FORWARDLINK-PROTOCOL: ENHANCED INTERNET-LINKAGES FOR READERS/SCHOLARS 2.1 Overview of Protocol Presentation used here Based upon the experience of presenting the ForwardLink-Protocol to others, the best approach is to describe in a *Figure* how the Protocol is *used*, and to include many of the technical details within a *Figure-Legend* whose paragraph numbers match the numbered Steps in the Figure. In order to get an overview, ignore or skim the indented text, labeled "TechDetails". The Protocol-Requirements (MUST, MAY, etc.) are often located in the Figure-Legends, and all Requirements are *also* collated in AppendixA. Don L. Jewett Expires December 17, 2015 Page 12 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 2.2 The Reader's Use of ForwardLinks How a Reader will use ForwardLinks provides a good introduction to the goals of the ForwardLink-Protocol. In Fig.2 we show the interactions that occur between the Reader's Browser and a WebSite containing a ForwardLink from a CitED Text, followed by a Jump to a WebSite containing the CitING Text. Fig.2 Title: The use of ForwardLinks by a Reader of a WebSite. STANDARD INTERNET CONNECTIONS | OLDER TEXT-WEBSITE | READER's BROWSER _________________________ V ____________________________ | | |1)Reader inputs a URL for | | | | an OlderText-Article | | | |2) Browser sends the HTTP | |3) Receives Request | <------ | Request to OldrTxt-WbSi | |4) Sends Display | ------> |5) Shows Display | | | |6)Reader sees ForwardLink-| | | |Icon before a *Text* or | | | |*Title* of interest, and | |7) Receives Click | <------ | clicks the Icon. | |8a) Sends SortableTable| | | | of MetaData of *all* | | | |ForwardLinks from the | | | |Icon-marked Text, and | ------> |9) Displays SortableTables| |8b) Also sends Request | |(see Fig.3a). Reader then | |to all NewrTxt-WebSites| |clicks to preview *one* of| |for *Update of Dynamic*| | the CitING Newer-Texts. | | MetaData; then sends | |10) Browser Displays the | | revised Display to | | Sentences of the | |Browser (Repeat Step8a)| | Text-Preview | |_______________________| |11) Reader immediately | |reads CitING NewerText. | |After evaluating it, | NEWER Text-WEBSITE |Reader clicks to Jump to | _________________________ |the NewerText-WebSite | |12) Receives Request | <------ | (see Jump in Fig.3a). | |13) Sends Display of | | | |WebSite Page containing| | | |Highlighted CitING Text| ------> |14) Reader continues | |_______________________| | study on NewrTxt-WbSi. | | (Reader can return to | | other ForwardLinks by | | clicking Browser | | back-arrow or prior tab) | |__________________________| Don L. Jewett Expires December 17, 2015 Page 13 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.2, Legend: Shown here are the Steps that occur when a Reader, reviewing text in an Article (or a WebSite) that *Conforms with the ForwardLink-Protocol*, finds Older-Text that has a ForwardLink to Newer-Text (as indicated by a ForwardLink-Icon). In this Figure, the Reader evaluates the Information about the Newer-Text (displayed in a SortableTable--see Fig.3), and then clicks for a Text-Preview. After reading the Preview, the Reader then clicks to go to the NewerText- WebSite directly. In the numbers below, the first is the Figure number, and the number after the "decimal-point" is the Step-number in the Figure. (2.1) The Reader is using a Browser to read material from the Internet. The Reader has a URL of an Article that might be important or useful. The Reader provides the URL to the Browser. (2.2) The Browser sends an HTTP-Request over the Internet, using the URL, to the WebSite that displays the Article. We will call this WebSite the "OlderText-WebSite". (2.3) The OlderText-WebSite receives the HTTP-Request. TechDetail: All ForwardLink-Protocol WebSites MUST use HTTP1.1 for Internet Communications. HTTPS MAY be used, and is RECOMMENDED because although the content carried by the ForwardLink-Protocol is intended to be freely available, it is possible that parts of the communications might be the basis for misusing the Protocol to affect the participating WebSites in ways not intended by the Protocol and in ways not useful to the creators of the WebSite. (2.4) In Response, the OlderText-WebSite Sends its Display to the Browser. TechDetail: The Display MUST include Link-Icons as specified in Step(2.6). (2.5) The Browser displays the WebSite content. (2.6) The Reader finds a Text of interest. The Text has a ForwardLink-Icon at the *start* of the Text. The Reader clicks on the ForwardLink-Icon in order to display the MetaData about *all* ForwardLinks from that specific Text. Such MetaData was previously acquired by the WebSite under the ForwardLink- Protocol. TechDetail: WebSites MUST use Link-Icons in Text-Displays. The ForwardLink-Icon MUST be a Helm Symbol (Unicode U+2388 or UTF-8 E2 8E 88) placed at the *start* of the Cited Text. If a whole article or section in an OlderText-WebSite is CitED, then the ForwardLink-Icon MUST be placed at the beginning of the *title* of the article or of the section. This Icon was chosen as being different from current alphanumerics in Reader-oriented articles, and also so that the ForwardLinks can be easily spotted by a quick glance over a page. Readers will want to find these Icons because of the reasons given on pp.7&8. Don L. Jewett Expires December 17, 2015 Page 14 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 In a NewerText-WebSite, the RetroLink-Icon MUST be an Asterism symbol "3 asterisks" (Unicode U+2042, UTF-8 E2 81 82) that MUST be placed at the *end* of the CitING Newer-Text. A form of Link with restricted MetaData can occur when PassiveArchives, created before the widespread use of the ForwardLink-Protocol, become ActiveArchives. An ActiveArchive does not change its Content over time, but *does* change its MetaData via the ForwardLink-Protocol. In this situation the RetroLinks may not have any Text-specificity since they only refer to the whole Article, but still, the SortableTable MetaData of the ForwardLink can still supply the CitING Text and its MetaData to the Reader of the OlderText-WebSite. The Icons and their locations within the Text-Display, as described in this Step (2.6), are REQUIRED. If the specified Icon-symbols cannot be used, then other symbols MAY be used ONLY IF the meaning of the symbols is clearly specified to a Reader on *each page* that such an Icon occurs. However, the ForwardLink-Icon MUST be such that it can be easily picked out during a glance at the page. In cases where the original text cannot be modified to include the required icons, the Link-Icons MAY be displayed using a transparent overlay. An Icon occupying just a single space is RECOMMENDED so as to allow display in texts that use only a single space between consecutive sentences. (2.7) The OlderText-WebSite receives the signal of Step(2.6), indicating that the Reader wants to view some Text and/or MetaData. TechDetail: The click starts the FL-P_Display_SortableTable Software-Module on the OlderText-WebSite. The Software identifies the appropriate MetaData and prepares to send the data as described in Steps(2.8a) and (2.8b). (2.8a) Any FL-P-conforming WebSite, in response to the clicking of either type of Link-Icon, MUST send to the Browser two SortableTables of MetaData. One SortableTable contains MetaData regarding the *Text*, while the other SortableTable contains information about the *Article* (or WebSite) containing the Text (see Fig.3); this information is *not* the same (see AppendixC3). The SortableTable MetaData is stored in the Text-WebSite's Database (see Fig.3 and AppendixC). TechDetail: Each SortableTable MUST include ALL of the ForwardLinks that cite this Text, each Link in a separate Row. If there are too many ForwardLinks to fit in the Display, then a means to move the Display, or to truncate the Display, MUST be provided. (See also Fig.3.) The format of both SortableTables MUST comply with any FL-P- Cookie on the Reader's Browser that has been created by the FL- P_Edit_Cookies Software-Module of *any* WebSite that conforms with the ForwardLink-Protocol. The Cookies MAY determine, Don L. Jewett Expires December 17, 2015 Page 15 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 among other parameters, the MetaData Categories to be displayed, their order in the SortableTable, which Row will be initially used for sorting the Table, and the direction of the Sort. The Reader MUST be able to change these choices during the Display, either in the Display or in the stored Cookies. The Reader MUST be shown a list of available MetaData- Categories that are not in being Displayed at the time, nor specified by the Cookie being edited. The Reader MUST be able to name and save different Cookie- files, each consisting of all of the parameters chosen at one time, so that multiple Reader-choice Cookies can be saved and later recovered for different projects and/or fields. These capabilities MUST be in the Software-Module "FL- P_Edit_Cookies". The Software-Module MUST provide an option to create a Cookie that, for some purposes, does *not* present the SortableTables (i.e. skipping this step). All Cookies MUST comply with RFC6896 [RFC6896]. The Reader MUST be offered access to the FL-P_Edit_Cookies Software-Module both before and after a Link-Icon has been clicked. (2.8b) In addition to the Step(2.8a) actions, the Displaying WebSite MUST, after sending the SortableTable Display to the Reader's Browser with the data presently in the Database, send a request for an update of Dynamic MetaData to every WebSite for which the Database has a Link *for the Text* of the Reader- selected Link-Icon, whether currently listed in the SortableTable or not. The Display MUST indicate to the Reader "Dynamic Data Being Updated" or an equivalent. Note that this rule applies to displays of SortableTables for all Links, both RetroLinks and ForwardLinks. TechDetail: Update requests MUST only be for Dynamic MetaData, and MUST NOT be sent if less than 7 days or 168 hours have elapsed since the last such request from the WebSite. This is to reduce the number of update requests to a single WebSite should an Article on that WebSite become popular. The latest Date/Time of an update request is found in AppendixC3 here: {...Link-List: ThisList-RetroLink#y: Date/Time last update request}. An analogous item is found in ThisList- ForwardLink#z. The WebSites MAY negotiate what Protocol will be used is this Updating Process, but each WebSite MUST be able to use the JSON-RPC protocol [JSON-RPC]. When the Responses to the Update Request(s) are received by the requesting WebSite, the requesting WebSite MUST update the Dynamic MetaData in the Display on the Reader's Browser, and MUST provide an indication that the update has occurred. The requesting WebSite's Database MUST also be updated, including the date/time of the most recent request (see previous paragraph). If a WebSite is unable to give a proper Response to an Update Request, that Don L. Jewett Expires December 17, 2015 Page 16 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 WebSite MUST provide a clear Error-message that indicates what prevents the Update, along with Contact Information if appropriate. The Error-message MAY be displayed to the Reader, and MAY also be directed to the SiteAdmin of the Requesting WebSite. All of these functions can be part of a Software- Module named "FL-P_Update_MetaData". If, for any reason, Static Metadata has changed, then such altered MetaData MUST be included in any Response to a "Request for Update of Dynamic MetaData." Note: as specified in this protocol, neither WebSite checks to see if the Dynamic MetaData has actually changed. It is possible to check this, and then send only the MetaData that has changed. However, it is possible that fewer computer- cycles may be needed to transmit all Dynamic MetaData, updated or not. Since reducing "Network-Load" and reducing CPU cycles at the WebSite are both worthwhile, this protocol specifies that the WebSite responding to an Update Request MAY EITHER 1) Send *all* Dynamic MetaData, whether updated or not, OR MUST 2) Determine which Dynamic MetaData has been updated, and *only* send updated MetaData. The Response must indicate which method was used. Each WebSite's Database MUST distinguish between Dynamic MetaData and Static MetaData for its own MetaData and for the MetaData of RetroLinks and ForwardLinks (see AppendixC, ListC3). (2.9) The Browser Displays the SortableTable as specified by the Browser Cookies (Step(2.8a)), so that the Reader can evaluate the MetaData and decide which of the ForwardLinks (if any) are worth further examination. In the example being described here, the Reader decides to read a *Preview* of one the Newer-Texts that Cite the Older-Text, so the Reader clicks on the Letter-symbol for that Text (see Fig.3A). If the CitING Text is not of interest to the Reader, a click on the "return arrow" of the Reader's Browser will repeat Step(2.9), to provide the option of following *other* ForwardLinks from the same CitED Text. TechDetail: In this Figure, we assume that the Reader has previously requested the Text-Preview to be displayed in a pop- up window because the Reader needs easy access to the Window of the SortableTable, in order to switch to another ForwardLink. The WebSite MUST offer at least two of the following three options (or equivalents): 1) New window (Reader returns by back-arrow); 2. New tab (Reader returns by closing tab or clicking previous tab); 3) a Pop-up Window (Reader returns by closing window). The Reader MUST be offered buttons or other controls that provide these functions: a) Display a list of Category-rows that are available in the Database, but are *not* currently displayed, b) Change the displayed Category-rows, c) Change the Row upon which the Table is sorted, d) Change the order of Don L. Jewett Expires December 17, 2015 Page 17 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 sorting on the chosen Row, and e) Return to the start of this Step(2.9) at any time. The last requirement (e) MUST be offered because, as the SortableTables will be used, it is likely that the Reader will look at several Text-Previews before Jumping to another WebSite. (2.10) At the end of Step(2.9), the Reader has clicked one Text- Letter (see Fig.3), in order to read the Text-Preview for that Text. A Text-Preview shows the CitING Text (or CitED Text for RetroLinks), together with the immediately-preceding Sentence and the immediately-following Sentence. Text-Preview data is part of the Link-MetaData on the Database (see AppendixC, ListC3) that was sent to the Browser. TechDetail: A click in the SortableTable MUST display the Text-Preview in a manner that was chosen by the Reader (and recorded in any Cookie created as specified in the TechDetail of Step(2.9)). By having the CitING Text in the Database of the OlderText- WebSite, it can be downloaded and displayed faster on the Reader's Browser than if the NewerText-WebSite had to be contacted via the Internet. Furthermore, this prevents excessive use of the Internet if a WebSite is receiving many clicks on the Link-Icons. (2.11) The Reader looks at one or more Text-Previews, and in the example here decides to go to one of the NewerText-WebSites using a "Jump" button in the SortableTable (Fig.3). (2.12) The Newer-Text-WebSite chosen by the Reader, and linked to the chosen "Jump" button, receives the request. (2.13) Using the "FL-P_Display_CitING_Text" Software-Module, the NewerText-WebSite sends the Browser a Page Display with the CitING Text near the middle of the display. The Text MUST be highlighted or distinguishable in some way easy for the Reader. (2.14) The Reader now can learn more about the Text, and explore the WebSite. Should the Reader wish to return to the SortableTables, this can be done by the Browser's BackButton, or by clicking on an older Tab. <> Don L. Jewett Expires December 17, 2015 Page 18 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 2.3 Sortable Tables of Text and WebSite MetaData Two SortableTables are presented to the Reader after clicking a ForwardLink-Icon (see Step(2.8a) above). The First Table presents MetaData about the CitING *Text* for each of the available ForwardLinks that cite the Text labeled with the ForwardLink-Icon. Each row of the Table contains one MetaData Category and the results for each ForwardLink, while the columns are the results for each ForwardLink for all Categories. The Second Table presents MetaData about the *Article* or *WebSite* in which the CitING Text was published. (For a single-Author Article the Article-MetaData will be similar to the Text-MetaData regarding authorship, etc. However, the Metadata may well be different for the Text and the Article, if, for example, the "Article" is a Blog, or a WebCompendium, then it is very likely that the the Metadata will also be different in the two SortableTables. The MetaData for the SortableTables is exchanged between WebSites during creation of the RetroLink/ForwardLink Pair. The WebSite (being read) displays the SortableTable MetaData when a Reader clicks a Link-Icon. The *Dynamic* MetaData in a SortableTable is Updated whenever a new Display is produced (see Step(2.8b). (See also Fig.7.) By means of Cookies on the Reader's computer, the rows that the Reader has selected are presented in the order of the Reader's choice. The Reader can also choose the row upon which the data will be sorted, and the sorting-order-direction. In addition, the Display MUST show any MetaData-Categories that are available, but have not been chosen by the Reader, to be displayed, and MUST offer a means for the Reader to Display such data without changing the active- cookie. From the foregoing description, it is not easy to imagine the SortableTables. So, Figs. 3A & 3B are shown next, with *made-up data* ("dummy-data"). <> Don L. Jewett Expires December 17, 2015 Page 19 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.3A Title: A SortableTable about the CitING Text, with dummy-data. ______________________________________________________________ | TEXT-MetaData Categories | ForwardLink MetaData | |____________________________________|_______________________| | Temporary Text ID's for this Table | | | | | Click Letter to Read Text-Preview| A | B | C | | Click Jump to Go To Article | JumpA | JumpB | JumpC | |------------------------------------|-------|-------|-------| | Question to CitING Author: "Please | | | | | rate the level of importance of | | | | | the CitED Text to what you | 3 | 0 | 2 | | are writing. 3=High,2=Med,1=Low, | | | | | 0=Uncertain" | | | | |------------------------------------|-------|-------|-------| | Question to CitING Author: "Is this| | | | | an unusual Citation in the field | Yes | No | No | | for which you are writing?" Yes/No | | | | |------------------------------------|-------|-------|-------| | Author of CitING Text |Nemo N |Lee RE |Geary I| |------------------------------------|-------|-------|-------| | Year of Publication[*SORTING HERE*]| 1999 | 2006 | 2010 | |------------------------------------|-------|-------|-------| | % of Readers who have followed | | | | | this ForwardLink | 6.3 | 0.8 | 3.7 | |------------------------------------|-------|-------|-------| | Author-added Keywords or Phrases | Novel |Prelim.|Review | | |Method |Result |Article| |------------------------------------------------------------| |------------------------------------------------------------| | Other MetaData Categories available, but not shown: | | 1. Total number of ForwardLinks on NewerText-WebSite. | | 2. Other Questions answered by the CitING Author. | | 3. Date of last ForwardLink on NewerText-WebSite. | |------------------------------------------------------------| | Click *HERE* to add another Row to this Table. | |------------------------------------------------------------| | Click *HERE* to change the Sort Row, or the Sort Order | |------------------------------------------------------------| | Click *HERE* to request a new question or new data category| | for CitEDText-WebSite, on the WebSite *you are reading*.| |____________________________________________________________| <> Don L. Jewett Expires December 17, 2015 Page 20 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.3B Title: A SortableTable about the *Article* containing the CitING Text, with dummy-data (in same order as Text Table in Fig.3A) ______________________________________________________________ | ARTICLE-MetaData Categories | ForwardLink MetaData | |____________________________________|_______________________| | Temporary Article ID's for Table | | | | | Click Letter to Read Text-Preview| A | B | C | | Click Jump to Go To Article | JumpA | JumpB | JumpC | |------------------------------------|-------|-------|-------| | Total Number of ForwardLinks | | | | | available on CitING Article | 152 | 10 | 37 | |------------------------------------|-------|-------|-------| | Title of CitING Entity (Article, |New |Gut |Calc in| | WebSite, or WebCompendium) |Methods|Sensory|Computr| | |Neurosc|Endings|Science| |------------------------------------|-------|-------|-------| | Moderator/Author Name, |Jones T|Lee ER |Quip D | | Position, and |AsstPrf|PostDoc|Prof | | Institution |Yoyodyne|Hitten-|Have- | | |Instit.|Miss | fjord | | | |College| Univ. | |------------------------------------|-------|-------|-------| | Key Words |Cortex |Histol |Fast | | |in vitr| |Compute| |------------------------------------|-------|-------|-------| | Field of Study of CitING Article | CNS |Anatomy|Comptr | | | | | Sci. | |------------------------------------------------------------| |------------------------------------------------------------| | Other MetaData Categories available, but not shown: | | 1. Last ForwardLink date. | | 2. Date First Posting. | | 3. Total Number Standard Citations (no URLs). | | 4. Total Number of RetroLinks (with URLs) | | 5. Language. | | 6. Is there higher math than Algebra and Geometry? | | 7. Are there Statistics higher than basic level? | |------------------------------------------------------------| | Click *HERE* to add another Row to this Table. | |------------------------------------------------------------| | Click *HERE* to change the Sort Row or Sort Order. | |------------------------------------------------------------| | Click *HERE* to request a new question or new data category| | for CitINGText-WebSite, on the WebSite *you are reading*. | |____________________________________________________________| Fig.3 Legend. Dummy SortableTables for MetaData: A) about the CitING *Text*, and B) about the *Article* containing the CitING Text. Note Don L. Jewett Expires December 17, 2015 Page 21 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 the kinds of information (Rows) that this (virtual) Reader has chosen to view. Note also that Text A is of particular interest to this virtual Reader because: In Fig.3A-- 1) The Author has rated the importance of the CitED Text HIGH relative to the material containing the CitING Text; 2) The Author states that this Citation is unusual (and hence the Link may lead to new ideas between fields); In Fig.3B-- 3) A large number of ForwardLinks (152) are presently available on the NewerText-Article (which implies that, since the NewerText-Article is CitED by many RetroLinks, whatever the Article says has become important). The ForwardLinks provide an easy way to follow this development; 4) The Keywords that describe the NewerText-Article are of interest to the Reader. NOTE: The SortableTables in Figs.3A&3B illustrate such Displays for *ForwardLinks*. Additionally, such information can *also* be of use to the Reader to evaluate *RetroLinks* (especially the Author's answers to the Questions asked by the OlderText-WebSite). So, SortableTables SHOULD BE used for *both* ForwardLinks *and* RetroLinks; the MetaData has been collected and is easily presented. 2.4 A Socio-Technical Loop Adapting MetaData to User Needs It is *critically important* in the ForwardLink-Protocol that the MetaData match the needs and interests of Readers as such needs and interests *change* or as they *differ across fields*. Recall that the design of the Protocol involves *independent* Authors and *independent* WebSites. Thus, there will be no "top-down" rules for the Content or Format of MetaData, either initially or later. When a WebSite is first set-up, the Moderator, WebAdmin, or Author will specify the MetaData to be collected and displayed. This makes the MetaData appropriate to the content of the WebSite, at least initially. However, should new developments occur that need different MetaData to be evaluated easily, there needs to be a method for the MetaData to change or enlarge. The communication channel provided by the "Click HERE" buttons in the lower sections of Figs.3A&3B provides a means for gradual changes of MetaData Categories to the needs and interests of the Readers by means of Messages to the SiteAdministrator, Author, or Moderator. Additionally, the Messages can be about the Questions and other Information collected from Authors of Newer-Texts. This *feedback- loop* is powerful in providing a *combined technical and social Don L. Jewett Expires December 17, 2015 Page 22 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 means* by which the information gathered during use of the ForwardLink-Protocol can follow changing trends and needs. 2.5 Creating a RetroLink/ForwardLink Pair So far a "User's View" of the functioning of ForwardLinks and RetroLinks has been presented. Next, how these features are created by means of software that conforms with the ForwardLink-Protocol will be shown. First, Fig.4 will clarify the relationship of the two Texts and the two Links involved in a RetroLink/ForwardLink Pair. Fig.4 Title: The two Texts of a RetroLink/ForwardLink Pair. The "Older-Text" and the "Newer-Text" are *the same* in both the RetroLink and the ForwardLink. What *differs* between the two Links is that the RetroLink points *to* the Older CitED Text (points Retro- in-time), whereas the ForwardLink points *to* the Newer CitING Text (points Forwards-in-time). Direction of Increasing Time ---------->------------>------------> _____in RetroLink from TextB_______ / TextA TextB \ is the *OLDER* is the *NEWER* CitED Text CitING Text \____in ForwardLink from TextA______/ Fig.4 Legend: A variation on the information in Figs.1A&1B, to clarify that during creation of a RetroLink/ForwardLink Pair, only *two Texts* are involved, one Newer, and one Older. (Fig.1 showed *three* Texts because it involved the concepts of "Older" and "Newer", where a single Text can be *both* at the same time.) Figures will be used to indicate the steps in creation of a RetroLink/ForwardLink Pair. <> Don L. Jewett Expires December 17, 2015 Page 23 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.5 Title: First Steps needed to create a RetroLink/ForwardLink Pair STANDARD INTERNET COMMUNICATIONS OLDER Text-WEBSITE | AUTHOR'S BROWSER __________________________ V ________________________ |2) Receive Request | <------ |1) Request Display | |3) Send Display | ------> |4) Show Display | |6)Start Pgm Collect Info| <------ |5)Send LinkPair Signal| |7) Send User Instr. | ------> |8)Displays User Instr | | | |9) Author HiLites Text| |11) Save & Check Text; | <------ |10) Sends "HiLiting | |Bad Data-->Snd Error msg| | Done" Signal | |Good Data-->Make ID's | | | |12) Send Questions | ------> |13) Questions Answered| |15) Saves to Database | <------ |14)Sends"Answers Done"| |16) Creates Text-Content| | | | (BibRef & HTTP-URLs) | | | |17) Sends Instr. Display| ------> |18)Displays Instructs.| | | |19) Copy of Copy/Paste| |21) End Internet Connect| <------ |20) Closes Browser | |________________________| |21) Opens TextEditor | |______________________| | | AUTHOR'S | TEXT EDITOR __________V_____________ |22)Paste BibRef & HTTP| |in new File or Draft- | |Article's Ref. Section| |23) Save File/Draft | | | | (An Indefinite Time | | Interval Follows) | |______________________| Fig.5 Legend: To create a RetroLink/ForwardLink Pair, initially a human must want to cite some Older-Text. When the Text to be cited is identified, the process is partly automated, as diagrammed here (and explained below). In the numbering of the paragraphs below, the first number is the Figure number and the second number matches the numbered Steps in the Figure. (5.1) The Author opens a WebSite-of-interest in a personal Browser. The Author wants to look for Text that might be CitED. (5.2) The OlderText-WebSite receives the HTTP-Request. (5.3) The OlderText-WebSite sends a Page for the Browser to Don L. Jewett Expires December 17, 2015 Page 24 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Display. The WebSite conforms with the ForwardLink-Protocol. Any WebSite that the conforms to the ForwardLink-Protocol MUST provide an easily seen and understood indication of that conformation, perhaps by a ForwardLink-*ProtocolIcon* and/or a Button labeled "Click HERE to Cite; create a ForwardLink to your work" (or equivalent). TechDetail: The WebSite MUST provide either a Button, or some other means that is easily seen and understood by the Reader, on EACH Page that contains material that can be CitED/Linked. When activated, the means will start a program to obtain the initial data necessary for a RetroLink/ForwardLink Pair. Best Practice is for a virtual button to be displayed on each such page. If some keyboard characters are needed for action, then this information MUST be readily available, preferably on each page-display containing material that could be CitED. (5.4) The Browser shows the Text Display. (5.5) The Author, finding Text to cite, clicks the Button described in Step(5.3). This click sends a signal that will start data collection using the ForwardLink-Protocol. (5.6) The OlderText-WebSite receives the signal from the Browser, and starts the Software-Module "FL-P_Collect_ForwardLink_Info". TechDetail: The Software-Modules are listed in AppendixB. The names of all Software-Modules used in the ForwardLink- Protocol MUST begin with the following 5 characters: FL-P_ . WebSites that conform to the ForwardLink-Protocol MAY program the actions of the Software-Modules in any way, using any internal terms as desired. However, in Internet- Communications, the labels of the ForwardLink-Protocol MUST be used. If a ForwardLink-Protocol Internet-Communication lists a named FL-P Software-Module in an item starting "HTTP-URL_", then the name assigned to the Software-Module by the WebSite MUST be included if it is different from the named Module. The ForwardLink-Protocol provides descriptions of the functions needed and the communication requirements. Each WebSite MAY meet these specifications in any manner, and each WebSite MAY embellish or enhance the functions without restriction, but MUST NOT change any functions or communications if such changes affect ForwardLink-Protocol functions in, or communications with, other WebSites. (5.7) The Software-Module "FL-P_Collect_ForwardLink_Info" on the OlderText-WebSite MUST send Instructions for the Author in a pop- up window (or equivalent), while the window containing the Text to be citED is still easily available to the Author for the steps that follow. If the Author wishes to Cite a non-text object (such as a Figure, Spreadsheet, or Table), it is RECOMMENDED that the Author HighLight the Title or the Legend of the object. The WebSite MAY provide other means of indicating CitED non-text objects, but MUST Don L. Jewett Expires December 17, 2015 Page 25 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 provide the Author with easily-found instructions on their use, PREFERABLY on the same page as the object. (5.8) The Browser displays the instructions requesting the Author to highlight the Text of interest. (5.9) The Author follows the instructions and HighLights the (to- be-Cited) Text. (5.10) The Author sends the "HighLighting Done" signal requested in the Instructions of Step(5.7). (5.11) The OlderText-WebSite Receives the "HighLighting Done" Signal and associated Data. Substeps of (5.11): (5.11a) The OlderText-WebSite (running the Software-Module FL-P_Collect_ForwardLink_Info), determines if the HighLighted Text starts at the start of a Sentence, and ends at the end of a Sentence. If not, then the Author is alerted, and asked either to change the HighLighting, or to indicate that the selection is OK. Despite the benefits of starting and ending on inter-sentence boundaries, if the Author finds such limits undesirable, the Author's judgement should prevail. When the choice is "OK", the OlderText-WebSite determines if the number of characters in the CitED Text exceed the limit set by the WebSite Admin (default size = 100). TechDetail: The limit on the number of characters is for the purposes of the *Search* for the Text. Later display is not limited by the ForwardLink-Protocol, though the WebSite MAY have display limits. For the Search, if the Text is too long, then the citED text is shortened and segmented by taking the first "x" characters and the last "y" characters (where x and y are set by the WebSite Admin --default size = 50), and treating these two labeled segments as the citED Text for the purposes of a Search of the Text within the Article. The symbols that identify the two segments, and the size of the segments MAY be set by the WebSite Admin. (5.11b) The Software then triggers FL-P_Search_CitED_Text, which, using any Search_Engine preferred by the WebSite Admin, and using the CitED Text specified in Step(5.11a), searches for the citED text (and any duplicates) within the range of the Article. TechDetail: The Search_Engine software SHOULD ignore LWS [Linear White Space] in both the citED text and in the WebSite if incorporating such LWS in the search might cause any ambiguity between searches, for example when using different Browsers. If the Search has been *successful* within the Article, then the Search for Duplicates SHOULD NOT include any Version Control or History files. If the search is *unsuccessful*, something is clearly wrong, since the Author has HighLighted something in the Don L. Jewett Expires December 17, 2015 Page 26 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 display of the OlderText-WebSite. Possible problems MUST be addressed: the Search MUST be expanded to include *all* parts of the WebSite where the Text might be found, including, but not limited to: Other Sections not searched, History files, Version Control files, Appendices, and Appended Content. If the Search is still unsuccessful, or if there are duplicates, an explanatory error signal is sent to the Author's Browser, and to the OlderText-WebSite Administrator. The program MAY provide additional information and options to the Author, or MAY otherwise halt or suspend the Protocol. With a *successful* Search and no duplicates (excluding Version Control, History files, etc.), the Software next determines if any of the Text characters are either a RetroLink-Icon or a ForwardLink-Icon (as used by the WebSite). If so, then this Text has been previously processed in the ForwardLink-Protocol, and has a previously- assigned TextID. This TextID, together with the Location of the CitED Text, MUST be transmitted to the Software-Module "FL-P_Collect_ForwardLink_Info", after which the Search Software quits. The "FL-P_Collect_ForwardLink_Info" Software-Module will use the previously assigned TextID (Step(5.12)), whether the Text was previously CitED or CitING. If the Text has *not* been previously processed, the FL- P_Search_CitED_Text Software sends that information to FL- P_Collect_ForwardLink_Info, and then quits. The Location MAY be coded in any manner, but the code MUST be such as to be correctly processed by any of the FL-P Software-Modules that utilize the location-data, and by any other Software that the WebSite may use to find and/or Display the Text. (5.11c) If there is no previously assigned TextID, then a unique ID (Identification) MUST be assigned to the *Text*. This is accomplished by the FL-P_Create_CitED_IDs Software (called by FL-P_Collect_ForwardLink_Info). The Software also determines what ArticleID was assigned to the Article when it was placed in the Database. The previous assignment of an ID for the Article MUST HAVE occurred because when the Article was placed in the WebSite, the Article Static Metadata MUST be entered into the Database at that time. Such MetaData MUST include the Article-ID and the Questions to be asked in Step(5.12). (The Software necessary for these actions are not part of the ForwardLink-Protocol.) TechDetail: The IDs created are used primarily on the OlderText-WebSite, so the ID Method MAY be specified by the WebSite Admin. Any given Text within an article MUST have the same TextID no matter whether it is a CitED Text of a Don L. Jewett Expires December 17, 2015 Page 27 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 RetroLink, or a CitING Text of a ForwardLink, since the same text can both be CitING and CitED (see Fig.1B). Also, the same Text-Phrase may be "enclosed" within different limits by different Authors, but can still have the same Text-ID because within the Database each Link-Pair is individually identified (see ListC3, AppdxC). The Software MUST NOT create any TextID which is a duplicate ID within the entity over which software may search. For example, if the Text is within an Article, then the TextID MUST be unique within that one Article. The Software MUST verify that each TextID is unique within the boundaries of the next-larger unit. If the ID is not unique, the Software MUST create a new ID that is unique and MUST verify the uniqueness. To reduce the usefulness of the TextID for malicious use, the ID SHOULD NOT be predictable based upon what can be obtained from the WebSite, or predictable from previous use of the ForwardLink-Protocol in legitimate communications with the WebSite. (5.11d) The "FL-P_Create_CitED_IDs" Software-Module then assigns a unique ID to the *Link*. TechDetail: The LinkID is used primarily on the OlderText- WebSite, and only on the specific Text specified by the CitED TextID, so the ID Method MAY be specified by the WebSite Admin. LinkIDs can be the *same* in *different* Texts (that have different Text-IDs). The limits placed on all IDs MUST match the requirements of the Database as it is used. The Software MUST NOT create any LinkID which is a duplicate ID within the Links of the specific TextID, including both RetroLinks and ForwardLinks. The Software MUST verify that each LinkID is unique within the range of use. If the ID is not unique, the Software MUST create a new ID that is unique and MUST verify the uniqueness. The Software MUST NOT re-use any LinkID that was used for a Link within the specific TextID, even if that LinkID is not currently in use. To reduce the usefulness of the LinkID for malicious use, the LinkID SHOULD NOT be predictable based upon what can be obtained from the WebSite, or predictable from previous use of the ForwardLink-Protocol in legitimate communications with the WebSite. Since each of the three IDs are unique within an ID's range, all three together describe a unique Link in a unique Text within a unique Article. Thus, the three Unique IDs not only uniquely identify a Text associated with a Link, the three IDs also form a functional "password" for the NewerText-WebSite to be validated for the OlderText-WebSite Don L. Jewett Expires December 17, 2015 Page 28 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 at the start of the communications necessary to create a NewLinkPair (described later re Fig.6). (5.11e) The FL-P_Create_CitED_IDs Software then prepares the Database for the MetaData entries that will be "under" the ArticleID in the Database: the TextID, and the LinkID. The Software then sends the IDs to the FL-P_Collect_ForwardLink_Info Software and quits. --End SubSteps of (5.11)-- (5.12) The OlderText-WebSite (running the FL-P_Collect_ForwardLink_Info Software) obtains the Questions for the Article from its Database by accessing the Static Metadata of the Article, using the ArticleID obtained in Step(5.11e). It also obtains any Extra Questions related solely to the Text, under the Static Metadata of the TextID (see ListC3, AppendixC). The prepared Questions are displayed to the Author, with fill- in-spaces for answers, space for Keywords, space for free text entry (that the Author might wish to contribute). Note that the Questions will clearly *differ* for WebSites of *different fields*; this is part of the Socio-Technical Loop previously described in Section 2.4. TechDetail: The Questions have been prepared by either the Author of the citED text, the Moderator of the blog, or the WebAdmin of the WebSite. The questions are relevant to the interests of the WebSite Readers of the Article on the *OlderText-WebSite*. The Answers may influence Readers when deciding to follow a ForwardLink or not. The Questions are stored in the Database (See AppdxC, ListC3: Aricle#(w),StaticMetadata,Questions for CitING Author). (5.13) The Author answers the Questions and completes fill-in boxes with keyboard strokes, or chooses among alternatives by clicking check-boxes. The Last of the Questions MUST be "Do you want a standard Bibliographic Reference to the Text to be provided for you? <> <>". (5.14) The Author finishes and clicks the "Answers Done" button that is displayed. (5.15) The OlderText-WebSite saves the Questions and Author's Replies (i.e., the Questions, Answers, Keywords, and all Fill-ins, including nulls) to the Database. It also populates the Database with the minimum MetaData necessary to support later use of the FL-P_Start_NewLinkPair Software. (A list is given in Step(5.23).) TechDetail: A *Very Important Fact*: Note that the Database does *not* contain an ID for every Sentence in every Article. *Instead* the Database contains only CitED material and the related MetaData. It is *not necessary* to give an ID to every Sentence in every Article. *Instead* entries are created and saved in the Database *only* if the entries are part of a Link that will probably be used. This fact reduces the amount of Don L. Jewett Expires December 17, 2015 Page 29 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 CPU cycles devoted to the ForwardLink-Protocol, and speeds searches of the Database. The Software-Module "FL-P_Collect_ForwardLink_Info" MUST save the data in the Database. ListC3 in AppendixC shows suggested MetaData Categories. (5.16) The OlderText-WebSite now creates Text-Content that will be transferred to the Author's computer. The Author's Answer to the Last Question (see Step(5.13)) determines part of the Content. If the Answer is "Yes" the Content MUST consist of the following parts: starting with a quadruple Semicolon (;;;;), then two texts separated by a double-Semicolon (;;), and ending with a triple Semicolon (;;;): 1) Quadruple Semicolons (;;;;) ; 2) A complete BibRef, ending with an appended WebLink; 3) Double Semicolons (;;) ; 4) An HTTP-URL (HTTP-URL_FLP_Start_NewLinkPair) which, when sent on the Internet, provides the correct address to access the named Software-Module on the OlderText-WebSite, plus additional information (see below); 5) Triple Semicolons (;;;) . If the Answer to the Last Question (see Step(5.13)) is "No" or Null, then the Content consists of only items 3,4, and 5, above. The Text-Content MUST start with a double Semicolon (;;) and end with a triple semicolon (;;;). The BibRef is *very important* because it makes Citing an online source *much easier for the Author* who would otherwise have to collate content from different online displays in order to provide a proper Citation in the Article being written. Authors that use the ForwardLink-Protocol "get 3 benefits for less effort than needed for one". The 3 automatically prepared benefits are: 1) the standard Reference, 2) the correct WebLink, and 3) the RetroLink/ForwardLink Pair, with their associated MetaData. If a WebSite's Administrators wish the WebSite to be especially popular with Authors, it MAY offer to create the BibRef in a number of different Citation-Styles, offering the choice to the Author. A list of citation styles is in Wikipedia under "Citation". The Author might then be able to match the BibRef Citation-Style to the Citation-Style that will be used in the article to be posted on the NewerText-WebSite. Otherwise, the WebSite's Administrators MUST choose one style most likely to be used by those CitING the Article, and offer at least the one style [Wikipedia Citation]. The appended WebLink allows Readers of the Author's Article to directly jump to the CitED Text from the Article's Reference Section. The WebLink can also be copied to other places in the Author's Article to provide Readers with easy access to the CitED- Text from within the Article. Don L. Jewett Expires December 17, 2015 Page 30 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Note that *both* the WebLink Address and the HTTP-URL are created by the WebSite that is to *receive* the communications. This ensures that both of these "pointers" are correct. There is no need for a WebSite to guess what the proper addresses to another WebSite are. TechDetails: The BibRef is a full bibliographic reference (citation) for the citED text, and MUST be for only a *single* citation. There MUST be one RetroLink/ForwardLink Pair for each of multiple Citations from a single Text. There MUST be a *different* RetroLink/ForwardLink Pair for each *different* CitING Text, whether or not the different CitING Texts refer to same CitED Text or not. These requirements occur because *each Link* has different data related to usage of the Link. The BibRef MUST include, at the end, a WebLink that, if activated, can display on a Reader's Browser the CitED Text (placed in the middle of the Display). The URL of this WebLink is provided in "HTTP-URL_Display_CitED_Text". The WebLink MAY contain any WebAddress chosen by the Programmers/Administrators of the OlderText-WebSite. Within the Software-Modules of the ForwardLink-Protocol, the Software-Module "FLP_Display_CitED_Text" will perform this function (see AppendixB). After the BibRef's WebLink, the program MUST place a double- Semicolon, and then MUST place an HTTP-URL line that, when used, will send data to the Software-Module "FL- P_Start_NewLinkPair" on the OlderText-WebSite. This HTTP-URL line will start the process of creating the RetroLink/ForwardLink Pair initiated by the Author. The HTTP_URL MUST include the Article-ID, the Text-ID, and the ForwardLink-ID, each labeled as "CitED". Different items in the this line MUST be separated by single Semicolons. The end of the Text-Content MUST be indicated by triple Semicolons. (5.17) The OlderText-WebSite sends Instructions that describe the Steps that must be taken by the Author to complete the "Collect_ForwardLink_Info" process correctly. This Step MUST be done. (5.18) The Author's Browser displays the Instructions. To give an example, the instructions might be as follows: ---- START of EXAMPLE INSTRUCTIONS ---- IMPORTANT INSTRUCTIONS Dear Author, Please carefully follow the steps below in order to complete creation of your RetroLink/ForwardLink Pair. Don L. Jewett Expires December 17, 2015 Page 31 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 If you do not follow these steps, the information for the LinkPair will be lost, and you will have to start over again (finding the Text, HiLiting it, Answering the Questions, etc.). 1) Below is displayed Text-Content THAT YOU MUST SAVE on YOUR computer. 2) If you would like to have the Text-Content automatically placed upon your computer's Clipboard now, click <> and go to 4). 3) Otherwise, HighLight ALL of the Text-Content-lines with your cursor and Copy them to the Clipboard for Pasting. 4) Open your word-processor and then Paste the ENTIRE Text- Content, in ONE of these two places: 4.1) First Place = Into your Draft of the Article that you are writing, in the correct place for a Citation/Reference to the CitED Text, and then save the modified Draft of the Article. If you edit the BibRef to match the referencing style you are using, you MAY remove the quadruple Semicolons at the Start of the Citation. BUT Do NOT remove or change the symbols that are between the double Semicolons (;;) and the triple Semicolons (;;;). OR 4.2) Second Place = Into a special computer file that you name and save. Use this method if your contribution, at this time, does NOT have a Citation/Reference Section. Or if you do not want to put entries into the Citation/References Section right now. This file MUST have, at the start of the Text-Content, 4 Semicolons (;;;;), and the Text-Content MUST end with 3 Semicolons (;;;). ALSO be sure to include in the file's name or somewhere in the file's content, something that indicates which Article the file applies to and which Text in your Article is the CitING Text. Do NOT change any Content having multiple semicolons at the Start and End. When you complete your Contribution to the WebSite, you can paste the Content into your Article, as described in 4.1, above. You may remove the 4 Semicolons (;;;;) but do NOT remove the other Semicolons or any other Content. 5) Finally, NOW OR AT SOME FUTURE TIME, you MUST upload your Don L. Jewett Expires December 17, 2015 Page 32 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Article, or other Contribution, to the WebSite that will post it on the Web. You MUST also upload the file of Step4.2) above, if you have not incorporated it's Content into your Contribution. -|-|- Below is the Text-Content that you MUST Copy, Paste, Use, & Upload -|-|- [[Text-Content Here]] -|-|- Above is the Text-Content that you MUST Copy, Paste, Use, & Upload -|-|- A blessing for a scholar: "May your work be properly cited, and appreciated." --------- END EXAMPLE INSTRUCTIONS ----------- (5.19) The Copy to the Clipboard is done by either clicking the <> button (as shown in line2 of the Example Instructions above), or by HighLighting the multiple text-lines, followed by a "Copy" function. (5.20) The Author exits the Browser, which ends the Internet Connection to the OlderText-WebSite. (5.21) The Author opens the Text Editor on the local computer. (5.22) The Author *either* pastes the Clipboard with Text-Content into a new file, *or* into the Draft of the Article, in the Reference Section as a Citation for a RetroLink. TechDetail: While many things can be automated, this specification is for the Author to place the Citation/Reference from the ClipboardData into the working document being created. The reasons are that there are many styles of scholarly writing, Authors differ as to the method that they like, and there is less problem if the Author makes the decision on placement of the Citation/Reference and the WebLink. At this point, it is reasonable to wonder why Clipboard manipulations are specified in the FL-P at all. Would it not be better to have the ClipboardData transmitted automatically between the two WebSites? The answer relates to the unreliability of humans in creating Citation/References between scholarly works. The Author, at the time of finding the CitED Text on the OlderText-WebSite, may have only a barely-formed idea about how the Citation will finally be used (after repeated editing). Some Links that are planned may never be completed. So it is not wise to complete the RetroLink/ForwardLink Pair *before* the RetroLink is correctly placed on the NewerText-WebSite. Thus, the ForwardLink-Protocol, as now written, has *no data* Don L. Jewett Expires December 17, 2015 Page 33 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 stored on the NewerText-WebSite until the Author is sure about creating the RetroLink Citation from the Newer-Text (described in Fig.6). Here is a Check-List of the minimum data that is stored, at this point, in the OlderText-WebSite's Database (following ListC3): Abbrs.: # = ID, not yet specific; #x = Specific ID; #_ = ID will be specified ThisList-Article#w ThisList-Text#x, Static Metadata, ID of Article#_: ID of Text#_: Text of Text#x: Preview of Text#x: HTTP-URL to Display_CitED_Text (WebLink): HTTP-URL_FL-P_Start_NewLinkPair: Link-List, ThisList-ForwardLink#z Dynamic Metadata ID of ForwardLink#_: Questions to & Answers from CitING Author: Keywords entered by Author: Other entries by Author: Comments upon items in the list above: 1. The three IDs are in the list so that they will be easily copied into the HTTP-URL_FL-P_Start_NewLinkPair as params of a JSON-RPC message. 2. The HTTP-URL_FL-P_Start_NewLinkPair contains the URL that will direct the JSON-RPC message to the FL- P_Start_NewLinkPair Software-Module on the OlderText- WebSite, without any change needed. The "Method" of the JSON-RPC message is "FL-P_Start_NewLinkPair", the Software-Module on the OlderText-WebSite that will do the initial processing. 3. The Text and Preview are saved because it is easiest to identify them during the "Collect_ForwardLink_Info" process. 4. The HTTP-URL to Display_CitED_Text is part of the BibRef, the "WebLink" at the end of the standard citation. This is included so that the Reference Section will provide a WebLink even if the remainder of the ForwardLink-Protocol is not completed. 5. The Questions/Answers and other Author-entered data are placed in the Database because there is no other place in Don L. Jewett Expires December 17, 2015 Page 34 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 the process where they can be easily saved. Note that *most* of the MetaData Categories in Appdx3, ListC3 are *not* in the above list. The data for such unfilled Categories will be entered when the NewLinkPair is created (See Fig.6). The MetaData in the list above provides a minimum amount to save. The OlderText-WebSite MUST NOT remove from the Database ANY data associated with Text#x until more than 24 months have passed. After 24 months the Author's Answers may not be current, and if the Author still wishes to Cite Text# after 24 months, then another LinkPair sequence should be initiated, starting with Step(5.1) of Fig.5. (5.23) The Author saves the File or Draft of Step(5.22). (The Author is responsible for backup of these Author Computer files.) A Recapitulation of the "story" of Fig.5, up to this point: The Author found a Text on the OlderText-WebSite that the Author wished to Cite in an article being written that the Author will post on the NewerText-WebSite. The Author wanted creation of a RetroLink/ForwardLink Pair, and so clicked on the "Create RetroLink/ForwardLink Pair" button on the Display of the Text, to start the process. The OlderText-WebSite provided instructions so that the CitED Text was identified by highlighting. It then gave unique IDs to the Text and the Link, and collected Answers to Questions from the Author. The OlderText-WebSite then provided text to the Author that had two parts: 1) a complete BibRef with WebLink, 2) an HTTP-URL needed for starting inter-WebSite communications, including the 3 IDs that uniquely identify the Text and Linkage. These two parts were temporarily saved by the Author. The BibRef is for the Author's benefit, because it will be inserted directly into a Reference-section of the Author's Article. The HTTP-URL is for use by the NewerText-WebSite; it will provide an easy, correct, direct way for the WebSite to contact the OlderText-WebSite to start creation of a NewLinkPair. The three IDs have two functions when the HTTP-URL is sent to the OlderText- WebSite: 1) The IDs uniquely define content in the OlderText- WebSite's Database that stores the CitED Text, and will contain all of the MetaData associated with the Link. The IDs are a simple method for both WebSites to be correctly dealing with the same Texts; 2) The IDs provide a means for the OlderText-WebSite to validate the Internet Communication from the NewerText-WebSite. The story continues in Fig.6, when the Author is ready to submit the contribution containing the Citation, to the NewerText-WebSite. <> Don L. Jewett Expires December 17, 2015 Page 35 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.6 Title: Final Steps in the Creation of a RetroLink/ForwardLink Pair STANDARD INTERNET HTTP/1.1 COMMUNICATIONS | NEWER Text-WEBSITE | AUTHOR'S BROWSER ____________________________ V ________________________ |2)Start "New Upload" pgm | <------ |1)Contact NewrTxt-WbSi| |3)Sends Upload Instructs. | ------> |4) Author Reads Instr.| |5)Recvs & Processes File | <------ |& Uploads Article File| |6)Sends Error Msgs or OK | ------> |7)When OK, Close Brwsr| |9) Close Web Connection | <-----> |8)Close Web Connection| |after CitING info sent to | |______________________| | "Create_CitING_IDs" pgm | | | | (An indefinite Time | | Interval Follows) | | | |10) This WebSite processes | | uploads for posting (not | | described) & for FL-P: | |a) "Create_CitING_IDs" pgm | | creates IDs, Database | | entries, & completes all | | empty Database MetaData. | |b)CitING IDs put into HTTP-| |URL_FL-P_Start_NewLinkPair,| |(CitED IDs already there); | OLDER Text-WEBSITE |c) Above HTTP sent to Older| __________________________ | Text-WebSite. | -----> |11) Message starts | | | | Start_NewLinkPair pgm | | | |12) Verify CitED IDs OK;| | | |If not OK--> Error msgs | | | | If OK, Response has: | | | |"HTTP-URL_FL-P_Continue_| |13) Msg Recvd, pgm Starts | <----- |NewLinkPair"; CitING IDs| |14) Verify CitING IDs OK | | | |15) If OK, sends MetaData | -----> |16) Receives MetaData & | | | | places in Database as | | | | "ForwardLink-Group" | |18) Receives MetaData & | <----- |17) Sends MetaData | | places in Database as | | | | "RetroLink-Group" | | | | and sends "Done" signal. | -----> |19) Rcvs "Done", sends | |20)Rcvs "Done Also"; Closes| <----- | "Done Also" and closes | |___________________________| |________________________| Don L. Jewett Expires December 17, 2015 Page 36 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.6 Legend: See the numbered paragraphs below for details about the Steps diagrammed here. (6.1) The Author, having completed the contribution for the NewerText-WebSite, opens a Browser and provides a URL of the NewerText-WebSite. The Browser makes the Internet connection. (6.2) The WebSite provides a means for the Author to start the WebSite's "FL-P_New_Upload" Software, and the Author does so. (6.3) The FL-P_New_Upload program sends to the Browser the Instructions on how to Upload the Author's Article and any ForwardLink-Protocol information. The details on this process will differ from WebSite to WebSite, and can be determined by the WebMaster. (6.4) The Author follows the Instructions and Uploads the Article Draft of the Contribution. If the Draft does not contain the contents of the "new file" of Step(5.22), above, then the "new file" is uploaded separately. (6.5) The "New Upload" Software initially processes the Upload(s) in the following SubSteps: (6.5a) The "New Upload" Software searches the Reference Section for any Citations that start or end with multiple semicolons. Upon finding such semicolons, the quadruple Semicolons at the start SHOULD be removed while leaving the rest of the Citation and the WebLink. (6.5b) All Content following the double Semicolon is deleted from the Reference Section and saved for use with the "FL- P_Create_CitING_IDs" module. Additionally, any identifying information about the CitING Text (such as the number in the References List, or the name-date) is saved. TechDetail: How the NewerText-WebSite incorporates the Author's *Article* (or Contribution) into the WebServer is outside the scope of the ForwardLink-Protocol. However, the NewerText-WebSite MUST use the "FL-P_New_Upload" Software- Module to search the Reference Section for the multiple Semicolons in order to recover the part of the Text-Content between the double and triple Semicolons so as to make it available to its Software-Module "FL-P_Start_NewLinkPair". (6.5c) If there is no Reference Section label in the Article or Contribution, then the "FL-P_New_Upload" Software-Module will search for the multiple Semicolons characters in the added "file" that has been also uploaded. If this search fails, then the Software-Module will search throughout the upload and, if the Semicolons are found, will place the Citation as specified by the WebAdmin in the Software-Module. If the multiple Semicolons are not found, then the Software-Module creates appropriate error messages to the Author. TechDetail: The "New Upload" Software MUST transmit the information about the CitING Text to the WebSite's Don L. Jewett Expires December 17, 2015 Page 37 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 "FL-P_Create_CitING_IDs" Software-Module. (End SubSteps of 6.5) (6.6) The "New Upload Software", if there are any errors found, MUST send Error Messages to the Author, so that they can be corrected. Such Messages MUST contain Instructions as to how to correct the errors, or whether or not the Author must go back to Step1, or to some other Step. When no errors are present, the "New Upload Software" MUST send an "OK" signal to the Browser. (6.7) When the Author receives the "OK" signal, the Browser is closed. (6.8) The Browser closes the Web Connections. (6.9) The WebSite sends information about the CitING Text and Article to the FL-P_Create_CitING_IDs Software-Module, which saves the data and MetaData that will identify to which Citation in which Article the data applies, and the Internet connection is closed. There then follows an indefinite Time Interval, depending upon how busy the NewerText-WebSite Server is, and whether other delays (such as time of day or available Internet speed) have been programmed by the WebAdmin. The WebAdmin MAY determine when the next steps occur, but the Interval SHOULD NOT be greater than 36 hrs. (6.10) At some unspecified time, the NewerText-WebSite processes the "New Upload" files for display on the WebSite. It also processes with respect to the FL-P, including the following SubSteps, among others: (6.10a) The FL-P_Create-CitING_IDs on the NewerText-WebSite creates the CitING IDs, following the same definitions and processes as occurred when the OlderText-WebSite created the CitED IDs, as detailed in SubSteps 5.11c,d,e of Fig.5. The Software-Module MUST also place any new entries into the Database, and also MUST populate all entries regarding the CitING Article, the CitING Text, and the CitING RetroLink. (6.10b) The 3 unique CitING IDs (ArticleID, TextID, RetroLinkID) are placed into the HTTP-URL_FL- P_Start_NewLinkPair. The CitED IDs were previously put into this HTTP-URL by the OlderText-WebSite, and they were labeled as "CitED". The CitING IDs MUST be labeled as "CitING". The URL for JSON-RPC messages *to* the NewerText-WebSite MUST also be included. The consequence is that the information in this HTTP-URL is sufficient to establish that the message from the NewerText-WebSite *to* the OlderText-WebSite is valid. It also provides the path to the NewerText-WebSite and the CitING ID information to validate the JSON-RPC-Response *from* the OlderText-WebSite. The word "valid" means that there have been preceding communications about the Linkage. Such validity reduces the usefulness of the ForwardLink-Protocol for malicious purposes. (6.10c) The NewerText-WebSite sends the HTTP-URL_FL- Don L. Jewett Expires December 17, 2015 Page 38 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 P_Start_NewLinkPair to the OlderText-WebSite, starting the inter-WebSite communications of the ForwardLink-Protocol. (End SubSteps of 6.10) (6.11) The message received by the OlderText-WebSite starts the FL-P_Start_NewLinkPair Software-Module. (6.12) The Software-Module in the OlderText-WebSite first verifies that the CitED IDs are correct and complete by checking the WebSite Database. An error causes Error messages to both WebAdmins. If the CitED IDs are correct, then the Software completes all Database entries in the "Article/Text-Group" (see Fig.7 and ListC3 in AppendixC). Next, the CitING IDs from the received message are copied and placed into an HTTP Response that starts the Software "FL-P_Continue_NewLinkPair", *and* contains the three CitING IDs that were included in the received message. Finally, the OlderText-WebSite sends the Response. (6.13) The NewerText-WebSite receives the Response and starts the "FL-P_Continue_NewLinkPair" Software-Module. (6.14) The Software validates the CitING IDs, following the same steps for checking and for errors as in Step 6.12. (6.15) If ID checks are OK, then the "FL-P_Send_MetaData" Software-Module sends the "Article/Text Group" MetaData from the Database. This Group, is shown in ListC3 of AppdxC. However, only the parts dealing with the Article, Text, and RetroLink are sent, as shown below. (Any "Repeat ... as needed" Categories are not included since such Categories, if needed, have already been entered into the Database.) Here is what is sent *from* the NewerText-WebSite (Article/Text Group) *to* the OlderText-WebSite (to be placed in the ForwardLink-Group), where the "<{" indicates that *all* MetaData within the named Category is sent. ThisList-Article#w Static MetaData<{ Dynamic MetaData<{ ThisList-Text#x Static Metadata<{ Dynamic Metadata<{ Link-List ThisList-RetroLink#y Dynamic Metadata<{ (6.16) The OlderText-WebSite receives the MetaData and places it in the ForwardLink-Group of its Database. Both the Label and the Content are saved in the Database. The "ThisList" words in ListC3 are either left off by the sending WebSite, or are removed by the receiving WebSite. Optionally, the words could be replaced by "NewerText", but they are not needed at this point; the words were placed in ListC3 to help Readers trying to understand the structure of the Database. All of the received MetaData Don L. Jewett Expires December 17, 2015 Page 39 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Categories are placed within the ForwardLink-Group of the ArticleID and TextID within the Database. Note that the location within the Database is determined by the three CitED IDs, originally created by this WebSite. This MetaData transfer is diagrammed in Fig.7. The receiving WebSite also checks the MetaData Categories that were sent to determine if any Categories were sent that are not in its "Article/Text Group". Any Categories not in the Group MUST be sent to the Author/Moderator/WebMaster to be considered for inclusion within the WebSite's MetaData. Changes or Additions to MetaData Categories can ONLY be done by a WebMaster, and MUST NOT be automatic. (6.17) The OlderText-WebSite sends the MetaData from the "Article/Text Group" to the NewerText-WebSite. The list of the MetaData Categories is the same as shown under Step6.15, above, *except* that the next-to-last item is "ThisList-ForwardLink#z". Again both Label and Content are both saved. (The time when *only* content is saved occurs later when the "FL-P_Update_MetaData" Software calls for an update when a Reader clicks a LinkIcon to see a SortableTable-- see Fig.3.) (6.18) Upon receipt of the MetaData, the NewerText-WebSite places it in the Database as the "RetroLink-Group" whose location is determined by the CitING IDs. The WebSite also checks for new MetaData Categories, as described in Step6.16. When finished, the WebSite sends a "Done" signal to the OlderText-WebSite. (6.19) The OlderText-WebSite, if done, sends "Done Also" and closes. (6.20) The NewerText-WebSite receives the "Done Also" signal and closes. *Note* that any WebSite that participates in the ForwardLink-Protocol MUST provide appropriate error messages for contingencies which may need them, even though such contingencies are NOT explicitly described herein. Note also that provisions MUST be available to easily reverse and remove a NewLinkPair if the Author/Moderator/WebMaster does not approve the LinkPair after review of the CitED Text, the CitING Text, and the NewerText-WebSite. After Review and Approval the OlderText- WebSite MUST send a message to the NewerText-WebSite that indicates "LinkPair approved". The OlderText-WebSite then puts the ForwardLink-Icon within its Content, and the NewerText-WebSite puts the RetroLink-Icon within its Content. These actions are needed to provide means to reduce fraudulent use of the ForwardLink-Protocol, and to ensure that the the usage is appropriate for the Readers of each WebSite. These procedures do NOT prevent usage of the ForwardLink-Protocol to create Links for other uses, but prevent inappropriate Linkages as judged by the Readers of the WebSites. Don L. Jewett Expires December 17, 2015 Page 40 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Any messages within the WebSites' Communications that are addressed to Author/Moderator/WebMaster/WebAdmin MUST be delivered to the correct person, and a Response MUST be sent to the Sending WebSite indicating that the message was delivered and MUST provide an email address for that person, or another person who can respond to messages from other WebSites. 2.5 MetaData Categories In the Databases, the MetaData MAY be arranged as the WebManagers wish. Remember that the only Texts in the ForwardLink-Protocol Database either are Citing another Text (a CitING Text) or are Cited by another Text (a CitED Text). The vast majority of Texts within Articles (or WebSites) will neither Cite nor be CitED. So, by not creating a TextID until a Text Cites or is Cited, the Database remains smaller than if the Database were made to accommodate all Texts. There is a corresponding saving of CPU cycles. In ListC3 of AppendixC, the structure of a proposed Database (for one Text having one RetroLink and one ForwardLink) is shown. This structure was created so that the MetaData could be easily separated into "Static" and "Dynamic" divisions in most places. The Dynamic MetaData is updated when there is a display of a SortableTable, whereas the Static MetaData is transmitted only once, during the formation of the RetroLink/ForwardLink Pair. The movement of MetaData from one place to another can be confusing because of the differing points-of-view possible during use of the ForwardLink-Protocol. Fig.7 is intended to help in understanding the situation. Realize that a given Text (with its unique TextID) can be either CitED or CitING, and this is determined by whether the Text has a RetroLink or has a ForwardLink, or *both*. Said in another way, a given Text of a pair of Texts can be either the Older-Text or the Newer-Text, as originally shown in Fig.1B. The Text's role determines the movement of the MetaData, as diagrammed in Fig.7. <> Don L. Jewett Expires December 17, 2015 Page 41 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.7 Title: The Movement of MetaData in the ForwardLink-Protocol between the two WebSites of the RetroLink/ForwardLink Pair. Abbreviations # = unique ID specific to a given SupraCategory C = a vertical line crosses over a horizontal line OlderText- NewerText- WebSite WebSite ____________________ ____________________ |ARTICLE/TEXT-GROUP| |ARTICLE/TEXT-GROUP| |IDs&MetaData from | |IDs&MetaData from | | THIS WebSite | | THIS WebSite | | .... .... | | .... .... | |Article# | |Article# | | Static MetaData |--->------+ +----<----| Static MetaData | | Dynamic MetaData|---->---+ | | +---<---| Dynamic MetaData| |Text# | | | | | |Text# | | Static MetaData |-->-+ | | | | +-<--| Static MetaData | | Dynamic MetaData|>\ | | | | | | /<| Dynamic MetaData| |+ ForwardLinkMetaD|->+ | | | | | | +<-|+ RetroLinkMetaD | |::::::::::::::::::| | | A A A A | | |::::::::::::::::::| |RETROLINK-GROUP | | | d s s d | | |RETROLINK-GROUP | |IDs&MetaData from | T T | | | | T T |IDs&MetaData from | |an OlderText-WebSi| d s | | | | s d |OlderText-WebSite | |(*not* shown here)| | | | | | | | | |(in *this* Figure)| | .... .... | | | | | | | | | | .... .... | |OlderText-Article#| T T | | | | | | |OldrTxt-Artcle# | | Static MetaData | d s | +--C-C--C-C->| Static MetaData | | Dynamic MetaData| | | +->--C-C--C-C->| Dynamic MetaData| |Older-Text# | | | | | | | |Older-Text# | | Static MetaData | | +--Ts-->-C-C--C-C->| Static MetaData | | Dynamic MetaData| | | | | |/>| Dynamic MetaData| |+ForwardLinkMetaD | +---Td--->-C-C--C-C->|+ ForwardLinkMetaD| |::::::::::::::::::| | | | | |::::::::::::::::::| |FORWARDLINK-GROUP | A A | | |FORWARDLINK-GROUP | |IDs&MetaData from | s d | | |IDs&MetaData from | |NewerText-WebSite | | | | | |a NewerTextWebSite| |(in *this* Figure)| | | | | |(*not* shown here)| |NewrText-Article# | | | T T |NewerText-Article#| | Static MetaData |<-----As-----+ | s d | Static MetaData | | Dynamic MetaData|<-----Ad-------+ | | | Dynamic MetaData| |Newer-Text# | | | |Newer-Text# | | Static MetaData |<------Ts---------+ | | Static MetaData | | Dynamic MetaData|<-\ | | Dynamic MetaData| |+ RetroLinkMetaD |<--------Td---------+ |+ RetroLinkMetaD | |__________________| |__________________| Don L. Jewett Expires December 17, 2015 Page 42 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.7 Legend: Several SupraCategories have IDs, and it is important to distinguish those made by the WebSite containing the Database, and those made by Other WebSites. This Figure indicates, for each Group, the specifying WebSite for *most* of the IDs in the Group. The WebSite that creates the IDs is specified in detail in the Lists shown in AppendixC. Note that one Group for each WebSite in Fig.7 does *not* show connections to another WebSite. To visualize such connections, one must imagine two additional WebSites, one on either side of those in the Figure. The WebSite on the far left would be OLDER than the "OlderText- WebSite" and the WebSite on the far right would be NEWER than the "NewerText-WebSite. These additional WebSites would provide the connections to the presently-unconnected Groups in this Figure, following the same pattern of connections as are shown. Finally, note that the the last entry in the "RetroLink Group" is a *ForwardLink*. The LinkPair created during the ForwardLink-Protocol is a RetroLink from the NewerText-WebSite *and* a ForwardLink from the OlderText-WebSite. When the Article/Text Group is copied from the OlderText-WebSite to the NewerText-WebSite, the name is *not* changed. (Similar opposites are found in the ForwardLink Group.) Fig.7 will be helpful in understanding the MetaData Lists of AppendixC, so Fig.7 is duplicated just before ListC1. 3. Security Considerations Communications in this Protocol MUST use HTTP/1.1 as described in the series of RFC's RFC 7230 through and including RFC 7235 [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], [RFC7235]. Thus, the ForwardLink-Protocol has the same security considerations as RFC 7230 [RFC7230], and RFC 7231 [RFC7231]. The older version HTTP/1.0 MUST NOT be used. HTTP or HTTPS MAY be used. Only GET and POST of the HTTP commands are utilized in the ForwardLink-Protocol, so any other HTTP command MUST be rejected should it reach the Protocol Software. This Protocol RECOMMENDS the use of JSON-RPC [JSON-RPC] and the use of a POST request. If JSON-RPC is used then the POST request MUST be used and GET MUST NOT be used. The POST request MUST have the following members: {"jsonrpc": "2.0", "method": "", "params": "", "id": "" }. Note: in JSON-RPC names *within* an Object MUST be unique. This is quoted from the latest JSON RFC [RFC7159]: "Generally, there are security issues with scripting languages. JSON is a subset of JavaScript but excludes assignment and invocation. Since JSON's syntax is borrowed from JavaScript, it Don L. Jewett Expires December 17, 2015 Page 43 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 is possible to use JavaScript's "eval()" function to parse JSON texts. This generally constitutes an unacceptable security risk, since the text could contain executable code along with data declarations. The same consideration applies to the use of eval()-like functions in any other programming language in which JSON texts conform to that language's syntax." The ForwardLink-Protocol uses JSON to label MetaData Categories and their contents, but otherwise does not use either JSON nor JSON-LD. The placement of executable code within any JSON-like elements within this Protocol MUST NOT be done, and any WebSite with such code MUST be blacklisted and its Links rejected. From RFC 7232, Sect.8, p.22: "An entity-tag can be abused in ways that create privacy risks. ... User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode." From RFC 7234, Sec.8, p36: "... the very use of a cache can bring about privacy concerns. ... Note that the Set-Cookie response header field [RFC6265] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields." From RFC 7233, Section 6.1, p. 19: "Unconstrained multiple range requests are susceptible to denial- of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts. Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason." 4. Interoperability Interoperability between WebSites having different search software and/or operating systems is ensured in the ForwardLink-Protocol by having a requirement that *each* Linked WebSite MUST provide the *host* and *path* portions of a valid HTTP1.1 GET or POST request Don L. Jewett Expires December 17, 2015 Page 44 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 to the *other* WebSite. Also, WebSites may use different Software, so long as the Software achieves the goals specified in the ForwardLink-Protocol. 5. IANA Considerations 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. [RFC6896] Barbato, S., Dorigotti, S., and T. Fossati, Ed., "SCS: KoanLogic's Secure Cookie Sessions for HTTP", RFC 6896, March 2013. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [RFC7232] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014. [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014. [RFC7235] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Don L. Jewett Expires December 17, 2015 Page 45 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. 6.2 Informative References [DublinCore] http://dublincore.org/documents/usageguide/ (accessed 2015-04-27) [JSON-RPC] http://www.jsonrpc.org/specification (accessed 2015-04- 09) [Larsen2010] Larsen PD, M von Ins: The rate of growth in scientific publication and the decline in coverage provided by Science Citation Index. Scientometrics. 84(3): 575-603. online doi: 10.1007/s11192-010-0202-z PMCID: PMC2909426 [Wikipedia Citation] http://en.wikipedia.org/wiki/Citation (accessed 2015-04-27). 7. Appendices 7.1 AppendixA (List of Required Elements) Below are cut/pastes from the body of this Informational Internet- Draft that contain statements about Required Elements, as defined in Section 1.1. p14: TechDetail: All ForwardLink-Protocol WebSites MUST use HTTP1.1 for Internet Communications. HTTPS MAY be used, and is RECOMMENDED because although the content carried by the ForwardLink-Protocol is intended to be freely available, it is possible that parts of the communications might be the basis for misusing the Protocol to affect the participating WebSites in ways not intended by the Protocol and in ways not useful to the creators of the WebSite. p14: The Display MUST include Link-Icons as specified in Step(2.6). p14: TechDetail: WebSites MUST use Link-Icons in Text-Displays. The ForwardLink-Icon MUST be a Helm Symbol (Unicode U+2388 or UTF-8 E2 8E 88) placed at the *start* of the Cited Text. p14: In a NewerText-WebSite, the RetroLink-Icon MUST be an Asterism symbol "3 asterisks"( Unicode U+2042, UTF-8 E2 81 82) that MUST be placed at the *end* of the CitING Newer-Text. p14: If a whole article or section in an OlderText-WebSite is CitED, then the ForwardLink-Icon MUST be placed at the beginning of the *title* of the article or of the section. p15: The Icons and their locations within the Text-Display, as described in this Step (2.6), are REQUIRED. If the specified Icon- symbols cannot be used, then other symbols MAY be used IF the meaning Don L. Jewett Expires December 17, 2015 Page 46 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 of the symbols is clearly specified to a Reader on *each page* that such an Icon occurs. However, the ForwardLink-Icon MUST be such that it can be easily picked out during a glance at the page. p15: In cases where the original text cannot be modified to include the required icons, the Link-Icons MAY be displayed using a transparent overlay. An Icon occupying just a single space is RECOMMENDED so as to allow display in texts that use only a single space between consecutive sentences. p14: (2.8a) Any FL-P- conforming WebSite, in response to the clicking of either type of Link-Icon, MUST send to the Browser two SortableTables of MetaData about the Text displaying the Link-Icon. One SortableTable contains MetaData regarding the *Text*, while the other SortableTable contains information about the *Article* (or WebSite) containing the Text (see Fig.3); this information is *not* the same (see AppendixC3). The SortableTable MetaData is stored in the WebSite's Database (see Fig.3 and AppendixC). p15: TechDetail: Each SortableTable MUST include ALL of the ForwardLinks that cite this Text, each Link in a separate Row. If there are too many ForwardLinks to fit in the Display, then a means to move the Display, or to truncate the Display, MUST be provided. (See also Fig.3.) p15: The format of both SortableTables MUST comply with any FL-P- Cookie on the Reader's Browser that has been created by the FL- P_Edit_Cookies Software-Module of *any* WebSite that conforms with the ForwardLink-Protocol. The Cookies MAY determine, among other parameters, the MetaData Categories to be displayed, their order in the SortableTable, which Row will be initially used for sorting the Table, and the direction of the Sort. p16: The Reader MUST be able to change these choices during the Display, either in the Display or in the stored Cookies. The Reader MUST be shown a list of available MetaData-Categories that are not in being Displayed at the time, nor specified by the Cookie being edited. p16: The Reader MUST be able to name and save different Cookie- files, each consisting of all of the cookies chosen at one time, so that multiple Reader-choice Cookies can be saved and later recovered for different projects and/or fields. These capabilities MUST be in the Software-Module "FL-P_Edit_Cookies". The Software-Module MUST provide an option to create a Cookie that, for some purposes, does *not* present the SortableTables (i.e. skipping this step). All Cookies MUST comply with RFC6896 [RFC6896]. The Reader MUST be offered access to the FL-P_Edit_Cookies Software-Module both before and after a Link-Icon has been clicked. p16: (2.8b) In addition to the Step(2.8a) actions, the Displaying WebSite MUST, after sending the SortableTable Display to the Reader's Browser with the data presently in the Database, send a request for an update of Dynamic MetaData to every WebSite for which the Database has a Link *for the Text* of the Reader-selected Link-Icon, whether Don L. Jewett Expires December 17, 2015 Page 47 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 currently listed in the SortableTable or not. The Display MUST indicate to the Reader "Dynamic Data Being Updated" or an equivalent. Note that this rule applies to displays of SortableTables for all Links, both RetroLinks and ForwardLinks. p16: TechDetail: Update requests MUST only be for Dynamic MetaData, and MUST NOT be sent if less than 7 days or 168 hours have elapsed since the last such request from the WebSite. This is to reduce the number of update requests to a single WebSite should an Article on that WebSite become popular. The latest Date/Time of an update request is found in AppendixC3 here: {...Link-List: ThisList- RetroLink#y: Date/Time last update request}. An analogous item is found in ThisList-ForwardLink#z. p16: The WebSites MAY negotiate what Protocol will be used is this Updating Process, but each WebSite MUST be able to use the JSON- RPC protocol [JSON-RPC]. When the Responses to the Update Request(s) are received by the requesting WebSite, the requesting WebSite MUST update the Dynamic MetaData in the Display on the Reader's Browser, and MUST provide an indication that the update has occurred. The requesting WebSite's Database MUST also be updated, including the date/time of the most recent request (see previous paragraph). If a WebSite is unable to give a proper Response to an Update Request, that WebSite MUST provide a clear Error-message that indicates what prevents the Update, along with Contact Information if appropriate. The Error-message MAY be displayed to the Reader, and MAY also be directed to the SiteAdmin of the Requesting WebSite. p17: Note: as specified in this protocol, neither WebSite checks to see if the Dynamic MetaData has actually changed. It is possible to check this, and then send only the MetaData that has changed. It seems possible that fewer computer-cycles may be needed to transmit all Dynamic MetaData, updated or not. Since reducing "Network-Load" and reducing CPU cycles at the WebSite are both worthwhile, this protocol specifies that the WebSite responding to an Update Request MAY EITHER 1) Send *all* Dynamic MetaData, whether updated or not, OR MUST 2) Determine which Dynamic MetaData has been updated, and *only* send updated MetaData. The Response must indicate which method was used. Each WebSite's Database MUST distinguish between Dynamic MetaData and Static MetaData for its own MetaData and for the MetaData of RetroLinks and ForwardLinks (see AppendixC, ListC3). If, for any reason, Static Metadata has changed, then such altered MetaData MUST be included in any Response to a "Request for Update of Dynamic MetaData." p17: TechDetail: In this Figure, we assume that the Reader has previously requested the Text-Preview to be displayed in a pop-up window because the Reader needs easy access to the Window of the SortableTable, in order to switch to another ForwardLink. The WebSite MUST offer at least two of the following three options (or equivalents): 1) New window (Reader returns by back-arrow); 2. New tab (Reader returns by closing tab or clicking previous tab); 3) a Don L. Jewett Expires December 17, 2015 Page 48 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Pop-up Window (Reader returns by closing window). p17: The Reader MUST be offered buttons or other controls that provide these functions: a) Display a list of Category-rows that are available in the Database, but are *not* currently displayed, b) Change the displayed Category-rows, c) Change the Row upon which the Table is sorted, d) Change the order of sorting on the chosen Row, and e) Return to the start of this Step(2.9) at any time. The last requirement (e) MUST be offered because, as the SortableTables will be used, it is likely that the Reader will look at several Text- Previews before Jumping to another WebSite. p18: TechDetail: A click in the SortableTable MUST display the Text-Preview in a manner that was chosen by the Reader (and recorded in any Cookie created as specified in the TechDetail of Step(2.9)). p18: (2.13) Using the "FL-P_Display_CitING_Text" Software-Module, the NewerText-WebSite sends the Browser a Page Display with the CitING Text near the middle. The Text MUST be highlighted or distinguishable in some way easy for the Reader. p19: By means of Cookies on the Reader's computer, the rows that the Reader has selected are presented in the order of the Reader's choice. The Reader can also choose the row upon which the data will be sorted, and the sorting-order-direction. In addition, the Display MUST show any MetaData-Categories that are available, but have not been chosen by the Reader, to be displayed, and MUST offer a means for the Reader to call for the Display of such data. p24-25: (5.3) The OlderText-WebSite sends a Page for the Browser to Display. The WebSite conforms with the ForwardLink-Protocol. Any WebSite that the conforms to the ForwardLink-Protocol MUST provide an easily seen and understood indication of that conformation, perhaps by a ForwardLinkProtocol-Icon and/or a Button labeled "Click HERE to Cite; create a ForwardLink to your work" (or equivalent). p25: TechDetail: The WebSite MUST provide either a Button, or some other means that is easily seen and understood by the Reader, on EACH Page that contains material that can be Linked. When activated, the means will start a program to obtain the initial data necessary for a RetroLink/ForwardLink Pair. Best Practice is for a virtual button to be displayed on each such page. If some keyboard characters are needed for action, then this information MUST be readily available, preferably on each page-display containing material that could be CitED. p25: The names of all Software-Modules used in the ForwardLink- Protocol MUST begin with the following 5 characters: FL-P_ . p25: WebSites that conform to the ForwardLink-Protocol MAY program the actions of the Software-Modules in any way, using any internal terms as desired. However, in Internet-Communications, the labels of the ForwardLink-Protocol MUST be used. If a ForwardLink- Protocol Internet-Communication lists a named FL-P Software-Module in an item starting "HTTP-URL", then the name assigned to the Software- Module by the WebSite MUST be included if it is different from the Don L. Jewett Expires December 17, 2015 Page 49 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 named Module. p25: The ForwardLink-Protocol provides descriptions of the functions needed and the communication requirements. Each WebSite MAY meet these specifications in any manner, and each WebSite MAY embellish or enhance the functions without restriction, but MUST NOT change any functions or communications if such changes affect ForwardLink-Protocol functions in, or communications with, other WebSites. p25: (5.7) The Software-Module "FL-P_Collect_ForwardLink_Info" on the OlderText-WebSite MUST send Instructions for the Author in a pop- up window (or equivalent), while the window containing the Text to be citED is still easily available to the Author for the steps that follow. p25-6: If the Author wishes to Cite a non-text object (such as a Figure, Spreadsheet, or Table), it is RECOMMENDED that the Author HighLight the Title or the Legend of the object. The WebSite MAY provide other means of indicating CitED non-text objects, but MUST provide the Author with easily-found instructions on their use, PREFERABLY on the same page as the object. p26: TechDetail: The limit on the number of characters is for the purposes of the Search for the Text. Later display is not limited by the ForwardLink-Protocol, though the WebSite MAY have display limits. For the Search, if the Text is too long, then the citED text is shortened and segmented by taking the first "x" characters and the last "y" characters (where x and y are set by the WebSite Admin -- default size = 50), and treating these two labeled segments as the citED Text for the purposes of a Search of the Text within the Article. The symbols that identify the two segments, and the size of the segments MAY be set by the WebSite Admin. The Author, after being told the reason for the size limit, is asked whether the two segments are OK, and the Author MAY adjust the size up to a total of 150 characters total (default). p26: TechDetail: The Search_Engine software SHOULD ignore LWS [Linear White Space] in both the citED text and in the WebSite if incorporating such LWS in the search might cause any ambiguity between searches, for example when using different Browsers. p26-7: If the Search has been *successful* within the Article, then the Search for Duplicates SHOULD NOT include any Version Control or History files. p27: If the search is *unsuccessful*, something is clearly wrong, since the Author has HighLighted something in the display of the OlderText-WebSite. Possible problems MUST be addressed: the Search MUST be expanded to include *all* parts of the WebSite where the Text might be found, including, but not limited to: Other Sections not searched, History files, Version Control files, Appendices, and Appended Content. If the Search is still unsuccessful, or if there are duplicates, an explanatory error signal is sent to the Author's Browser, and to the OlderText-WebSite Administrator. The program MAY Don L. Jewett Expires December 17, 2015 Page 50 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 provide additional information and options to the Author, or MAY otherwise halt or suspend the Protocol. p27: With a *successful* Search and no duplicates (excluding Version Control, History files, etc.), the Software next determines if any of the Text characters near (or before) the start of the Text, near (or after) the end of the Text, or within the Text characters, are either a RetroLink-Icon or a ForwardLink-Icon. If so, then this Text has been previously processed in the ForwardLink-Protocol, and has a previously-assigned TextID. This TextID, together with the Location of the CitED Text, MUST be transmitted to the Software- Module "FL-P_Collect_ForwardLink_Info", after which the Search Software quits. The "FL-P_Collect_ForwardLink_Info" Software-Module will use the previously assigned TextID (Step(5.12)), whether the Text was previously CitED or CitING. p27: The Location MAY be coded in any manner, but the code MUST be such as to be correctly processed by any of the FL-P Software-Modules that utilize the location-data, and by any other Software that the WebSite may use to find and/or Display the Text. p27: (5.11c) If there is no previously assigned TextID, then a unique ID (Identification) MUST be assigned to the *Text*. This is accomplished by the FL-P_Create_CitED_IDs Software (called by FL- P_Collect_ForwardLink_Info). The Software also determines what ArticleID was assigned to the Article when it was placed in the Database. The previous assignment of an ID for the Article MUST occur because when the Article is placed in the WebSite, the Article Static Metadata MUST be entered into the Database at that time. Such MetaData MUST include the Questions to be asked in Step(5.12). (The Software necessary for these actions are not part of the ForwardLink- Protocol.) p28: TechDetail: The IDs created are used primarily on the OlderText-WebSite, so the ID Method MAY be specified by the WebSite Admin. The Software MUST NOT create any TextID which is a duplicate ID within the entity over which software may search. For example, if the Text is within an Article, then the TextID MUST be unique within that one Article. The Software MUST verify that each TextID is unique within the boundaries of the next-larger unit. If the ID is not unique, the Software MUST create a new ID that is unique and MUST verify the uniqueness. Any one Text within an article MUST have the same TextID no matter whether it is a CitED Text of a RetroLink, or a CitING Text of a ForwardLink. p28: Since the TextID might be used maliciously, the ID SHOULD NOT be predictable based upon what can be obtained from the WebSite, or predictable from previous use of the ForwardLink-Protocol in legitimate communications with the WebSite. p28: TechDetail: The LinkID is used primarily on the OlderText- WebSite, and only on the specific Text specified by the CitED TextID, so the ID Method MAY be specified by the WebSite Admin. The Software MUST NOT create any LinkID which is a duplicate ID within the Links Don L. Jewett Expires December 17, 2015 Page 51 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 of the specific TextID, including both RetroLinks and ForwardLinks. The Software MUST verify that each LinkID is unique. If the ID is not unique, the Software MUST create a new ID that is unique and MUST verify the uniqueness. The Software MUST NOT re-use any LinkID that was used for a Link within the specific TextID, even if the LinkID is not currently in use. LinkIDs can be the *same* in *different* Texts (that have different Text-IDs). The limits placed on all IDs MUST match the requirements of the Database as it is used. p28: Since the LinkID might be used maliciously, the ID SHOULD NOT be predictable based upon what can be obtained from the WebSite, or predictable from previous use of the ForwardLink-Protocol in legitimate communications with the WebSite. Since each of the three IDs are unique within an ID's range, all three together describe a unique Link in a unique Text within a unique Article. Thus, the three Unique IDs form a functional "password" for the NewerText- WebSite to be validated for the OlderText-WebSite at the start of the communications necessary to create a NewLinkPair (described later re Fig.6). p29: (5.13) The Author answers the Questions and completes fill- in boxes with keyboard strokes, or chooses among alternatives by clicking check-boxes. The Last of the Questions MUST be "Do you want a standard Bibliographic Reference to the Text to be provided for you? <> <>". p29: The Software-Module "FL-P_Collect_ForwardLink_Info" MUST save the data in the Database. ListC3 in AppendixC shows suggested MetaData Categories. p29-30: (5.16) The OlderText-WebSite now creates Content that will be transferred to the Author's computer. The Author's Answer to the Last Question (see Step(5.13)) determines part of the Content. If the Answer is "Yes" the Content MUST consist of the following parts: starting with a quadruple Semicolon (;;;;), then the two parts separated by a double-Semicolon (;;), and ending with a triple Semicolon (;;;): p30: If the Answer to the Last Question (see Step(5.13)) is "No" or Null, then the Content consists of only items 3,4, and 5, above. The Content MUST start with a double Semicolon (;;) and end with a triple semicolon (;;;). p30: Otherwise, the WebSite's Administrators MUST choose one style most likely to be used by those CitING the Article, and offer at least the one style [Wikipedia Citation]. p31: TechDetails: The BibRef is a full bibliographic reference (citation) for the citED text, and MUST be for only a *single* citation. There MUST be one RetroLink/ForwardLink Pair for each of multiple Citations from a single Text. There MUST be a *different* RetroLink/ForwardLink Pair for each *different* CitING Text, whether or not the different CitING Texts refer to same CitED Text or not. These requirements occur because *each Link* has different data related to usage of the Link. Don L. Jewett Expires December 17, 2015 Page 52 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 p31: The BibRef MUST include, at the end, a WebLink that, if activated, can display on a Reader's Browser the CitED Text (placed in the middle of the Display). The URL of this WebLink is provided in "HTTP-URL_Display_CitED_Text". The WebLink MAY contain any WebAddress chosen by the Programmers/Administrators of the OlderText- WebSite. Within the Software-Modules of the ForwardLink-Protocol, the Software-Module "FLP_Display_CitED_Text" will perform this function (see AppendixB). p31: After the BibRef's WebLink, the program MUST place a double- Semicolon, and then MUST place an HTTP-URL line that, when used, will send data to the Software-Module "FL-P_Start_NewLinkPair" on the OlderText-WebSite. This HTTP-URL line will start the process of creating the RetroLink/ForwardLink Pair initiated by the Author. The HTTP_URL MUST include the Article-ID, the Text-ID, and the ForwardLink-ID, each labeled as a "CitED ID". Different items in the this line MUST be separated by single Semicolons. The end of the Content MUST be indicated by triple Semicolons. p31: (5.17) The OlderText-WebSite sends Instructions that describe the Steps that must be taken by the Author to complete the "Collect_ForwardLink_Info" process correctly. This Step MUST be done. p31: 1) Below is displayed Text-Content THAT YOU MUST SAVE on your computer. p32: This file MUST have, at the start of the Text-Content, 4 Semicolons (;;;;), and the Text-Content MUST end with 3 Semicolons (;;;). p32: This file MUST have, at the start of the Text-Content, 4 Semicolons (;;;;), and the Text-Content MUST end with 3 Semicolons (;;;). p32: ALSO be sure to include in the file's name or somewhere in the file's content, something that indicates which Article the file applies to and which Text in your Article is the CitING Text. Do NOT change any Content having multiple semicolons at the Start and End. p32: When you complete your Contribution to the WebSite, you can paste the Content into your Article, as described in 4.1, above. You may remove the 4 Semicolons (;;;;) but do NOT remove the other Semicolons or any other Content. p32: 5) Finally, NOW OR AT SOME FUTURE TIME, you MUST upload your Article, or other Contribution, to the WebSite that will post it on the Web. You MUST also upload the file of Step4.2) above, if you have not incorporated it's Content into your Contribution. p32: -|-|- Below is the Text-Content that you MUST Copy, Paste, Use, & Upload -|-|- p37: TechDetail: How the NewerText-WebSite incorporates the Author's *Article* (or Contribution) into the WebServer is outside the scope of the ForwardLink-Protocol. However, the NewerText- WebSite MUST use the "FL-P_New_Upload" Software-Module to search the Reference Section for the multiple Semicolons in order to recover the Don L. Jewett Expires December 17, 2015 Page 53 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 part of the Text-Content between the double and triple Semicolons so as to make it available to its Software-Module "FL- P_Start_NewLinkPair". p37: TechDetail: The "New Upload" Software MUST transmit the information about the CitING Text to the "FL-P_Create_CitING_IDs" on the NewerText-WebSite . p37-8: (6.6) The "New Upload Software", if there are any errors found, MUST send Error Messages to the Author, so that they can be corrected. Such Messages MUST contain Instructions as to how to correct the errors, or whether or not the Author must go back to Step1, or to some other Step. When no errors are present, the "New Upload Software" MUST send an "OK" signal to the Browser. p38: (6.10a) The FL-P_Create-CitING_IDs on the NewerText-WebSite creates the CitING IDs, following the same definitions and processes as occurred when the OlderText-WebSite created the CitED IDs, as detailed in SubSteps 5.11c,d,e of Fig.5. The Software-Module MUST also place any new entries into the Database, and also MUST populate all entries regarding the CitING Article, the CitING Text, and the CitING RetroLink. p38: (6.10b) The 3 unique CitING IDs (ArticleID, TextID, RetroLinkID) are placed into the HTTP-URL_FL-P_Start_NewLinkPair. The CitED IDs were previously put into this HTTP-URL by the OlderText-WebSite, and they were labeled as "CitED". The CitING IDs MUST be labeled as "CitING". The URL for JSON-RPC messages *to* the NewerText-WebSite MUST also be included. p39: The receiving WebSite also checks the MetaData Categories that were sent to determine if any Categories were sent that are not in its "Article/Text Group". Any Categories not in the Group MUST be sent to the Author/Moderator/WebMaster to be considered for inclusion within the WebSite's MetaData. p40: Note* that any WebSite that participates in the ForwardLink- Protocol MUST provide appropriate error messages for contingencies which need them, even though such contingencies are NOT explicitly described herein. p40: Note also that provisions MUST be available to easily reverse and remove a NewLinkPair if the Author/Moderator/WebMaster does not approve the LinkPair after review of the CitED Text, the CitING Text, and the NewerText-WebSite. After Review and Approval the OlderText- WebSite MUST send a message to the NewerText-WebSite that indicates "LinkPair approved". The OlderText-WebSite then puts the ForwardLink-Icon within its Content, and the NewerText-WebSite puts the RetroLink-Icon within its Content. These actions are needed to provide means to reduce fraudulent use of the ForwardLink-Protocol, and to ensure that the the usage is appropriate for the Readers of each WebSite. These procedures do NOT prevent usage of the ForwardLink-Protocol to create Links for other uses, but prevent inappropriate Linkages as judged by the Readers of the WebSites. p40: Any messages within the WebSites' Communications that are Don L. Jewett Expires December 17, 2015 Page 54 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 addressed to Author/Moderator/WebMaster/WebAdmin MUST be delivered to the correct person, and a Response MUST be sent to the Sending WebSite indicating that the message was delivered and MUST provide an email address for that person, or another person who can respond to messages from other WebSites. p43: Communications in this Protocol MUST use HTTP/1.1 or its updates, and thus has the same security considerations as RFC7230, and RFC7231. The older version HTTP/1.0 MUST NOT be used. HTTP or HTTPS MAY be used. Only GET and POST of the HTTP commands are utilized in the ForwardLink-Protocol, so any other HTTP command MUST be rejected should it reach the Protocol Software. p43: This Protocol RECOMMENDS the use of JSON-RPC [JSON-RPC] and the use of a POST request. If JSON-RPC is used then the POST request MUST be used and GET MUST NOT be used. The POST request MUST have the following members: {"jsonrpc": "2.0", "method": "", "params": "", "id": "" }. Note: in JSON-RPC names *within* an Object MUST be unique. p44: The ForwardLink-Protocol uses JSON to label MetaData Categories and their contents, but otherwise does not use either JSON nor JSON-LD. The placement of executable code within any JSON-like elements within this Protocol MUST NOT be done, and any WebSite with such code MUST be blacklisted and its Links rejected. p44: Interoperability between WebSites having different search software and/or operating systems is ensured in the ForwardLink- Protocol by having a requirement that *each* Linked WebSite MUST provide the *host* and *path* portions of a valid HTTP1.1 GET or POST request to the *other* WebSite. p44: Also, WebSites may use different Software, so long as the Software achieves the goals specified in the ForwardLink-Protocol. ----------------End AppendixA ----------------- 7.2 AppendixB (Software Modules & HTTP-URL Lines) The ForwardLink-Protocol Software is best explained as comprising several Software-Modules because of different processing needs at different times during the creation and use of the Links. The name of each Software-Module starts with "FL-P" (the abbreviation of the ForwardLink-Protocol). "Pg=" shows the Page(s) where the Software- Module is described. *Note*: *Each WebSite* MUST have *all* of the ForwardLink-Protocol Software-Modules, because any give Text can be the Older-Text for one Don L. Jewett Expires December 17, 2015 Page 55 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 RetroLink/ForwardLink Pair, and be the Newer-Text for *another* RetroLink/ForwardLink Pair (see Fig.1B). A LIST OF SOFTWARE-MODULES IN ORDER OF MENTION IN THIS INFORMATIONAL INTERNET-DRAFT p = page(s) upon which the Software-Module is mentioned FL-P_Display_SortableTable p: 15, FL-P_Edit_Cookies p: 15,16, FL-P_Update_MetaData p: 17,40 FL-P_Start_NewLinkPair p: 18,29,31,34,38, FL-P_Display_CitING_Text p: 18, FL-P_Collect_ForwardLink_Info p: 25,26,27,29, FL-P_Search_CitED_Text p: 26,27, FL-P_Create_CitED_IDs p: 27,28, FLP_Display_CitED_Text p: 31 FL-P_New_Upload p: 37, FL-P_Create_CitING_IDs p: 37,38, FL-P_Continue_NewLinkPair p: 39, FL-P_Send_MetaData p.39 A LIST OF HTTP-URL LINES IN ORDER OF MENTION IN THIS INFORMATIONAL INTERNET-DRAFT p = page(s) upon which the Line is mentioned NOTE: Some Lines are NOT Software-Modules in the ForwardLink- Protocol. Only the lines that contain "FL-P_" are Software-Modules. Those without the letters are Software-Modules whose function is named, but exist in a WebSite's Software tools; and need to be named according to what Software the HTTP line should be addressed to. HTTP-URL_FLP_Start_NewLinkPair p: 30,34,38, HTTP-URL_Display_CitED_Text p: 31,34, HTTP-URL_FL-P_Continue_NewLinkPair p: 36, HTTP-URL_Display_CitED_Article p: 64,67, HTTP-URL_Display_Text p: 66,68,72, HTTP-URL_FL-P_Send_MetaData p: 66,68,72, HTTP-URL_FL-P_UpDate_MetaData p: 66,68,72, ----------------End AppendixB ----------------- <> Don L. Jewett Expires December 17, 2015 Page 56 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 7.3 AppendixC (Possible MetaData SupraCategories & Categories) Below are *examples* of categories of MetaData, and how they might be organized. The examples are based on the *assumption* that each *WebSite* is devoted to multiple Articles, and each Article is devoted to *just one topic*, though there may be Sections within the Article. This structure should be kept in mind in going over the MetaData Categories below. If one Library Archive is a WebSite divided into Journals, each Journal divided into Issues, each Issue divided into Articles, then MetaData to encompass the entirety of the Archive will need to have an enlarged hierarchy of Categories for the Journals, Issues, and Articles, in addition to the list below. The "Article" listed below is the equivalent of a single Article in this Library Archive example. The MetaData list below has *not* been correlated with the Dublin Core [Dublin Core]. For some WebSites such a correlation may well be needed, and might be the subject a further RFC addressed to those special needs.The intention of this Protocol Design is for it to be *flexible*, so documented changes that make it better adaptable to other uses are encouraged, as relevant RFC's. The MetaData Information MAY be transmitted between Servers or WebSites by whatever means the two WebSites can negotiate. However, every WebSite compliant with ForwardLink-Protocol MUST offer JSON-RPC as one alternative. All of the communicated MetaData MUST be transmitted in JSON. Because of the number of MetaData-Categories can only increase, a topic for future development may well be some means of making the categorization more efficient. The size of the MetaData is large. The good part is that this can *all* be done by computers! Rapidly! And the availability of inexpensive Hard-Drive memory means that the MetaData-size need not be a limiting factor. NB: Fig.7 will be of help in understanding the transmission of MetaData during the creation of a RetroLink/ForwardLink Pair, and during Link-use of SortableTables, so a copy of Fig.7 duplicated here: <> Don L. Jewett Expires December 17, 2015 Page 57 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.7 Title: The Movement of MetaData in the ForwardLink-Protocol between the two WebSites of the RetroLink/ForwardLink Pair. Abbreviations # = unique ID specific to a given SupraCategory C = a vertical line crosses over a horizontal line OlderText- NewerText- WebSite WebSite ____________________ ____________________ |ARTICLE/TEXT-GROUP| |ARTICLE/TEXT-GROUP| |IDs&MetaData from | |IDs&MetaData from | | THIS WebSite | | THIS WebSite | | .... .... | | .... .... | |Article# | |Article# | | Static MetaData |--->------+ +----<----| Static MetaData | | Dynamic MetaData|---->---+ | | +---<---| Dynamic MetaData| |Text# | | | | | |Text# | | Static MetaData |-->-+ | | | | +-<--| Static MetaData | | Dynamic MetaData|>\ | | | | | | /<| Dynamic MetaData| |+ ForwardLinkMetaD|->+ | | | | | | +<-|+ RetroLinkMetaD | |::::::::::::::::::| | | A A A A | | |::::::::::::::::::| |RETROLINK-GROUP | | | d s s d | | |RETROLINK-GROUP | |IDs&MetaData from | T T | | | | T T |IDs&MetaData from | |an OlderText-WebSi| d s | | | | s d |OlderText-WebSite | |(*not* shown here)| | | | | | | | | |(in *this* Figure)| | .... .... | | | | | | | | | | .... .... | |OlderText-Article#| T T | | | | | | |OldrTxt-Artcle# | | Static MetaData | d s | +--C-C--C-C->| Static MetaData | | Dynamic MetaData| | | +->--C-C--C-C->| Dynamic MetaData| |Older-Text# | | | | | | | |Older-Text# | | Static MetaData | | +--Ts-->-C-C--C-C->| Static MetaData | | Dynamic MetaData| | | | | |/>| Dynamic MetaData| |+ForwardLinkMetaD | +---Td--->-C-C--C-C->|+ ForwardLinkMetaD| |::::::::::::::::::| | | | | |::::::::::::::::::| |FORWARDLINK-GROUP | A A | | |FORWARDLINK-GROUP | |IDs&MetaData from | s d | | |IDs&MetaData from | |NewerText-WebSite | | | | | |a NewerTextWebSite| |(in *this* Figure)| | | | | |(*not* shown here)| |NewrText-Article# | | | T T |NewerText-Article#| | Static MetaData |<-----As-----+ | s d | Static MetaData | | Dynamic MetaData|<-----Ad-------+ | | | Dynamic MetaData| |Newer-Text# | | | |Newer-Text# | | Static MetaData |<------Ts---------+ | | Static MetaData | | Dynamic MetaData|<-\ | | Dynamic MetaData| |+ RetroLinkMetaD |<--------Td---------+ |+ RetroLinkMetaD | |__________________| |__________________| Don L. Jewett Expires December 17, 2015 Page 58 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 Fig.7 Legend: Several SupraCategories have IDs, and it is important to distinguish those made by the WebSite containing the Database, and those made by Other WebSites. This Figure indicates, for each Group, the specifying WebSite for *most* of the IDs in the Group. The WebSite that creates the IDs is specified in detail in the Lists below. Note that one Group for each WebSite in Fig.7 does *not* show connections to another WebSite. To visualize such connections, imagine two additional WebSites, one on either side of those in the Figure. The WebSite on the far left would be OLDER than the "OlderText- WebSite" and the WebSite on the far right would be NEWER than the "NewerText-WebSite. These additional WebSites would provide the connections to the presently-unconnected Groups in this Figure, following the same pattern of connections as are shown. Finally, note that the the last entry in the "RetroLink Group" is a *ForwardLink*. The LinkPair created during the ForwardLink-Protocol is a RetroLink from the NewerText-WebSite *and* a ForwardLink from the OlderText-WebSite. When the Article/Text Group is copied from the OlderText-WebSite to the NewerText-WebSite, the name is *not* changed. (Similar opposites are found in the ForwardLink Group.) Overview of List Presentation in AppendixC: ListC1 is a bare list containing ONLY SupraCategory and Category Headings, matching Fig.7. *All* of the Lists are based upon a single *Text#* having a single RetroLink and a single ForwardLink. Locations for Additional Links are shown as "Repeat": "Addl. ______as needed". ListC2 enlarges on ListC1, to show JSON labeling, and to include "List" items that will expand in ListC3 to become multiple JSON "Elements" (Key:Value Pairs). Thus, the basic structure of ListC1 can now be seen to include other JSON entries. ListC3 expands the "List" of ListC2 (that is, the single-line multiple-Elements), giving a complete list of the Database contents for a single *Text#*. Hopefully, confusions that arise from looking at ListC3 may be resolved by returning to earlier Lists in order to see the underlying "skeleton". <> Don L. Jewett Expires December 17, 2015 Page 59 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 (Continuing unused space) <> ---- ListC1: EXPLAINING THE DATABASE LABELING ---- | = a marker to aid the Reader in judging the amount of indentation. # = A *singular or plural* Abbreviation for "ID" (an Identification), which implies one or more identifiable item(s) whose ID(s) will be created and used later. #x is an # that has been created and put into the Database and is represented by the letter for purposes of the List and Figures. #_ is an # whose ID is created by *another* WebSite. ATG is the abbreviation of "Article/Text Group". The "Groups" are *not* used in the JSON labeling. They are used only for labeling within the ForwardLink-Protocol and in Figures. Note that *most* of the labeling is based upon IDs created by the WebSite that contains *ThisList*. But, the labeling from *other* WebSites bears the IDs from those WebSites. The basis of the labeling is clearer if you refer back to Fig.7, above, when something is unclear. *Note* that Fig.7 shows MetaData *about a Link*, which is sent at the same time as "Dynamic MetaData" of Text#x. Note *further* that in a LinkPair, one WebSite's Link is a RetroLink, while the other WebSite's matching link (same LinkPair) has a ForwardLink, so that the same MetaData has a different "label" on different WebSites. This can be seen in the List below where the "ThisList-RetroLink#y" data contains MetaData from the OlderText WebSite with a "OlderText-ForwardLink#" label. Don L. Jewett Expires December 17, 2015 Page 60 INTERNET DRAFT The ForwardLink-Protocol June 15, 2015 ThisList-Database ThisList-Article#w <-Start ThisList-Text#x-ARTICLE/TEXT GROUP| Static MetaData | Dynamic MetaData If OTHER Text is ..., then ... | | 1. Older, then this data + RetroLin | ThisList-Text#x Dynamic MetaData goes TO | Static MetaData OlderText-WebSite, ForwardLink-Group|--+ Dynamic MetaData --- OR --- | | Link-List 2. Newer, then this data + ForwardLink| | Dynamic MetaData goes TO | | NewerText-WebSite, RetroLink-Group| | | | | ThisList-RetroLink#y (ForwardLink part of ATG below)| | Dynamic MetaData ________________________________| | ---------------- | OlderText-MetaData <-Start RETROLINK#y GROUP | | OlderText-Article#_ | A Static MetaData This Group's data FROM| T Dynamic MetaData the Article/Text-Group| G OlderText-Text#_ of CitED Older-Text | | Static MetaData WebSite Database | | Dynamic MetaData | | Link-List | | OlderText-ForwardLink#_ | | Dynamic MetaData _____________| | | ---------------------------------- | Addl ThisList-RetroLink# from Text#x (part of ATG) | | | | | |--+ ThisList-ForwardLink#z (ForwardLink part of ATG here)| | Dynamic MetaData _________________________________| | ---------------- | NewerText-MetaData