close
Jump to content

Wikifunctions:Type proposals/Abstract sentence

From Wikifunctions

Summary

This proposal is an attempt to represent in an abstract way the content of Abstract Wikipedia.

Comparison with competing proposals

This is an alternative to other proposals like Syntactic tables and Semantic units, that try to solve the same problem. Both of these have some issues, that this proposal tries to address.

The former proposal has the issue of imposing a bottom-up approach, having functions that need to generate only a part of the sentence and populate a table that should contain all the different variations of the part of the sentence for all the possible grammatical contexts. As it has been pointed out, this approach has the issue that in realistic scenarios for many languages requires the creation of huge tables, only to select at the end just one option, other than not accounting the fact that in some languages, different parts of the sentence may be mixed up.

The Semantic unit and Syntactic unit approach tries to solve these issues by proposing a different approach, which consist in first encode the entire sentence through an object, and then pass it to a function that renders it. The Abstract sentence approach is basically the same one of Semantic units (and leaves purposefully out the proposal of Syntactic unit, since it is an internal tool that is outside the scope of this proposal), but is an attempt to implement it in a way that is more idiomatic to Wikifunctions, exploiting the potential given by Wikifunctions. The hope is to create an approach that is simpler to understand for uninitiated contributors, and that naturally guides Abstract Wikipedia editors to the generation of abstract content.

Structure

An "Abstract sentence", for the purposes of this page, is the representation of a sentence in a language-neutral way. It is composed of various "Abstract sentence parts" (or "Abstract parts" for brevity), which can consist of entire phrases down to single nouns. The Abstract sentence is modeled as a tree, with Abstract sentence parts containing other Abstract sentence parts, down to the primitive ones. The Abstract parts can be of various types, each corresponding to a different Wikifunctions type. Each Abstract part type should contain all the content of the Abstract part (such as the Wikidata item reference (Z6091)s or the composing Abstract parts), as well as all the grammatical information that some languages need in order to properly inflect the part.

For every structure that is needed for the encoding of abstract content, there would be a different type that encodes the specific structure. For example, there would be types representing specific nouns, types encoding for various types of attributes, various sentence structures... Each new type would be discussed with the same procedure currently followed for the creation of new types. This would allow the organic growth of the different types of sentences that can be represented with the Abstract sentence model, ideally with the ability in the end to encode all the possible structures that are used in natural languages.

Usage

With this proposal, a typical Abstract Wikipedia fragment would consist in a call to a function like Abstract sentence to HTML (Abstract sentence, Language). This function would then delegate the NLG to language-specific functions.

In order to fully exploit the functionalities of Wikifunctions types, Configurations of functions for given types are needed.

Examples of Abstract part types

Those are just some examples of possible Abstract part types, that should be enough to fully encode the fragments generated by subject is instance of (string) (Z26039), classifying a class of nouns (Z26627), and subject is kind of (Monolingual text) (Z26095). These examples are still a draft, and are purposefully limited in order to just provide minimal working examples. Through progressive implementation of many new types, in the future it will be possible to encode many more language structures.

Abstract proper name concept

This Abstract part type encodes an item that has a proper name that is unique to the single real-life item. This should not be used for people, since it is necessary to use a more specialized type to handle all the nuances of people's names. This allows us to just represent it just with a single QID. This type should contain:

  • QID: The Wikidata item reference (Z6091) of the object referred by the proper name.
  • Topicality: Of type Topic-comment, encodes the topicality of the proper name.
  • Complements: A list of the eventual Abstract parts that complement the proper name. Note: they should be of type "Abstract complement", which for now is not included among these examples.

Abstract nominal concept

This Abstract part type encodes one or multiple items that are identified by a common noun. Note that here "noun" does not necessarily refer to a literal single word noun, since some languages could use an entire construction just to refer to this concept. The structure is:

  • QID: The Wikidata item reference (Z6091) of the common noun.
  • Definiteness: Of type Abstract definiteness (see below), encodes the definiteness of the noun (in other words, whether this particular noun has been previously introduced or not).
  • Specificity: Of type Grammatical specificity, represents the specificity of the noun (i.e., whether the noun refers to a specific object)
  • Number: Of type Abstract number, encodes how many instanced this noun is referring to.
  • Topicality: Of type Topic-comment, encodes the topicality of the noun.
  • Complements: A list of the eventual Abstract parts that complement the noun.

Abstract classificational construction

This type represents a sentence of type "X is Y", with the specific meaning "X is equal to Y" (like "Mars is a planet" or "Paris is the capital of France", but not for example "Jupiter is big"). The structure is:

  • First part: An Abstract part representing the first part of the copula structure.
  • Second part: An Abstract part representing the second part of the copula structure.
  • Tense: Of type Abstract tense, represents when the copula is true.
  • Complements: A list of the eventual Abstract parts that complement the copula.

Abstract part decoration

Represents a visual decoration of an abstract part (like bold or italics). The structure is:

  • Content: The Abstract part that has to be decorated.
  • Decoration: Of type Text decoration, represent the decoration that needs to be applied.
  • Applies recursively: Of type Boolean (Z40), encodes whether the decoration should also apply to all the child Abstract parts.

Examples of auxiliary types

Abstract definiteness

An enumeration that can be one of the following values:

  • Absolute: Refers to entire concept or the entirety of the instances. Supports only the numbers "1" and "Global". In English, with Abstract number "1" it usually corresponds to the article-less singular for uncountable nouns ("Bread is an aliment.") and to the singular with definite article for countable nouns ("The violin is a musical instrument."). With Abstract number "Global", it usually corresponds to the article-less singular for uncountable noun ("Water is wet.") and to the article-less plural for countable nouns ("Giraffes are mammals.").
  • Definite: Refers to instances that are completely identifiable. Corresponds to the English definite article.
  • Indefinite: Refers to instances that are not identifiable from the given information. Corresponds to the English indefinite article.

Abstract number

A value that can be either:

  • A Natural number (Z13518): the exact number of instances (if it is known).
  • One of the following values:
    • Plural: If it is an unknown quantity greater than 5.
    • Greater plural: If it is an unknown quantity greater than an already established plural.
    • Paucal: If it is an unknown small quantity.
    • Greater paucal: If it is an unknown small quantity greater than an already established paucal.
    • Global: If it is the entire quantity that exists.
  • An Abstract part, representing a quantifier (like "a glass of water").

Abstract tense

Either:

  • An enumeration of:
    • Absolute: A sentence that is always true, regardless of time. In English, is usually represented by a simple present.
    • Past: A sentence that was true in the past.
    • Present: A sentence that is true only now.
    • Future: A sentence that will be true in the future.
  • An Abstract relative tense, representing a time relative to a known time.

Abstract relative tense

Contains:

  • Relation: Either Before, During or After
  • Reference time: Of type Abstract tense.

Text decoration

An enumeration with either one of the following values:

  • Bold
  • Italics
  • Underlined
  • Crossed

Examples of abstract sentences

"Berlin is a city.":


"Antelopes are mammals." (assuming that this sentence is in a text speaking about mammals, and antelopes are just an example of mammals):

The presence of topicality allows some languages to properly mark it, and for topic-prominent languages to properly organize the syntax, if necessary.


"The eyes were a door." (assuming that it is referring to 2 eyes that have been previously introduced; this is just a demonstration of the potential versatility of this model):

Note how with this representation, it is possible for languages that have the dual number to properly employ it to indicate that the eyes are 2.

A more complete, albeit speculative, example can be found here.

Comments

Please comment mainly the general Abstract sentence proposal; if it will receive enough support, the singular types exemplified in this page will be discussed singularly in dedicated pages.

  • Support Support, as the proposer (see below). This page is meant to discuss the general proposal. The specific example types are open to discussion (in particular, I am not particularly convinced of the handling of tenses, since many languages require a very nuanced handling of tenses). Dv103 (talk) 10:00, 7 April 2026 (UTC)reply
    Can you come up with an example that goes beyond what already exists in WF, to show in what way this would be more powerful? YoshiRulz (talk) 15:36, 7 April 2026 (UTC)reply
    For now the example Abstract part types are very limited (since ideally every new type should require discussion and the reach of community consensus, so I purposefully limitated them to just the bare minimum), so it is very difficult to come up with more elaborated examples. But I think the first example already exemplifies a new feature that currently would need hyper-specific functions, which is the ability to bold just a part of the sentence, and it would not be a stretch to conceive a new similar type that would allow the encoding of hyperlinks. Dv103 (talk) 20:10, 7 April 2026 (UTC)reply
    I have now added a new example that tries to show the versatility of this structure. Dv103 (talk) 20:39, 7 April 2026 (UTC)reply
    I have created a speculative more complete example at Wikifunctions:Type proposals/Abstract sentence/Douglas Adams. Dv103 (talk) 21:08, 8 April 2026 (UTC)reply
    I have now tried to add support for topicality in the example types. Since I don't speak any language that marks it grammatically (outside the typical indo-european active and passive voices), please check if my implementation makes sense. Dv103 (talk) 20:41, 7 April 2026 (UTC)reply

*Support Support lgtm. Feeglgeef (talk) 13:56, 7 April 2026 (UTC) Oppose Oppose per opposition of proposer. Feeglgeef (talk) 13:50, 10 April 2026 (UTC)reply

  • Regretfully Oppose Oppose as the types here seem rather limited in the arguments they require--what of arbitrary proper names not mapped to items? what of nouns that haven't been mapped to items yet and may not warrant such mapping?--and there does not seem to be an ability to extend this to treat arbitrary predicates (that is, verbs that are not 'to be' or 'to have'). I fear that subordinating the flexibility for handling arbitrary linguistic phenomena to some notion of Wikifunctions idiomaticity will kneecap the expressive ability of abstract content; if we are to help new contributors out, then this should come from (as sort of tried by Immanuelle on the current Abstract Wikipedia) tooling on top of the abstract content format and (as hinted at by VivianIsBee on Abstract Wikipedia's Project chat) a flexible authoring language that is defined and maintained alongside any defined abstract content types. Mahir256 (talk) 15:26, 7 April 2026 (UTC)reply
    Perhaps it was not very clear (I've now tried to clarify more), but the examples of Abstract part types present in this page are just a minimal part of the entirety of types that would be created in order to encode Abstract parts. One of the features of this proposal is the ability to encode a very diverse variety of structures, exploiting the polymorphism provided by Configurations of functions for given types in order to maintain scalability. For example, there will be a type encoding people's names (handling all the nuances due to the many different ways a name can be expressed), a type encoding arbitrary predicates (again, handling all the nuances due to how differently the various languages treat them). (For now, I don't see an incumbent need to encode arbitrary proper names not on Wikidata that are not people's names, but if the Abstract Wikipedia community felt the need to include this corner case, it would be easy to create a new type handling it.) Dv103 (talk) 19:52, 7 April 2026 (UTC)reply
    Setting aside issues with specific types that you provide examples for, let me then bring up some more general problems I see here:
    1. These proposals seem to stray too much towards representing syntax than towards representing information. Even if 'sentence' in the name of this page is supposed to be discounted in favor of something more general, the suggested choices of terminology like 'noun', 'copula', 'definiteness', 'tense', and 'adjective' make it seem like other terminology used with these types, however they are renamed, will continue to focus more on simply trying to replicate language rather than replicating the meaning underlying that language (however much on the surface of the words we stay).
    2. The types as defined demand many parameters when instantiated. It is much more likely that particular features of even the most commonly used types will be specified either entirely through context or purely optionally, so that having to manually specify each one every time it is used can get rather troublesome. Other features, when not necessary in a particular context, are unlikely to be allowed to be left out since there doesn't seem to be an equivalent of types having default 'null' values (as might be expected with Python or JavaScript classes).
    3. The types, if needing modification, require modification to all uses of those types. Whether this is due to adding as a parameter some new grammatical feature that has come to mind (such as 'topicality' or 'recursive applicability' which I see you added after this proposal was created) or modifying the types of other parameters (maybe some new possible 'specificity' is desired and the 'specificity' field takes a type with only a fixed number of possibilities), this type will need to have its definition modified—requiring the permission of someone who can edit types, and more than likely requiring a type re-proposal—and uses of those types, since they no longer correspond with the definition on the type page, will have to all be changed to prevent something malformed from being processed.
      More concerning to me is that this modification process applied to all uses in abstract content is not always trivially doable, since every use may not have a reasonable default fallback, and resolving any weird outcomes from a chosen default may take longer than might be comfortable.
    There are accompanying points on the semantic unit proposal corresponding to the points raised here, which I have marked with a dagger (†) wherever they occur. Mahir256 (talk) 23:35, 8 April 2026 (UTC)reply
    1. Could you please elaborate on this point? My purpose is to try to encode the meaning, so I'd accept any constructive criticism. Also note that, for the terminology, the idea is that we are not speaking about "nouns", "copulas",... but we are speaking about "Abstract nouns", "Abstract copulas": they are names to represent concepts that are analogous to the well known grammatical concepts, but are still very different. An "Abstract copula" could correspond to the weirdest grammatical construction in specific languages, but it just encodes the meaning of "X == Y" that is usually expressed by a copula. This is why, for example, the type "Abstract copula" proposed in this page specifically just encodes the expression "X is Y" with X and Y both nouns (and not "X is A", with A an adjective): it is an attempt to just select a specific meaning that the English verb "to be" has (I too agree that this meaning is still ill-defined, so more work is needed). By the way, in the Douglas Adams example, I'm too very skeptical on the modelization of "adjectives" present there, but for now I haven't been able to come up with anything better.
    2. This is partly by design. Each type should contain all the fundamental information that cannot be deduced by the context (at least, not by a computer) that (ideally) at least 1 language needs in order to produce the correct output. One of the reasons why they are compulsory is that they represent a remainder for Abstract Wikipedia editors on which information is necessary: it is not difficult to think that an European editor would for example completely forget to signal what is the topic (which for many languages is a very important feature that needs to be marked); if the topicality is instead compulsory, it is way more likely that editors will signal it correctly. Also consider that, due to how the Wikifunctions user interface works, in order to insert many of these information you just have to select the right option from a drop-down menu, while making them not compulsory (i.e., inserting a generic Typed map (Z883) "core arguments" field, like proposed in Wikifunctions:Type proposals/Semantic unit) would be way more tedious, or require specific functions just too wrap the type creation with a nicer interface.
    3. This is actually the weakest point for this proposal, since type modification is very tedious (even if it has been done various times in the past, so it is possible; in particular, the insertion of new fields doesn't seem too much an issue). But it is also true that part of this tediousness is unavoidable: whatever representation we choose, we still need to choose a specific encoding, and a change in the encoding would always need to correct all the instances in which the previous encoding has been used (and if necessary also all the functions dealing with it). This is why I oppose a cheap creation and tweaking of encodings, preferring instead the slow and consensus-based approach that is currently used for type creation, in order to minimize the need of corrections after the type creation, if possible. Also consider that in the future type creation should become much easier, when/if phab:T318943 is resolved.
    Dv103 (talk) 12:11, 9 April 2026 (UTC)reply
    @Dv103: As a general statement, I will suggest you read, if not the whole semantic unit proposal again, the parts of that proposal that have been marked with daggers (†), now with accompanying superscript numbers, and respond to my reply of 23:34, 7 April 2026 (UTC) to your comments there.reply
    1. (†²) No matter how many times you put 'abstract' or its synonyms in front of the name of some syntactic concept, the connection to syntax will be present, if not stronger, in the mind of the person coming across the term you use. Even words like 'copula' and 'noun' are necessarily overloaded here due to those terms often encompassing different semantic notions (the nonverbal clause construction analysis I am using, for example, does not have a general catch-all category for 'copular' constructions), and simply stating things in terms of the usual meaning of a syntactic concept only complicates situations when a "less-usual" meaning needs to be referred to. As far as leaving things ill-defined or not being 'able to come up with anything better', you may wish to consult scholarly cross-linguistic analyses of semantic concepts and constructions and support some of the existing types you have proposed above with those analyses.
    2. (†³, †⁴, †⁷) If the goal is to get contributors acquainted with the particular semantic features that lead to a properly grammatically indicated sentence, then adding those features should become a gradual process. I don't see it being very helpful to a newcomer if when starting to learn an abstract content language they are forced to reckon with e.g. seven parameters to start for each abstract type rather than working their way up from e.g. two parameters—even Python's print function, to name something very common, has four other possible arguments besides the list of things to output to the screen, and I am not sure that newcomers to that language would have had as nice a time if they had to specify all four of those from the get-go. I am a little confused by the idea that making someone select lots of options manually at once is simpler than just letting someone add only those options that must be specified to a general argument list; the user interface could be improved to make those options more easily addable to the general list.
    3. (†⁵, †⁶, †⁸, †⁹) I don't mean to suggest that consensus-building should be disregarded when coming up with abstract content types, but that process should fall between creating an abstract content type and using that type (so that, for instance, those types can be tested in draft pages and evaluated on more than just a conceptual level). If the process of adjusting uses of an abstract content type becomes too tedious, then that is likely to dissuade people from suggesting improvements (cf. the many months it took to propose and create alternatives when substituting the overloaded "of" property on Wikidata everywhere it occurred), and I also fear that the format will stagnate and become resistant to any changes as a consequence. (Funny to see that the task you linked has been open for over three and a half years now, and that the last subtask was closed back in August.) Mahir256 (talk) 14:20, 9 April 2026 (UTC)reply
      1. If I understand correctly, is the problem just the nomenclature? Now it seems to me that the structure of these examples are very similar to the structure of Ninai examples. Very likely, I am missing something more fundamental, so please explain me if I'm wrong.
      2. I don't think that types should necessarily accomodate to the individual learning process, since this can be handled in various other ways.
      3. It is a matter of understanding how much of a technical issue it is. If this issue turns out to be unresolvable, I too agree that we should abandon this proposal. This is something that needs to be discussed with the Wikifunctions development staff.
      Dv103 (talk) 20:12, 9 April 2026 (UTC)reply
Now Oppose Oppose, due to the technical challenges that type modification brings along. Dv103 (talk) 20:31, 9 April 2026 (UTC)reply
Thanks for taking the time to write this proposal. I learned a lot just from reading it and the comments. :) So9q (talk) 21:11, 11 April 2026 (UTC)reply
Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Type_proposals/Abstract_sentence&oldid=264768"