chore(weave): Refactor and rename code to more appropriately handle builtin_object_class not base_object_class

[tssweeney]

Note: should split and deploy backend before landing front end (python extraction: #3248)

This is just a refactor, but touches many files. Specifically, in this PR: #2826 I introduced a mechanism for creating weave objects via the API for known classes. This system introduced an API param: set_base_object_class: Optional[str] = None. Notice the base word here.

In nearly all the files, I used the term base for example base_object_class, baseObjectClass, BASE_OBJECT_REGISTRY, etc... This is used by Leaderboards and Annotation spec definitions.

However, as I am beginning to rely on this more for Scorers and Models, I realized that this was not correct. Let me take a minute to define these terms:

• base_object_class: this is the name of the first subclass of any subclass of a weave Object class.
• object_class: the string of the actual class.

Let's consider the following example:

class Scorer(weave.Object):
   ...

class LLMScorer(Scorer):
   ...

class HalucinationLLMScorer(LLMScorer):
   ...

scorer = HalucinationLLMScorer()

In this case, the class hierarchy is: HalucinationLLMScorer -> LLMScorer -> Scorer -> Object -> BaseModel

So, in our terms:

• base_object_class = "Scorer"
• object_class = "HalucinationLLMScorer"

Now, base_object_class is treated specially and extracted to be stored in the DB and has first-class filter support. This allows us to find all Scorers, Models, or other objects, even if they are sub classes of those "base" classes.

Furthermore, in the val payload of the object, we have special keys:

• _type = "HalucinationLLMScorer"
• _class_Name = "HalucinationLLMScorer"
• _bases = ["LLMScorer", "Scorer", "Object", "BaseModel"]

Yes, _type and _class_name are the same.

---

So, why is this all important? Well, names are important! And the use of base here was not correct b/c it was intended to target the final object_name of some builtin class. Therefore, this PR effectively renames all cases of base to builtin where appropriate such that anytime base appears, it really means the base_object_class and is no longer ambiguous.

[circle-job-mirror]

Preview this PR with FeatureBee: https://beta.wandb.ai/?betaVersion=a16822174cee2155754d9dcb918fdc18321ad335

[tssweeney]

this is an edited version of the now deleted weave/trace_server/base_object_class_util.py

[tssweeney]

mostly just comments and name changes

[tssweeney]

This is just a rename of another file

[gtarpenning]

Future readers might prefer a descriptive comment rather than this notice which feels more relevant for reviewers (which I appreciate)

[gtarpenning]

neat

[gtarpenning]

might want to have the docs team take a peek at the docs changes, lgtm