Objects and Object Types

In Lar, a book you read, the person who wrote it, and the meeting where you discussed it are all Objects, and each one knows what kind of thing it is. Because every Book has the same fields, you can later ask for “every Book rated 4 or higher” and get a reliable answer.

An Object Type (usually just “Type”) defines that shape: which properties and relations its Objects have, whether they have a body, and how they look. Every Object has exactly one Type. On top of what its own Type declares, an Object can also get fields from a parent Type and from Mixins.

Create an Object

1. Select New in the sidebar.
2. Search for or select an Object Type. Lar creates the Object and opens it.
3. Give the Object a title.
4. Fill the properties that matter now. The editor marks required properties.
5. If the Type has a body, write in the block editor below the properties.

You can also create an Object from a template, a Collection, Quick Capture, the calendar, or a workflow. Each path produces an ordinary typed Object.

Choose the right Type

Choose the Type that describes what the Object is, not every role it plays. A client contact is still a Person. Client-specific fields can come from a Mixin, and the link to the client’s company can be a relation, rather than a second Type.

Why one Type instead of tags

In a tag-only system nothing stops two “book” notes from drifting apart: one has a rating, the other a stars field. In Lar, all Books share one schema, so a query such as type:Book prop.rating:>4 means the same thing for every Book. Tags still exist for topics that cut across Types; see Tags.

Create a custom Type when several Objects need the same:

• properties or relations;
• page and card layout;
• templates;
• calendar behavior; or
• Type-scoped Collections and automations.

Loose properties

Sometimes you need a one-off field that doesn’t belong in the shared schema. Lar keeps such values as loose properties, listed under Loose properties in the Object’s details panel. Loose properties have no declared kind, aren’t inherited, and aren’t part of typed property queries. They exist so the typed model never stops you from writing something down. When the same field keeps recurring, add it to the Type as a real property.

Change an Object’s Type

1. Open the Object’s ⋯ menu and choose Change Type.
2. Pick the new Type.

Lar matches each value to the new Type’s schema. Values for properties the new Type also has, including ones both Types get from the same parent or Mixin, carry over unchanged. Every other value moves to a loose property instead of being discarded, and the new Type’s defaults fill any properties the Object didn’t have.

Changing an Object’s Type affects one Object. Editing a Type’s definition affects every Object of that Type.

How Types change over time

Editing a Type doesn’t silently reinterpret your data:

• Renaming a property keeps the old name as an alias, so saved queries and references keep working.
• Changing a property’s kind (for example text to number) creates a new property with converted values and keeps the original, deprecated, with its values untouched.
• Deprecating a property keeps every stored value but stops new writes. Deleting a property permanently is a separate action that asks you to confirm.

See Properties for the steps.

Objects without a body

A Type can exist without a body. That suits structured records whose properties are the content, such as the built-in Tag Type. To remove a custom Type’s body, remove its Blocks property; see Add or remove the body. Types with a body use Lar’s block editor and can switch between page and edgeless modes.

Built-in and custom Types

Lar includes built-in Types such as Note, Page, Tag, Daily Note, Task, Event, Capture, Workflow, and file-backed media like Image and PDF. Their schema is owned by the app, so they expose fewer settings. Custom Types can define their own parent, properties, relations, Mixins, templates, and layouts.

Next: Create and edit an Object Type. For vocabulary, see the glossary.