search

cezarykluczynski / stapi

STAPI, a Star Trek API
https://stapi.co
MIT License
123 stars 14 forks source link

Many suspect/erroneous Element database entries #19

Open xihr opened 3 years ago

xihr commented 3 years ago

Browsing through the API browser, I poked through the Elements category and see a lot of either suspect or erroneous data.

For starters, clearly some of these are not even elements ("Lanthanide," "Sulfide," "Carbon-70," etc.). Many are fictional, obviously -- nothing suspect about that -- but have entries for atomicNumber or atomicWeight that clearly conflict with existing elements ("Purseronite," "Freedonia," "Cosmoium," etc.) or have a symbol which is already used by an existing element (e.g., "Cosmoium" is listed as having symbol "Cs," but that's the symbol for cesium), or just have nonsensical data ("Kryptonite" has symbol "Kr" (conflicts with the real krypton), has atomic weight 1 (that's the atomic weight of hydrogen-1) and is marked as transuranic). There's also some just plain silly names that I've never heard of in any Star Trek property, but maybe these are just gags ("Disneyium," "Daffyduckium," "Cheeseium," etc.).

And, as a minor correction, the field transuranium (a Boolean) would be more properly named transuranic.

Also maybe add a Boolean field known for ones that represent real elements (of which there are more than a few in the database)?

cezarykluczynski commented 1 year ago

Thanks for taking time to look at the data!

After a recent data update, some of the elements that are not really elements, were cleared.

I also renamed transuranium to transuranic in the new version of the API (example).

As to other things, I don't think that anything should be done about two elements having the same atomic number, the same symbol, the same atomic weight, or conflicting with other fictional or non-fictional elements, as long as Memory Alpha pages were parsed correctly.

STAPI merely takes note of the facts that happened inside the Star Trek franchise. Even if conflicting in-universe facts has been produced by different writers at different occassions, that is what the franchise consists of. Even if we conclude that major inconsistencies exist between different TV series, the only way to correct them would be to put fake data into the DB, not corresponding to how things really were. That doesn't seem right.

STAPI uses Memory Alpha as it's primary source of data for few reasons, and that includes the fact that people at Memory Alpha spend a good amounts of their time discussing how the in-universe facts should be presented, and they are tirelessly going over source material, to accurately represent it in the encyclopedia. To now go and correct their findings and undermine their consensus would suggest that I have resources and expertise to challange their effort. Which I don't. Granted, in the source code, there are some corrections for different edge cases, but never to an extent that changes source data. Usually it just filters out what is too elusive to categorize.

I also don't agree that a known field has a place here, or in any other fictional entity that STAPI serves. In a sense, all of the data that STAPI gatheres, and that Memory Alpha gathers, is fictional. It could happen that in the next episode of the new series one of the characters tells another that they fly to 23rd century New York. Will it be real New York? Is it any more real that Daffyduckium, a in-universe element? TNG mentions that in 2024 the unification of Ireland happens. Should we treat unified Ireland as a real country now, because of the possibility, but not in 3 years, in the year 2025? Stephen Hawking played himself in TNG, but it was not a documentary about him. Was he more real than Mark Twain played by Jerry Hardin? There are many cases like this, and I think the best approach is to take data as it is. Memory Alpha does it with source material, STAPI does it with Memory Alpha contents. Otherwise, we create a whole new class of problems, which are nearly impossible to resolve.