User talk:Reversedragon/FirstNineThousand

Unreleased works?

• So what do we think about putting monster strains on this thing
  You know, as long as one is willing to update any scrapped mons to at least something current that will be used
  Valenoern (talk) 15:10, 24 January 2025 (UTC)

  • Well, the general rule is that objects inside unreleased works don't go directly into Items, though that's mostly to keep things tidy. Unreleased works are fine in the User: namespace — assuming of course that they're alpha/beta material being put there for the world to reference up to their release, but I'm sure you already understand that distinction.
    As for the CDRW tables you sent, those would make great thesis pages. Make a hue list of your in-progress monster strains using the templates, and they can be Items when there's a demo.

    I absolutely get your thinking. When you look at something like Monster Rancher / Monster Farm there are a million links back to previous works and forward to new works and sideways to parallel works. What would definitely be okay already is to put all the Monster Rancher creatures into the FirstNineThousand list, and all their previous horror / sci-fi movies. — 🦖 R.D. (talk) 00:54, 25 January 2025 (UTC)

  • There is just one problem here which is: where on earth do we fit every single Pokémon? I've been thinking about that. I think Pokémon are banned from the FirstNineThousand just because they won't fit. They can be added later of course. — 🦖 R.D. (talk) 00:54, 25 January 2025 (UTC)
    • Note: Shortly after this they were added.
      Valenoern (talk) 03:00, 28 January 2025 (UTC)
  • Neither of us really takes any issue with you using this project as infrastructure for the zensekai project. Personally, I have ideas to slowly integrate it with wavebuilder. The only real caveats to remember are we don't want unused Items and we don't want abandoned projects, or projects that will try to withdraw themselves from us and declare we can't talk about them. Apart from that, go crazy. — 🦖 R.D. (talk) 19:33, 3 February 2025 (UTC)
• I've been thinking again about the prospect of numbering MDem entries in the main namespace given they are already indexed by topic number. I ran tree on the folder and a range of 2000 would almost certainly be able to contain every finished chapter of the book and every scrap and revision if necessary. Valenoern, what do you think? I banned your Asekai entries because the game isn't out but do you think an unfinished philosophy text is any better? Here's my new deal: 1000 entry slots for any project that is highly likely to end up with development posts that will be referenced years later, and you put said referenceable posts in there. Said another way, you get reserved slots but we trust you not to use them. Except when it's time to. — RD
  • This will be a closed project for a while, but maybe when we open it up more and admit more reserved project ranges we can call this..... wait for it..... the U.S.S.R. policy. "User Space for Special Research" — 🦖 R.D. (talk) 02:11, 14 February 2025 (UTC)

S.S.R. progress bar

• If we're going to do this thing of giving projects Item slots, we need to set down some criteria for S.S.R. promotion, so we can track those criteria on each thesis portal and create a snazzy progress bar template. — 🦖 R.D. (talk) 02:51, 14 February 2025 (UTC)
  • Thought number one: number of entries. You should have at least 200 distinct post files written somewhere, at least one of which should be likely to be cited for information or quotes years later. (This means that if the other 199 are not quite worthy of leaving up publicly, you only "have" to put one of the 200 posts into your Item range once you get it.) The UNIX tree command may be helpful. — RD
  • Thought number two: ontology. Your body of posts should have some neat ontological ordering, such as with bop sort codes ordering the MDem book into parts and different drafts of the book being ordered into version numbers. There is no specific kind of sort code or folder structure you have to use, but it should be solid enough to imply the work is already through its first draft. — RD
  • You would not be required to put every Item within your Item range into perfect presentable order as if they were a book. It would be fine to register the entries in whatever order they are actually being created or used for data connections and then present them in "proper" order on a thesis/Ontology portal. That's likely how the MDem range will do it. — RD

Editing

• Can I just, go add every single tokusatsu show I can think of
  You know. It takes the three of us such a long time to communicate back and forth, maybe I'll just do it first and then ask
  Valenoern (talk) 03:00, 28 January 2025 (UTC)
  • Yeah, it's fine for either of you to edit the FirstNineThousand list if you have any ideas; in that sense this is basically just the same general thing as Wikidata or a Fandom category page with a teeny bit more thought because the page IDs are "forever". It's possible you might make mistakes versus what I had in mind, but I'll fix up the ordering or concept divisions if I think you made any mistakes. — RD
  • A little note for the outside world: this wiki is something of a closed project right now because I feel that we really need to put down the right scaffolding before it can properly get started, but it may well open up for general registration later. As of today it has three members: maintainer vidak, director R.D., and alpha tester Valenoern. — 🦖 R.D. (talk) 03:21, 30 January 2025 (UTC)

Lexemes

• Today and yesterday I have been having crazy ideas about Lexemes. I think I need to start writing them down to see if anything becomes of any of them. — RD
  • My first idea: would it make sense to make every Item as a Lexeme so Items can have multiple meanings? I don't think so. Multiple Items per multiple meanings is probably better. A Lexeme should serve a purpose something like a disambiguation page. — RD
  • Second idea: what if Lexemes were used as Item labels? This would allow labeling a Property with specific linguistic labels on different Items, making the reuse of Properties for slightly different contexts more intuitive to new editors. — RD
    • I actually like this one. If Lexemes don't fully replace labels, and are just a bit of an upgrade, and if they are mostly language-specific unless the label Lexeme has a translation but other Lexemes for other languages are not linked, then Lexemes should be quite appropriate for Item-namespace message strings. — RD
    • Note that simply adding Forms to Properties is not a good idea because the Forms area is not well-designed to hold multiple languages. With SeaTurtle format it's trivial to put in languages but nobody using the API expects Lexemes to behave that way, so it may be better not to. — 🦖 R.D. (talk) 23:36, 6 February 2025 (UTC)
  • Third silly idea: could Lexemes be abused to connect works and editions? I have thought a lot about works and editions and have felt like edition items should not be separate from works on this Wikibase, but there is always the risk that for some reason editions of something will not be considered notable by Wikidata, and will have to be recorded here. If a work item had built-in fields for editions the same way Lexemes had fields for forms and senses, this would be one way to solve the problem. — RD
  • Fourth thought: Valenoern, didn't you have an entire data structure for creature form charts? Now, honestly, that one might be genuinely better served by a new Entity data type. It doesn't necessarily work the same way as anything else, and it has its own particular way of functioning, where perhaps the key feature should be Stages listed out in a linear fashion and everything then becomes about connecting the Stages. — RD
  • Fifth thought: I think... I think the best thing to do here might be to before we seriously get started with a lot of Items here, create a new type of Entity which replaces Items, which allows all Items to have Forms, Senses, Editions, or Stages, even though most of them won't. (Or, we can keep Lexemes, but allow regular Entities to have Editions or Stages, and use Lexemes for their labels.) That might be a pain to create, but it might be the best thing to do in the long run. I just hope that it's possible to have a Wikibase up with some 100 Items or so, tweak the extension with a new capability, add a new Entity, and seamlessly see that all Entities have the new capability. — RD
    • The great strength of this one is that there will never be any new namespaces with restarted numbering just because new Entity types are added. I am greatly warming up to the notion of there being exactly one linear listing of all Entities except perhaps Lexemes, while an ordinary Item field sorts them into their semantic item grouping of Z, S, and so forth. And if the basic Item structure could be added to, everything would be so much more future-proof. — RD
      • Now the biggest conundrum I have is: is there any meaningful difference between editions, stages, and other kinds of variations in form? Imagine there is some item for Archaeopteryx and it has the species Archaeopteryx lithographica, some item for Journey to the West and it has two editions, some item for Agumon on the original Digital Monster device with a specific array of forms, and some item for a Pokémon or Digimon card which clearly illustrates the same entity in the same sense but has multiple editions. Beyond the obvious caveat that some kinds of data are highly likely to change and it is a bad idea to code some clades above the genus level as these kinds of fixed stage-having Entities, what is the difference between any of these? — RD
        • Arguably it might actually be best to code species binomial names as Lexemes, because of the way the names stick around indefinitely but they change in meaning. A particular dinosaur specimen might bounce between genera as more details come up and errors are fixed; two duplicate names can get assigned to the same specimen and they both become documented as synonyms for the same thing, with the older one usually being termed the canonical one. You know, this is a great argument for Lexemes being a kind of Item label or otherwise linked into them to represent their name. As well as for not merging Lexemes with anything else. — RD
        • Imagine there is some item for the apparently-rather-confusing flower Abelmoschus manihot, which has the cultivars(?) Abelmoschus manihot var. pungens, Abelmoschus manihot var. tetraphyllus, and the subspecies Abelmoschus manihot subsp. manihot. Botanists can hardly agree what's a variety or a cultivar either definitionally or practically, and then there are subspecies too. At the end of the day it's best to just number them all as the same kind of variation and use Properties to specify what taxonomic rank they are being called today. — 🦖 R.D. (talk) 10:49, 8 February 2025 (UTC)
        • Human populations, philosophies, or movements should always be coded with separate Items and linking Properties given their nested relationships are subject to rapid change, and likely to come under ideological dispute as to what each group believes to currently be true. The variations concept is only for "instance-level" kinds of variation, like editions of a specific book or cultivars of a specific species that are going to be connected to that thing indefinitely. — 🦖 R.D. (talk) 10:49, 8 February 2025 (UTC)
        • Oh yeah, this could also be used for notably-different-but-not-necessarily breaking software versions. Another kind of variation that looks different but might fundamentally be the same thing. — 🦖 R.D. (talk) 10:54, 8 February 2025 (UTC)
        • These also might be ideal for coding SCPs. Say there is an Entity S447 which is a green sphere that should never come into contact with dead bodies. S447 then has sub-Entities S447-F1 (SCP-447-1), the sphere itself, and S447-F2 (SCP-447-2), the ooze that comes out of it. It would be a minor downside that some entries wouldn't have their proper number, but if they were on their own Wikibase instance purely for SCPs that created placeholder Entities so numbers can somewhat be "chosen" the way beta-Lithographica does, it would work out reasonably well except for a few edge cases like SCP-1 proposals which would just have to take higher numbers until one was properly chosen. — 🦖 R.D. (talk) 23:56, 8 February 2025 (UTC)
          • I guess one way to fix this is to simply create a skin which really prioritizes Entity labels as if the Entities were wiki pages and makes the internal numbers almost invisible. Then the Entity ID could be anything but the label would show the correct number. — RD
        • Say we make a Sign Entity for string theory — maybe for some specific mathematical equation. For a long time people thought this equation was a model of black holes, but then a paper came up which gave people reason to think this equation was not accurate. Entity S100-M1 says that the equation is literally a mathematical equation that refers to nothing but itself. Entity S100-M2 says that the equation is an accurate model of black holes. If information comes up saying that the equation is inaccurate, there's no need to try to delete S100-M2, as much as to change it to say the equation is an outdated or falsified model of black holes. Likewise, a Sign Entity might model M-theory by saying that it has several variations in particular string theories, but in terms of Meanings only refers to itself because the individual string theories are the models. Unless there is a highly-specific M-theory model which is easy to describe as a particular set of equations, in which case the Meaning S100-M1 would link to that. — 🦖 R.D. (talk) 23:56, 8 February 2025 (UTC)
    • Other important question: if we code this new Entity to be appropriate for both "signs" and "species", what happens if the variants have meanings? — RD
      • This sounds like a silly question but it really opens a concerning logical regress. We basically have an "S" Entity with "F" sub-Entities. Perhaps we will call these datatypes Sign and Fragment in the code. An S Entity is the important one with all sorts of Properties on it. But the F entities can also have all sorts of Properties on them. Say there is an S entity for Vulpix, and an F entity for Alolan Vulpix. Entity S37 will say it is a Fire-type Pokémon and entity S37-F1 will say it is an Ice-type Pokémon. But maybe for some reason — this is a bad example, but bear with me — we decide that the feature for Sign Entities to have Meanings will be used to code variations of Vulpix in each game engine, like Pokémon main series games versus Pokémon Ranger, Pokémon Go, and so forth. Has this shown that Alolan Vulpix really needs to be coded as a separate Entity so that it can properly have Meanings for each game? Let's assume that in this hypothetical scenario having stat blocks for each game is really really important. Can we fix the problem by creating multiple Sign entities for Vulpix (mainline games) and Vulpix (Pokémon GO), or is this problem fundamental? — 🦖 R.D. (talk) 23:56, 8 February 2025 (UTC)
        • Say we use Sign Entities to code Digimon. We decide to code every form as a separate Entity because they are largely separable even if they look similar. We can assign Meanings for each particular game data block. But now say we take this back to Pokémon. Pyroar has four superficially evident forms: Male, Female, Male Shiny, and Female Shiny. There is no real getting away from the fact Pokémon need Fragment sub-Entities, because making a separate Entity for Shiny Female Pyroar would be ridiculous, and yet, they all have potentially separate party icons and 3D models as well as the Property of Pokémon Gender. All four Pyroar forms have the same game data block per game, suggesting Meanings can exist independently of Fragments. We can encode the fact that Litleo evolves into Pyroar on the top-level Sign Entity. Everything looks fine, unless we go back to Digimon, and we discover for instance that SnowAgumon has the same game stats as Agumon, but yet we've made them separate Sign Entities, so we are stuck awkwardly making a Fragment on Agumon and linking it over to its separate full Sign Entity. — RD
  • I just had another strange idea for how to use Lexemes: formatting rules. If/when we restart bop development, having a consistent URI for "two hashes" or "text enclosed in asterisks" containing the meanings of those formatting strings could turn out to be useful. It might be mildly strange to have to put in their languages as "HTML" or "Markdown", but quite honestly, not so very strange because of such facts as that HTML tags can have intended semantic meanings. Sometimes when I'm looking for what HTML tag is the most semantic it really does feel a lot like frantically flipping through a very strange thesaurus. — 🦖 R.D. (talk) 05:04, 22 February 2025 (UTC)

Wavebuilder

• I have been contemplating a mechanism to properly integrate the notion of Wikibase Item numbers with the code of wavebuilder to better enable crossover between these two projects. — RD
  • The fact Wikibase stores Items or Lexemes as integers is very good. It means that any program adjacent to Wikibase can safely assume that elements, pre-existing or arbitrarily added in a dictionary, can all be mapped to integer numbers, and in turn, any structure storing combinations between elements can be described in purely mathematical terms — if each element has some number from 1 to 10, then it is the case that combinations can all be assigned numbers in a linear numbering from 1 to 55 using a coordinate equation in terms of x and y. What might have been a hash table of combinations turns into a neat triangle. Of course, then all the human-comprehensible symbols mapping to each integer element still have to be handled somewhere. — RD
    • If the dictionary loading process were reworked a little, then every Lithographica Item could be registered into Wavebuilder using exactly its Lithographica number. This probably wouldn't be the case if you wanted to omit some Items, but, perhaps using some kind of retry algorithm to throw other elements in the gaps between specific numbers it would become possible. Optional setting, I guess. — 🦖 R.D. (talk) 06:22, 25 February 2025 (UTC)
  • I had a great insight regarding wavebuilder and Lexemes a number of minutes before I wrote this but I can't remember what it was. — 🦖 R.D. (talk) 06:22, 25 February 2025 (UTC)
    • It's nice that Lexemes have integer numbers but it's a minor problem that they restart their numbering, and a slightly bigger problem that they have Senses that give them a non-linear character. — RD
    • Another thing about Lexemes that is actually very cool is they could theoretically be used to label elements and control the labels of elements. I have thought about this before. But with wavebuilder, it would be easier to code a system that says Q1 can be labeled by L10-F1, L40-F3, or L50-F2 and when the strings for those integer vectors are then loaded into the element bank any of those strings can be typed in to select the element. It would be a matter of downloading a list of Lexeme forms to update the available Lexemes, loading the table of Item label Lexeme numbers, and loading the Lexeme forms to generate a table of Item labels. a bit of a lengthy route but it would allow storing the Item-to-Lexeme table in simple binary if that were necessary for some reason, and fully separate the elements from their potentially-multilingual names. — RD
    • The other possibility that occurred to me was just, combining Lexemes in the game and creating more Lexemes to add to the wiki. This part of wavebuilder has so far been a bit lacking because it doesn't have any kind of punchy visualization yet. Everything about the game has implied that this is actually something of a "wiki game" and the real purpose of the game is to slowly fill in the combination pyramid. We need to figure out some kind of punchy graphical interface where you actually search for the un-filled slots and see if you can think of anything to fill them in with. — 🦖 R.D. (talk) 12:32, 25 February 2025 (UTC)