Internet DRAFT - draft-dljewett-forwardlinkprotocol
draft-dljewett-forwardlinkprotocol
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.
<<Unused Space to better format the next page>>
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.
<<Space here left unused to better present the next page>>
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").
<<Space here left unused to better present the next page>>
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*.|
|____________________________________________________________|
<<Space here left unused to better present the next page>>
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.
<<Space here left unused to better present the next page>>
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? <<Yes>> <<No>>".
(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 <<HERE>> 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
<<HERE>> 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.
<<Space here left unused to better present the next page>>
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.
<<Space here left unused to better present the next page>>
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
<IANA considerations text>
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? <<Yes>> <<No>>".
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 -----------------
<<Space here left unused to better present the next page>>
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:
<<Space here left unused to better present the next page>>
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".
<<Space here left unused to better present the next page>>
Don L. Jewett Expires December 17, 2015 Page 59
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
(Continuing unused space)
<<Space here also left unused to better present the next page>>
---- 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 <Start FORWARDLINK#z GROUP | |
NewerText-Article#_ | |
Static MetaData This Group's data FROM| |
Dynamic MetaData the Article/Text-Group| A
NewerText-Text#_ of CitING Newer-Text | T
Static MetaData WebSite Database | G
Dynamic MetaData | |
Link-List | |
NewerText-RetroLink#_ | |
Dynamic MetaData ______________| |
| ---------------------------------- |
Addl ThisList-ForwardLink# from Text#x (part of ATG) |--+
| _________________________________|
Addl ThisList-Text# in ThisList-Article#w
|
Addl ThisList-Article# in ThisList-Database
Don L. Jewett Expires December 17, 2015 Page 61
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
ListC1 comment: Note that, because of the hierarchy with JSON, the
Article/Text Group has 3 parts as indicated by the vertical ATG-line
on the right side.
Also Note that what determines whether the RetroLink "part" or the
ForwardLink "part" is transmitted (see Fig.7), depends upon whether
the Text of the ThisList-WebSite is the Newer or Older of the two
Texts being Linked.
---- End of ListC1 ----
---- ListC2 below ----
ListC2 is a copy of ListC1, but using JSON-RPC Objects [JSON-RPC].
IDs that are specified by *This* WebSite are shown thusly: #a, where
"a" is assigned by the WebSite during the formation of a
RetroLink/ForwardLink Pair. IDs created by *Other* WebSites are
shown by #_ .
The items In ListC1 labeled as "Addl" are now shown in lines
starting "Repeat".
{"ThisList-Database": {
"START": "Article/Text GROUP",
"ThisList-Article#w": {
"Static MetaData": "List",
"Dynamic MetaData": "List",
"ThisList-Text#x": {
"Static MetaData": "List",
"Dynamic MetaData": "List",
"Link-List": {
"START": "RetroLink Alternative part of Article/Text GROUP",
"ThisList-RetroLink#y": {
"Dynamic MetaData": "List",
"END": "RetroLink Alternative part of Article/Text GROUP"
"END": "This part of Article/Text GROUP",
"START": "RetroLink GROUP",
"OlderText-MetaData": {
"OlderText-Article#": {
"Static MetaData": "List",
"Dynamic MetaData": "List",
"OlderText-Text#": {
"Static MetaData": "List",
"Dynamic MetaData": "List",
"Link-List": {
Don L. Jewett Expires December 17, 2015 Page 62
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"OlderText-ForwardLink#_": {
"Dynamic MetaData": "List"
}
}
}
}
},
"END": "RetroLink GROUP",
},
"START": "Another part of Article/Text GROUP"
"Repeat": "Addl ThisList-RetroLink#" as needed",
"START": "ForwardLink Alternative part Article/Text GROUP",
"ThisList-ForwardLink#z": {
"Dynamic MetaData": "List",
"END": "ForwardLink Alternative part of Article/Text GROUP",
"END": "Another part of Article/Text GROUP",
"START": "ForwardLink GROUP",
"NewerText-MetaData": {
"NewerText-Article#_": {
"Static MetaData": "List",
"Dynamic MetaData": "List",
"NewerText-Text#_": {
"Static MetaData": "List",
"Dynamic MetaData": "List",
"Link-List": {
"NewerText-RetroLink#_": {
"Dynamic MetaData": "List"
}
}
}
}
}
"END": "ForwardLink GROUP",
},
"START": "Last part of Article/Text GROUP",
"Repeat": "Addl ThisList-ForwardLink# as needed",
"END": "Last part of Article/Text GROUP",
}
},
"Repeat": "Addl ThisList-Text# as needed",
},
"Repeat": "Addl ThisList-Article# as needed"
}}
---- End ListC2 ----
Don L. Jewett Expires December 17, 2015 Page 63
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
---- START ListC3 ----
ListC3 is a copy of ListC2, but with each "List" entry expanded to
"Label": "Content" pairs that carry the MetaData Information from one
WebSite to the other, using JSON-RPC. The "" marks imply a string of
characters.
The JSON-RPC structure [JSON-RPC] allows an HTTP-POST request to
easily transfer whole Categories. The Structure below has been
designed so that the transfers can be specified at the level of
"Static Metadata" or "Dynamic Metadata".
Blank lines are inserted to make the Categories and Groups
somewhat easier to see. The "START" indicators imply the "END" of the
previous Category (not labeled).
Abbreviations
# = unique ID within a given SupraCategory or Category
#x = a specific ID
#_ = an unspecified ID (to be specified *later*)
"Database" : {
"START": "ARTICLE#/TEXT# GROUP",
"Note": All IDs in this Group, created by THIS WebSite",
"ThisList-Article#w": {
"Static MetaData": {
"Title": null,
"Subtitle": null,
"Author": null,
"Author-Info": null,
"Moderator": null,
"Moderator-Info": null,
"Standard, Full BibRef": null,
"Keywords": null,
"Field of Interest": null,
"Sub-Field of Interest": null,
"HTTP-URL_Display_CitED_Article": null,
"Cookie-Keyword(s)": null,
"Language": null,
"Is content open-access?": null,
"Is MetaData open-access?": null,
"Minimum Math BackGround Needed": null,
"Minimum Statistics BackGround Needed": null,
"Questions for CitING-Author": {
Question A1": null
Don L. Jewett Expires December 17, 2015 Page 64
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
}
"Repeat": "Addl Questions as needed",
"Contact info": {
"Author email": null,
"Moderator email": null,
"WebAdmin email": null
}
}
"Dynamic MetaData": {
"Date of Last Update of Article Dynamic MetaData": null,
"Total Number of ForwardLinks in Article": null,
"Number of new ForwardLinks in Article each Month": null,
"Number of new RetroLinks in Article each Month": null,
"Number Total WebLinks in Article": null,
"Number Total non-WebLink References in Article": null,
"Number Total of Reader Visits to Article": null,
"Number of Reader Visits to Article each Month": null,
"Number Total Pages/Words in Article": null,
"Different MetaData-Categories from Other Articles": {
"Category name": null,
"URL of Article with new Category": null,
"Date this name first Received": null,
"Keywords of other Article": null,
"Field of Interest of other Article": null,
"Disposition of this Category": null,
"Date of Disposition": null
},
"Repeat": "Addl Different MetaData-Categories as needed"
},
},
"ThisList-Text#x": {
"Static MetaData": {
"Date First Posting of Text in this Article": null,
"ID of Article#_": null
"ID of Text#_": null
"Text of Text#_": null,
"Preview of Text#_": null,
"Author": null,
"Author-Info": null,
"Moderator": null,
"Moderator-Info": null,
"HTTP-URL_Display_Text": null,
"HTTP-URL_FL-P_Send_MetaData": null,
"HTTP-URL_FL-P_UpDate_MetaData": null,
"Location within Article": null,
Don L. Jewett Expires December 17, 2015 Page 65
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"Section within Article (if used)": null,
"Questions to CitING-Author, specific to Text#_": {
"Question T1": null,
}
"Repeat": "Questions specific to Text#_ as needed",
"Contact Info": {
"Author email": null,
"Moderator email": null,
"WebAdmin email": null
},
},
"Dynamic MetaData": {
"Date Last Update to this Dynamic MetaData": null,
"Date Last Change to Text": null,
"Total Number of RetroLinks from Text": null,
"Total Number Clicks of Text from RetroLinks": null,
"Total Number of ForwardLinks from Text": null,
"Total Number Clicks of Text from ForwardLinks": null,
"Nbr new ForwardLinks from Text each Month": null,
"List of Article#() Comments about Text": null"
"Link-List": {
"START": "RetroLink Alternative of Article/Text GROUP",
"Note": "All Link-IDs created by THIS WebSite.",
"ThisList-RetroLink#y": {
"Dynamic MetaData": {
"ID of RetroLink#_": null,
"Location of RetroLink-Icon": null,
"ID of Text#_": null,
"Date/Time last update request": null,
"Date this Link created": null,
"Date Last Update this MetaData": null,
"Date this RetroLink Last Followed": null,
"Monthly % Readers followed Link": {
"Fraction Numer (Nbr Rdrs followed Link)": null,
"Fraction Denom (Nbr Rdrs saw LinkData)": null,
"Computed % (Numer / Denom) * 100": null
},
"Total % Readers follow Link":{
"Total Monthly Reader Sum-Numer": null,
"Total Monthly Reader Sum-Denom": null,
"Computed % (Sum Numer / Sum Denom) * 100": null
},
}
"END": "RetroLink Alternative of Article/Text GROUP",
Don L. Jewett Expires December 17, 2015 Page 66
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"END": "This part of ARTICLE#/TEXT# GROUP",
"START": "RetroLink GROUP",
"Note": "All IDs from OlderText WebSite",
"Older-Text MetaData": {
"OlderText-Article#_": {
"Static Metadata": {
"Title": null,
"Subtitle": null,
"Author": null,
"Author-Info": null,
"Moderator": null,
"Moderator-Info": null,
"Standard, Full BibRef": null,
"Keywords": null,
"Field of Interest": null,
"Sub-Field of Interest": null,
"HTTP-URL_Display_CitED_Article": null,
"Cookie-Keyword(s)": null,
"Language": null,
"Minimum Math BackGround Needed": null,
"Minimum Statistics BackGround Needed": null,
"Questions for CitING-Author": {
Question A1": null
}
"Repeat": "Addl Questions as needed",
"Contact info": {
"Author email": null,
"Moderator email": null,
"WebAdmin email": null
}
}
"Dynamic MetaData": {
"Date of Last Update of Article Dynamic MetaData": null,
"Total Number of ForwardLinks in Article": null,
"Number new ForwardLinks in Article each Month": null,
"Number of new RetroLinks in Article each Month": null,
"Number Total WebLinks in Article": null,
"Number Total non-WebLink References in Article": null,
"Number Total of Reader Visits to Article": null,
"Number of Reader Visits to Article each Month": null,
"Number Total Pages/Words in Article": null,
"Different MetaData-Categories from Other Articles": {
"Category name": null,
"URL of Article with new Category": null,
"Date Category first Received": null,
"Keywords of other Article": null,
Don L. Jewett Expires December 17, 2015 Page 67
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"Field of Interest of other Article": null,
"Disposition of this Category": null,
"Date of Disposition": null
}
"Repeat": "Addl Diff. MetaData-Categories as needed",
}
"OlderText-Text#_": {
"Static Metadata": {
"Date First Posting of Text in this Article": null,
"ID of Article#_": null,
"ID of Text#_": null,
"Text of Text#_": null,
"Preview of Text#_": null,
"Author": null,
"Author-Info": null,
"Moderator": null,
"Moderator-Info": null,
"HTTP-URL_Display_Text": null,
"HTTP-URL_FL-P_Send_MetaData": null,
"HTTP-URL_FL-P_UpDate_MetaData": null,
"Location within Article": null,
"Section within Article (if used)": null,
"Questions to CitING-Author, specific to Text#": {
"Question T1": null,
}
"Repeat": "Addl Questions--as needed"
"Contact Info": {
"Author email": null,
"Moderator email": null,
"WebAdmin email": null
}
"Dynamic MetaData": {
"Date Last Update to this Dynamic MetaData": null,
"Date Last Change to Text": null,
"Total Number of RetroLinks from Text": null,
"Total Number Clicks of Text from RetroLinks": null,
"Total Number of ForwardLinks from Text": null,
"Total Number Clicks of Text from ForwardLinks": null,
"Nbr new ForwardLinks from Text each Month": null,
"List of Article#(w) Comments about Text": null
}
"Link-List": {
"OlderText-ForwardLink#_": {
"Dynamic MetaData": {
"ID of ForwardLink#_": null,
Don L. Jewett Expires December 17, 2015 Page 68
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"Location of ForwardLink-Icon": null,
"ID of Text#_": null,
"Date/Time last update request": null,
"Questions to & Answers from CitING Author": {
"Question T1": null,
"Answer T1": null,
"Question A1": null,
"Answer A1": null,
},
"Repeat": "Addl Questions & Answers as needed",
"Keywords entered by Author": null,
"Other entries by Author": null,
"Date this Link created": null,
"Date Last Update this MetaData": null,
"Date this Link Last Followed": null,
"Monthly % Readers followed Link": {
"Fraction Numer (Nbr Rdrs followed Link)": null,
"Fraction Denom (Nbr Rdrs saw LinkData)": null,
"Computed % (Numer / Denom) * 100": null
},
"Total % Readers follow Link":{
"Total Monthly Reader Sum-Numer": null,
"Total Monthly Reader Sum-Denom": null,
"Computed % (Sum Numer / Sum Denom) * 100": null
}
}
}
}
}
}
}
"END": "RetroLink GRoup",
},
"START": "Another part of Article/Text GROUP",
"Repeat": "RetroLink#_, as needed",
"START": "ForwardLink Alternative of Article/Text GROUP",
"Comment": "IDs from ThisList WebSite",
"ThisList-ForwardLink#z": {
"Dynamic MetaData": {
"ID of ForwardLink#_": null,
"Location of Link-Icon": null,
"ID of Text#_": null,
"Date/Time last update request": null,
"Questions to & Answers from CitING Author": {
Don L. Jewett Expires December 17, 2015 Page 69
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"Question T1": null,
"Answer T1": null,
"Question A1": null,
"Answer A1": null,
},
"Repeat": "Addl Questions & Answers as needed",
"Keywords entered by Author": null,
"Other entries by Author": null,
"Date this Link created": null,
"Date Last Update this MetaData": null,
"Date this ForwardLink Last Followed": null,
"Monthly % Readers follow Link": {
"Fraction Numer (Nbr Rdrs followed Link)": null,
"Fraction Denom (Nbr Rdrs saw LinkData)": null,
"Computed % (Numer / Denom) * 100": null
},
"Total % Readers follow Link":{
"Total Monthly Reader Sum-Numer": null,
"Total Monthly Reader Sum-Denom": null,
"Computed % (Sum Numer / Sum Denom) * 100": null
}
},
},
"END": "ForwardLink Alternative of Article/Text GROUP",
"Repeat": "Addl ForwardLink#_ as needed",
"END": "Another part of Article/Text GROUP",
"START": "ForwardLink GROUP",
"Comment": IDs below from Newer-Text WebSite",
"NewerText-MetaData": {
"NewerText-Article#_": {
"Static Metadata": {
"Title": null,
"Subtitle": null,
"Author": null,
"Author-Info": null,
"Moderator": null,
"Moderator-Info": null,
"Standard, Full BibRef": null,
"Keywords": null,
"Field of Interest": null,
"Sub-Field of Interest": null,
"HTTP-URL_Display_CitED_Article": null,
"Cookie-Keyword(s)": null,
"Language": null,
"Minimum Math BackGround Needed": null,
Don L. Jewett Expires December 17, 2015 Page 70
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"Minimum Statistics BackGround Needed": null,
"Questions for CitING-Author": {
"Question A1": null
}
"Repeat": "Addl Questions as needed",
"Contact info": {
"Author email": null,
"Moderator email": null,
"WebAdmin email": null
}
}
"Dynamic Metadata": {
"Date of Last Update of Article Dynamic MetaData": null,
"Total Number of ForwardLinks in Article": null,
"Number new ForwardLinks in Article each Month": null,
"Number of new RetroLinks in Article each Month": null,
"Number Total WebLinks in Article": null,
"Number Total non-WebLink References in Article": null,
"Number Total of Reader Visits to Article": null,
"Number of Reader Visits to Article each Month": null,
"Number Total Pages/Words in Article": null,
"Additional MetaData-Categories from Other Articles": {
"Category name": null,
"URL of Article with new Category": null,
"Date Category first Received": null,
"Keywords of other Article": null,
"Field of Interest of other Article": null,
"Disposition of this Category": null,
"Date of Disposition": null
}
"Repeat": "Addl MetaData-Categories as needed"
}
"NewerText-Text#_": {
"Static Metadata": {
"Date First Posting of Text in this Article": null,
"ID of Article#_": null,
"ID of Text#x_": null,
"Text of Text#_": null,
"Preview of Text#_": null,
"Author": null,
"Author-Info": null,
"Moderator": null,
"Moderator-Info": null,
"HTTP-URL_Display_Text": null,
"HTTP-URL_FL-P_Send_MetaData": null,
"HTTP-URL_FL-P_UpDate_MetaData": null,
"Location within Article": null,
"Section within Article (if used)": null,
Don L. Jewett Expires December 17, 2015 Page 71
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
"Questions to CitING-Author, specific to Text#": {
"Question T1": null
}
"Repeat": "Addl Questions as needed",
"Contact Info": {
"Author email": null,
"Moderator email": null,
"WebAdmin email": null
},
}
"Dynamic MetaData": {
"Date Last Update to this Dynamic MetaData": null,
"Date Last Change to Text": null,
"Total Number of RetroLinks from Text": null,
"Total Number Clicks of Text from RetroLinks": null,
"Total Number of ForwardLinks from Text": null,
"Total Number Clicks of Text from ForwardLinks": null,
"Number new ForwardLinks from Text each Month": null,
"Comments in Article#w about Text#x": {
"Comment 1": null,
},
"Repeat": "Addl Comments as needed",
}
"Link-List": {
"NewerText-RetroLink#_": {
"Dynamic MetaData": {
"ID of RetroLink#_": null,
"Location of Link-Icon": null,
"ID of Text#_": null,
"Date/Time last update request": null,
"Date this Link created": null,
"Date Last Update this MetaData": null,
"Date this ForwardLink Last Followed": null,
"Monthly % Readers follow Link": {
"Fraction Numer (Nbr Rdrs followed Link)": null,
"Fraction Denom (Nbr Rdrs saw LinkData)": null
"Computed% (Numer / Denom) * 100": null
}
"Total--% Readers follow Link":{
"Total Monthly Reader Sum-Numer": null,
"Total Monthly Reader Sum-Denom": null,
"Computed% (Sum Numer / Sum Denom) * 100": null
}
}
}
}
Don L. Jewett Expires December 17, 2015 Page 72
INTERNET DRAFT The ForwardLink-Protocol June 15, 2015
}
}
}
"END": "ForwardLink GROUP",
}
"START": "Last part of Article/Text GROUP",
"Repeat": "Addl ThisList-ForwardLink#_ as needed",
"END": "Last part of Article/Text GROUP",
}
},
"Repeat": "Addl ThisList-Text#_ as needed"
},
"Repeat": Addl ThisList-Article#_ as needed"
}}
(Please check all JSON in this Draft with a JSON Validator-- there is no
certainty that all commas are correct.)
----------------End AppendixC -----------------
Acknowledgements
The WYSIWYG Nroff Editor was immensely helpful and time-saving. Many
thanks to Stefan Santesson of 3XA Security.
The ideas in early versions were discussed many times with Drs.
Robert Plantz, Bill Baird, and Dana Rottach. The Author thanks them
for their time and patience. Dr. Rottach invented the idea of
transmitting some MetaData via the Author in a copy/paste, which
helped development.
Robert Plummer has done some of the programming of ForwardLink-
Protocol, which brought out hidden flaws.
Without the help from the grant from the National Library of
Medicine, this work would never have been done (see Section 1.5).
Author's Address
Don L. Jewett
69 Ridge Ave.
Mill Valley, CA 94941
US
email: dlj@abratech.com
or don.jewett@ucsf.edu
Don L. Jewett Expires December 17, 2015 Page 73
