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)
- 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
treeon 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
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)
- 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
- 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
- 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)
- 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