User:Reversedragon/SignSubpageProposal

Now that Ontology pages have gotten so elaborate, and become more or less fully functional as semantic MediaWiki entries, it is likely that the Wikibase feature is going to be outright removed and the main namespace turned into something more like a home for human-readable names in various languages that form simple links to both Lexemes (standardized versions of terms themselves) and Ontology pages. The Ontology namespace could be dropped entirely, or more likely, used solely for number-based page names while the main namespace holds the readable ones.

With this change, there is a question of how to best realize book editions and Lexeme Senses, both of which are still relatively cumbersome to input and make use of quickly.

Book editions and Lexeme redirects

These were mentioned in the Sign Entity proposal. Having only two entries for a book and all its editions is something of an improvement from Wikidata's FRBR-accurate model, because referencing a particular book without worrying about what specific characteristics it has has become much less complicated. However, creating term redirect links in order to specify each Lexeme sense has still been clunky. A redirect page has to be created which holds the actual name, then the anchor has to be on the Lexeme page, then the anchor has to be tested, then the edition-Sense can be put on the book page to separate editions. That is already too many steps for a Lexeme, let alone a book edition.

If Wikibase Entities themselves are going away, then there is no reason to not simply start creating Sense-like distinctions on Item pages, solely for book-like things at this time. The Sign Entity proposal overcomplicated things a bit by assuming every Item should have the possibility of having Associations, when that should not be the case if Items follow a policy of being objectively-distinguishable concepts and not words. Lexemes can be the opposite: every Lexeme is a mere word, and has almost every connotative definition people could conceivably use out in the real world.

By now there is already a possible way to fix this: some Property pages now have pass/fail subpages for the purpose of rating sheets, such as P201/G and P201/NG. Swatches, labels, and data attributes for debugging can be kept on these includable subpages, making them very appealing for localization.

Lexeme Sense subpages

The relatively obvious solution:

= L617 run =
1. move fast   [[L617/S1]]
2. execute computer code   [[L617/S2]]

The only problem with this is that Lexeme Sense numbers suggest a preference for particular definitions. Although this is not a big problem for Items when there will only ever be one Item #1, Lexemes constantly start the numbering over, constantly asking users who add Lexemes to arbitrarily mark definitions of words the first and second definitions in accordance with their current usage knowledge or prejudices. In practice, it is more convenient to be able to swap Lexeme definitions around and reference them without a particular number. This could be fixed by assigning senses random capital letters resembling "S1", "S2" Sense strings:

= L617 run =
1. move fast   [[L617/RJ]]
2. execute computer code   [[L617/LS]]

Lexemes and Wavebuilder

I am not totally sure if this truly belongs on this page, but I have found a way for Wavebuilder combinations on Lexemes to make sense. Lexemes should not be combined with Items and Items should not be combined with Lexemes. This is what was already implied to be the case the way things already were. But now, I have a more solid image of how Lexemes should be used.

Lexemes should be used about as they were in thesaurus.dict. We start with fairly basic words, and combine one word with another that suggests the sense the word is used in to arrive at a more specific term. This probably deserves its own Wavebuilder operator. It has the characteristic of being order-dependent, like Wordiverse's "how does X become Y" operator (which is more or less the same as the "characterization" Property in concept, in that it requests the two elements that combine to form a particular result). X Sensu Y.

Demo

Wavebuilder: hyponym

staging-ground

sense

place

Wavebuilder: hypernym

stage

sense

place

<!--       en: stage  SENSU  place  DUBBED  staging-ground -->
<!-- en: FROM  stage  SENSU  place  DUBBED  staging-ground -->