Web Rules, Requirements, and Preferences

[AdamSobieski]

Introduction

Presented here are new techniques involving: (1) uses of <link> metadata elements to reference any rules, requirements, or preferences pertaining to hypertext documents and their elements (e.g., from style guides or rubrics), (2) a JSON-LD ontology to represent these rules, requirements, and preferences, and (3) interoperation with a potential Decisions API to verify documents and their elements with respect to these rules, requirements, and preferences.

Requirements and preferences can describe hypertext documents and their elements, including with respect to their semantics, pragmatics, stylistics, grammaticality, and vocabulary.

Definitions

A Rule can conditionally perform one or more actions. Rules are created using a reduced set of nestable abstract computational operators.

A Requirement is a Rule which can conditionally produce one or more Message, Warning, or Error instances about a document or its elements, e.g., when its conditions aren't met.

A Preference is a Rule which can conditionally produce one or more Cost or Score instances about a document or its elements. These would be summed across documents and their elements. Costs would be sought to be minimized while scores would be sought to be maximized.

Use Cases

Considered use cases include, but are not limited to: (1) natural-language engineering design, (2) both single-author and collaborative writing and editing scenarios, including those involving natural-language generation by artificial-intelligence systems, (3) the automated analysis, evaluation, and assessment of natural-language hypertext documents, and (4) enhancing scholarly and scientific communication.

Examples

The following example shows how Web Requirements could be referenced from hypertext documents using <link> metadata elements.

<html>
  <head>
    <link rel="rules" href="article-34969.jsonld" />
    <link rel="rules" href="encyclopedia-article.jsonld" />
    <link rel="rules" href="biographical-article.jsonld" />
  </head>
  <body>
    <article class="biography">
      <section class="introduction">
        <p>
          <span class="sentence">Benjamin Franklin (January 17, 1706 – April 17, 1790) was an American polymath active as a physicist, philosopher, statesman and inventor who was one of the Founding Fathers of the United States.<span>
          <span class="sentence">He was a drafter and signer of the Declaration of Independence, and the first postmaster general.</span>
        </p>
        <p>
          <span class="sentence">Born in the Province of Massachusetts Bay, Franklin became a successful newspaper editor and printer in Philadelphia, the leading city in the colonies, publishing The Pennsylvania Gazette at age 23.</span>
          <span class="sentence">He became wealthy publishing this and Poor Richard's Almanack, which he wrote under the pseudonym "Richard Saunders".</span>
          <span class="sentence">After 1767, he was associated with the Pennsylvania Chronicle, a newspaper known for its revolutionary sentiments and criticisms of the policies of the British Parliament and the Crown.</span>
          <span class="sentence">He pioneered and was the first president of the Academy and College of Philadelphia, which opened in 1751 and later became the University of Pennsylvania.</span>
          <span class="sentence">He organized and was the first secretary of the American Philosophical Society and was elected its president in 1769.</span>
          <span class="sentence">He was appointed deputy postmaster-general for the British colonies in 1753, which enabled him to set up the first national communications network.</span>
        </p>
        ...
      </section>
      ...
    </article>
  </body>
</html>

An article-specific resource, article-34969.jsonld, might include JSON-LD content resembling:

[
  {
    "@context": "http://standard.org/",
    "@type": "Data",
    "data": {
      "subject": {
        "fullName": "Benjamin Franklin",
        "dateOfBirth": "January 17, 1706",
        "dateOfDeath": "April 17, 1790",
        "occupation": [
          "politician",
          "publisher",
          "printer",
          "political theorist",
          "postmaster",
          "inventor",
          "political activist",
          "statesperson",
          "diplomat",
          "dilettante",
          "polymath",
          "chess player",
          "designer",
          "musician",
          "political philosopher",
          "autobiographer",
          "librarian",
          "journalist",
          "economist",
          "physicist",
          "editor",
          "writer",
          "philosopher",
          "naturalist",
          "book printer"
        ]
      }
    }
  }
]

A general-purpose, reusable resource, encyclopedia-article.jsonld, might include JSON-LD content resembling:

[
  {
    "@context": "http://standard.org/",
    "@id": "http://encyclopedia.org/requirements/neutrality",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article p",
      "as": "x",
      "do": {
        "@type": "Question",
        "question": "Does `x` have a neutral and objective tone?",
        "as": "conf",
        "do": {
          "@type": "Interval",
          "using": "conf",
          "lessThan": "0.5",
          "do": {
            "@type": "Error",
            "on": "x",
            "message": "This paragraph must have a neutral and objective tone."
          }
        }
      }
    }
  }
]

A general-purpose, reusable resource, biographical-article.jsonld, might include JSON-LD content resembling:

[
  {
    "@context": "http://standard.org/",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article.biography p",
      "as": "x",
      "do": {
        "@type": "Question",
        "question": "Does `x` mention {{data.subject.fullName}}?",
        "as": "conf",
        "do": {
          "@type": "Interval",
          "using": "conf",
          "greaterThanOrEqual": "0.5",
          "do": {
            "@type": "Question",
            "question": "Is `x` respectful of {{data.subject.fullName}}?",
            "as": "conf2",
            "do": {
              "@type": "Interval",
              "using": "conf2",
              "lessThan": "0.5",
              "do": {
                "@type": "Error",
                "on": "x",
                "message": "This paragraph must be respectful of {{data.subject.fullName}}."
              }
            }
          }
        }
      }
    }
  },
  {
    "@context": "http://standard.org/",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article.biography > section.introduction > p:first-of-type > span.sentence:first-of-type",
      "as": "x",
      "do": {
        "@type": "Question",
        "question": "Does `x` indicate that {{data.subject.fullName}} was born {{data.subject.dateOfBirth}}?",
        "as": "conf",
        "do": {
          "@type": "Interval",
          "using": "conf",
          "lessThan": "0.5",
          "do": {
            "@type": "Error",
            "on": "x",
            "message": "First sentence must indicate that {{data.subject.fullName}} was born {{data.subject.dateOfBirth}}."
          }
        }
      }
    }
  },
  {
    "@context": "http://standard.org/",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article.biography > section.occupations",
      "as": "x",
      "do": {
        "@type": "ForEachData",
        "value": "data.subject.occupation",
        "as": "o",
        "do": {
          "@type": "Question",
          "question": "Does `x` mention that {{data.subject.fullName}} was a {{o}}?",
          "as": "conf",
          "do": {
            "@type": "Interval",
            "using": "conf",
            "lessThan": "0.5",
            "do": {
              "@type": "Error",
              "on": "x",
              "message": "This section must mention that {{data.subject.fullName}} was a {{o}}."
            }
          }
        }
      }
    }
  }
]

Processing Rules, Requirements, and Preferences

Parallel Processing

Independent rules, requirements, and preferences could be processed concurrently, in parallel.

Hierarchical Processing

Rules, requirements, and preferences could have child items, via a children property, such that each child would have to be verified for the parent item to be verified.

Since JSON-LD is utilized, developers could use @id to identify rules, requirements, or preferences and then refer to these by identifier with respect to this children property or by means of an inverse parent property. This latter inverse parent property would enable extensibility with respect to interrelating rules, requirements, and preferences provided in multiple resources.

Hierarchical capabilities can enable the aggregation of nested messages, warnings, and errors.

Click here to toggle display of an example.

[
  {
    "@context": "http://standard.org/",
    "@id": "http://encyclopedia.org/requirements/neutrality",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article",
      "as": "x",
      "do": {
        "@type": "TryCatch",
        "try": {
          "@type": "AggregateTry",
          "do": {
            "@type": "AllChildRules"
          }
        },
        "catch": [
          {
            "@type": "AggregateCatch",
            "collect": [
              "Error"
            ],
            "do": {
              "@type": "AggregateError",
              "on": "x",
              "message": "This article must have a neutral and objective tone."
            }
          },
          {
            "@type": "AggregateCatch",
            "collect": [
              "Warning"
            ],
            "do": {
              "@type": "AggregateWarning",
              "on": "x",
              "message": "This article may need to be reviewed with respect to its neutrality and objectivity."
            }
          },
          {
            "@type": "AggregateCatch",
            "collect": [
              "Message"
            ],
            "do": {
              "@type": "AggregateMessage",
              "on": "x",
              "message": "This article has messages with respect to its neutrality and objectivity."
            }
          }
        ]
      }
    }
  },
  {
    "@context": "http://standard.org/",
    "@type": "Requirement",
    "parent": {
      "@id": "http://encyclopedia.org/requirements/neutrality"
    },
    "do": {
      "@type": "ForEachCssSelection",
      "using": "x",
      "value": ":scope section > p",
      "as": "y",
      "do": {
        "@type": "Question",
        "question": "Does `y` have a neutral and objective tone?",
        "as": "conf",
        "do": {
          "@type": "Interval",
          "using": "conf",
          "lessThan": "0.5",
          "do": {
            "@type": "Error",
            "on": "y",
            "message": "This paragraph does not have a neutral and objective tone."
          }
        }
      }
    }
  }
]

Multi-step Processing

Rules, requirements, and preferences could indicate that they were to be processed before or after one another. They could be scheduled for processing in multiple steps or stages.

Perhaps Requirement instances could be placed into ad-hoc classes, categories, steps, or stages which could be interrelated as occurring before and after one another.

Task-based Processing

From scheduled sequences of steps to hierarchical tree models of steps, provided steps or stages could also be Task instances, these instances having hierarchical subtasks, capable of providing global task scope data atop any tasks and subtasks occurring within individual rules, requirements, and preferences.

Individual rules, requirements, and preferences could indicate themselves as being elements of overarching global Task instances which could be traversed in a hierarchical manner during processing.

Workflow-based Processing

By analyzing sets of rules, requirements, and preferences, and other objects, alongside their interrelationships and interdependencies, software could create workflows with which to verify documents and their elements.

Knowledge Graphs

With the capabilities to query and update knowledge graphs, one could create semantic rules. These might resemble something like the following example.

Click here to toggle display of an example.

[
  {
    "@context": "http://standard.org/",
    "@type": "Rule",
    "do": {
      "@type": "DeclareVariables",
      "as": [
        "x",
        "y",
        "z"
      ],
      "do": {
        "@type": "ForEachMatch",
        "content": [
          {
            "@type": "Statement",
            "subject": "{{variable x}}",
            "predicate": "http://example.org/hasFather",
            "object": "{{variable y}}"
          },
          {
            "@type": "Statement",
            "subject": "{{variable y}}",
            "predicate": "http://example.org/hasBrother",
            "object": "{{variable z}}"
          }
        ],
        "do": {
          "@type": "Insert",
          "content": {
            "@type": "Statement",
            "subject": "{{term x}}",
            "predicate": "http://example.org/hasUncle",
            "object": "{{term z}}"
          }
        }
      }
    }
  }
]

Rules, requirements, or preferences would also be able to select document elements and conditionally update knowledge graphs depending upon interactions with a potential Decisions API. Other objects would later be able to query these knowledge graphs in the process of verifying documents and their elements.

One could use the id attribute in coordination with documents' URLs or base attribute values to obtain IRI nodes for documents' elements. For those elements without id attributes, blank nodes could be provided. A table could be utilized to provide the same blank nodes for the same elements, upon repeated requests. In this way, one could obtain either an IRI node or a blank node for any document element.

Click here to toggle display of an example.

[
  {
    "@context": "http://standard.org/",
    "@type": "Rule",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article.biography > section.events > p",
      "as": "x",
      "do": {
        "@type": "ForEachData",
        "value": "data.subject.events",
        "as": "e",
        "do": {
          "@type": "Question",
          "question": "Does `x` mention `e.text`?",
          "as": "conf",
          "do": {
            "@type": "Interval",
            "using": "conf",
            "greaterThanOrEqual": "0.5",
            "do": {
              "@type": "Insert",
              "content": [
                {
                  "@type": "Statement",
                  "subject": "{{element-to-term x}}",
                  "predicate": "http://example.org/mentionsEvent",
                  "object": "{{term e.id}}",
                  "confidence": "{{conf}}"
                }
              ]
            }
          }
        }
      }
    }
  }
]

Click here to toggle display of an example.

[
  {
    "@context": "http://standard.org/",
    "@type": "Rule",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article section.argument",
      "as": "a",
      "do": [
        {
          "@type": "Insert",
          "content": [
            {
              "@type": "Statement",
              "subject": "{{element-to-term a}}",
              "predicate": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type",
              "object": "http://example.org/Argument"
            }
          ]
        },
        {
          "@type": "ForEachCssSelection",
          "using": "a",
          "value": "span.claim",
          "as": "c",
          "do": {
            "@type": "ForEachCssSelection",
            "using": "a",
            "value": "span.support",
            "as": "s",
            "do": [
              {
                "@type": "Insert",
                "content": [
                  {
                    "@type": "Statement",
                    "subject": "{{element-to-term s}}",
                    "predicate": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type",
                    "object": "http://example.org/Statement"
                  },
                  {
                    "@type": "Statement",
                    "subject": "{{element-to-term a}}",
                    "predicate": "http://example.org/hasStatement",
                    "object": "{{element-to-term s}}"
                  },
                  {
                    "@type": "Statement",
                    "subject": "{{element-to-term c}}",
                    "predicate": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type",
                    "object": "http://example.org/Claim"
                  },
                  {
                    "@type": "Statement",
                    "subject": "{{element-to-term a}}",
                    "predicate": "http://example.org/hasClaim",
                    "object": "{{element-to-term c}}"
                  }
                ]
              },
              {
                "@type": "Question",
                "question": "Does `s` support the claim `c`?",
                "as": "conf",
                "do": {
                  "@type": "Interval",
                  "using": "conf",
                  "greaterThanOrEqual": "0.5",
                  "do": {
                    "@type": "Insert",
                    "content": {
                      "@type": "Statement",
                      "subject": "{{element-to-term s}}",
                      "predicate": "http://example.org/supports",
                      "object": "{{element-to-term c}}",
                      "confidence": "{{conf}}"
                    }
                  }
                }
              }
            ]
          }
        }
      ]
    }
  }
]

Notes

1. Must ensure that structured data, document content, and instructions intended for use with a potential Decisions API are safe and secure.
2. Should instructions for use with a potential Decisions API be model-agnostic or should they, instead, be capable of being model-specific, e.g., having model-specific threshold values?
   1. Could use templating to process accompanying data into numerical threshold values.
3. Could process noul-related responses using switch/case/default semantics on floating-point intervals. That is, could branch based on floating-point intervals with respect to a numerical noul response.

Click here to toggle display of an example.

[
  {
    "@context": "http://standard.org/",
    "@id": "http://encyclopedia.org/requirements/neutrality",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article p",
      "as": "x",
      "do": {
        "@type": "Question",
        "question": "Does `x` have a neutral and objective tone?",
        "as": "conf",
        "do": [
          {
            "@type": "Interval",
            "using": "conf",
            "lessThan": "0.75",
            "do": {
              "@type": "Error",
              "on": "x",
              "message": "This paragraph must have a neutral and objective tone."
            }
          },
          {
            "@type": "Interval",
            "using": "conf",
            "greaterThanOrEqual": "0.75",
            "lessThan": "0.90",
            "do": {
              "@type": "Warning",
              "on": "x",
              "message": "This paragraph may need to be reviewed with respect to its neutrality and objectivity."
            }
          }
        ]
      }
    }
  }
]

4. In addition to noul-related capabilities, choice-related and score-related capabilities could be made available through structures drawing inspiration from switch/case/default. That is, could branch based on choice responses and, perhaps, floating-point intervals with respect to choice responses' confidence scores.

Click here to toggle display of an example.

[
  {
    "@context": "http://standard.org/",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachCssSelection",
      "value": "article section.argument",
      "as": "a",
      "do": {
        "@type": "ForEachCssSelection",
        "using": "a",
        "value": "span.claim",
        "as": "c",
        "do": {
          "@type": "ForEachCssSelection",
          "using": "a",
          "value": "span.support",
          "as": "s",
          "do": {
            "@type": "Choice",
            "question": "Does the statement `s` support the claim `c`?",
            "criteria": [
              {
                "@type": "Criterion",
                "label": "supports",
                "description": "The statement directly supports or clearly entails the claim."
              },
              {
                "@type": "Criterion",
                "label": "contradicts",
                "description": "The statement states or clearly implies the opposite.",
                "as": "conf",
                "do": [
                  {
                    "@type": "Interval",
                    "using": "conf",
                    "lessThan": "0.5",
                    "do": {
                      "@type": "Warning",
                      "on": [
                        "c",
                        "s"
                      ],
                      "message": "This statement may contradict the claim."
                    }
                  },
                  {
                    "@type": "Interval",
                    "using": "conf",
                    "greaterThanOrEqual": "0.5",
                    "do": {
                      "@type": "Error",
                      "on": [
                        "c",
                        "s"
                      ],
                      "message": "The statement contradicts the claim."
                    }
                  }
                ]
              },
              {
                "@type": "Criterion",
                "label": "insufficient",
                "description": "Relevant, but not enough to establish the claim.",
                "as": "conf",
                "do": [
                  {
                    "@type": "Interval",
                    "using": "conf",
                    "lessThan": "0.5",
                    "do": {
                      "@type": "Warning",
                      "on": [
                        "c",
                        "s"
                      ],
                      "message": "This statement might not establish the claim."
                    }
                  },
                  {
                    "@type": "Interval",
                    "using": "conf",
                    "greaterThanOrEqual": "0.5",
                    "do": {
                      "@type": "Error",
                      "on": [
                        "c",
                        "s"
                      ],
                      "message": "The statement does not establish the claim."
                    }
                  }
                ]
              },
              {
                "@type": "Criterion",
                "label": "unrelated",
                "description": "The statement does not address the claim.",
                "as": "conf",
                "do": [
                  {
                    "@type": "Interval",
                    "using": "conf",
                    "lessThan": "0.5",
                    "do": {
                      "@type": "Warning",
                      "on": [
                        "c",
                        "s"
                      ],
                      "message": "The statement may be unrelated to the claim."
                    }
                  },
                  {
                    "@type": "Interval",
                    "greaterThanOrEqual": "0.5",
                    "do": {
                      "@type": "Error",
                      "on": [
                        "c",
                        "s"
                      ],
                      "message": "The statement is unrelated to the claim."
                    }
                  }
                ]
              }
            ]
          }
        }
      }
    }
  }
]

5. With respect to updating and querying knowledge graphs, expressiveness could include annotating statements with confidence scores.
6. Explore how SPARQL could be utilized.
   1. This might involve a ForEachSparqlSelection component.
7. Explore how SHACL could be utilized.
   1. Steps or stages might require that a knowledge graph be valid per SHACL content or SHACL resources to proceed.
   2. SHACL validation result messages could be interoperable with the envisioned messages, warnings, errors system.
8. If a potential Decisions API supports multimodal capabilities, could extend the Web Requirements conceptual model to include support for multimodality. Developers would be able to easily select and include images as inputs to multimodal decision models.
9. What about also making decisions with respect to documents' layouts and elements' styles? In theory, this could be achieved using window.getComputedStyle(element, pseudoElement) and perhaps the CSSOM.
10. What about also making decisions with respect to documents' elements' attributes' values?
11. What about also making decisions with respect to documents' elements' text values?
    1. This would entail being able to store elements' innerText values into variables to be provided to decision models.
12. It remains to be determined how document immutability and mutability (e.g., contenteditable), including per element, may factor into Web Requirements.
    1. It remains to be determined how results caching, including per element, may be realized.
       1. Could cached results for served versions of documents be provided, e.g., in JSON-LD data blocks or from <link> metadata?
    2. In theory, for mutable documents, during steps and stages, the processing of rules, requirements, and preferences could add CSS classes to and remove them from documents' elements.
       1. This might modify subsequent processing while potentially providing feedback to document editors in the form of visual styling.
13. Determining whether factual statements that need citations have citations should be possible with Web Requirements.
14. Verifying bibliographic citations should be possible with Web Requirements.
    1. Examples will use: (1) markup solutions for inline citations, and/or (2) CSS Selectors Level 5 Reference Combinators with markup solutions for bibliographies and their entries.
15. Could provide a ForEachSentence component to iterate sentences in selected documents' elements so that <span class="sentence"> markup would not be necessary to provide sentence-granular functionalities. Such a component might use Intl.Segmenter to segment selected text content into sentences.
16. Consider how to use CSS @namespace rules for selectors in ForEachCssSelection components.
    1. Perhaps an optional namespaces property which would provide a single object or array of objects each having a prefix and iri.
17. Also include ForEachXPathSelection components.
    1. Similarly, will need a means for handling XML namespaces, perhaps namespaces property on these components.
18. Special hyperlinks in message property values would be useful.

Click here to toggle display of an example.

[
  {
    "@context": "http://standard.org/",
    "@type": "Requirement",
    "do": {
      "@type": "ForEachXPathSelection",
      "value": ".//article//p",
      "as": "x",
      "do": {
        "@type": "Question",
        "question": "Does `x` have a neutral and objective tone?",
        "as": "conf",
        "do": {
          "@type": "Interval",
          "using": "conf",
          "lessThan": "0.5",
          "do": {
            "@type": "Error",
            "on": "x",
            "message": "<a href='x'>This paragraph</a> must have a neutral and objective tone."
          }
        }
      }
    }
  }
]

19. One could create components of use for indicating systems' tasks and goals.
    1. These components would go in do properties and provide do properties. They could be easily used to provide hierarchical tasks or goals pertaining to the processing of rules, requirements, and preferences. These data could accompany messages, warnings, and errors in the form of stacks' traces.
    2. These hierarchical tasks would have applicability to systems' states and to telemetry.
       1. Compare with System.Diagnostics.Activity and OpenTelemetry.
    3. Building on hyperlinks, above, one could use the as property in a Task to assign it to a symbol to refer to in nested subtasks' message property values.
       1. For example: "In order to accomplish <a href='supertask'>the supertask</a>, will use the Decisions API to ask...".

{
  "@type": "Task",
  "message": "...",
  "as": "...",
  "do": {  }
}

20. Similarly, authorial tasks and goals for hypertext documents and their elements (e.g., sections) could be useful to express.
    1. These metadata could, for example, be provided by student authors or by writing teachers in documents (templates) or in rules, requirements, and preferences for writing assignments.
    2. These components could make use of updating and querying knowledge graphs.
    3. Outlines or traversal paths resulting from these components could be incorporated into automatically-generated prompts.

{
  "@type": "AuthorialTask",
  "message": "...",
  "on": "...",
  "as": "...",
  "do": {  }
}

21. While a primary focus of Web Requirements is, thus far, on interoperation with a potential Decisions API, one could include functionality supporting end-users being able to enter into dialogues with artificial-intelligence writing assistants to improve their documents.
    1. Various data available with messages, warnings, or errors, then, could be used when prompting LLMs.
       1. For example: "You are a helpful writing assistant; a student is writing a biographical article about Benjamin Franklin; that student is supposed to narrate the main events of Benjamin Franklin's life in a section; this is the current revision of that section; here are the messages, warnings, and errors about that section received from tools processing rules, requirements, and preferences accompanying the assignment; the student is requesting assistance; the student says: X."
22. Might need Minimum and Maximum components for processing multiple questions' responses into resultant values, e.g. questions that were paraphrases of one another.
23. Question instances' expected responses could be interrelated using their @id property values via fuzzy-logical expressions and assertions. This could be useful for indicating that questions were paraphrases of one another, implied by one another, logically equivalent, logically mutually exclusive, or otherwise related via usage of conjunction, disjunction, and negation in more intricate expressions.
24. Could outlines, either provided by users or obtained via automatic reverse outlining, be of use for analyzing and evaluating documents? Could some rules, requirements, and preferences operate on documents' outlines? See also: The Computational Representation of Outlines w3c-cg/adaptation#46 .

Conclusion

What do you think about these ideas? Thank you.