User:Jeblad/Collected workpackages

Collected work packages is automated document composition whereby smaller work descriptions are collected into larger descriptions, describing a complete path from one state to another. Often this is done to describe a sequence of steps to be done in a construction or repair formula. A simpler description could be that it acts like a dynamic manual or cookbook.

The concept is often referred to as work packages, but it is more general than just what you do as "work". It is a sequence of actions or descriptions that bring the actor or reader from one node to another along the shortest path.

Algorithm

Assume there are a subset of tags, and that each work description has such tags. They are probably best implemented as page properties. For each work description there is a previous tag and a next tag. An upstream work description will have a next tag, and a downstream work description will have a previous tag. If the next and previous tags are the same, then a path exist. A complete collected work package forms a complete path from a start state to a final state, where each is given by a start tag and a final tag.

A more formal description would be that a work package is a sequence of descriptions along the shortest path from a starting node to an end node, where descriptions are attached to the transitions between nodes.

On the surface this is a known problem, with good solutions, although it can be computational intensive to find the solution. At a slightly deeper level there are problems, in particular it must be possible to infer if a particular transition moves closer to a solution. Without some measure of "closeness" the search for solutions will be of ${\textstyle \operatorname {O} \left(\prod _{i}^{m}{n_{i}}\right)}$, where n is the number of proposed nodes and m is the length of the sequence. With increasing m this will create an overwhelming workload. Several simplifications can be done, given various assumptions, leading to a search in linear time for specific cases.

An extension to this is how to extend the basic work package with additional work packages. This relationship can be tracked by adding tags for explicit extensions. It is possible to add a separate page prop for how to extend a specific sequence to include extra nodes.

The proposed algorithm has no inherit direction, except for what is defined as the starting and ending points, but some work procedures have differences in forward and backward direction. It is although possible to add extra attributes to the page prop to enforce directedness.

Examples

There are a few notable examples of possible use in a wiki, and a Wikimedia wiki in particular.

Wikidata

Work packages can describe how to add or remove properties, especially how some properties should be used with qualifiers in special configurations. There are no obvious closeness measure, except number of work steps, but as the sequences are rather short the workload should be manageable.

Wikivoyage

Work packages can describe travel routes between waypoints, with possible extensions along scenery routes. The closeness measure will be the distance to the target point, possibly with adjustment for scenery values or similar. Because Wikivoyage lacks a lot of descriptions of important scenery points, they could be imported from Wikipedia as short descriptions.

Wikipedia

Work packages can describe learning paths, like a kind of reading list on how a topic build on other topics. A possible closeness measure could be how remote a topic is from some other topic, and whether the topic properly describes the basics necessary for understanding some other topic. This can be estimated as a language overlap from the upstream (earlier) article into the downstream (later) article.