# Objects Schemas

### By default, our grid objects are modeled in accordance with [schema.org](https://schema.org) standards.

Modeling objects to be compliant with schema.org brings a powerful blend of interoperability, visibility, and data clarity — both for machines and humans.

Not all objects our clients require are currently defined in [schema.org](https://schema.org). For these cases, we create them ourselves, in collaboration with you and other clients. Once ready we'll also submit them to schema.org for consideration, with the goal of contributing to the standard.

#### Benefits of Schema.org-Compliant Object Modeling:

* **Enhanced Search Visibility (SEO)**\
  Enables rich snippets (reviews, prices, events) in search results and increases click-through rates with enhanced previews.
* **Machine-Readable Semantics**\
  Shared vocabulary understood by search engines, crawlers, and AI agents. Improves structured data processing and content indexing.
* **Interoperability and Portability**\
  Makes your data more reusable across APIs, CMSs, and partner platforms. Easily consumed by systems expecting schema.org or JSON-LD formats.
* **Cleaner, Standardized Modeling**\
  Reduces the need to invent custom schemas for common entities (e.g., `Product`, `Offer`, `Person`). Aligns your data with industry-wide expectations.
* **Better Structured APIs and Headless Content**\
  Ideal for use with GraphQL, REST, and headless CMSs. Improves clarity and documentation in API responses.
* **AI and ML Readiness**\
  Structured, semantically labeled data is easier to use in training, recommendation, and inference engines.
* **Developer and Partner-Friendliness**\
  Clear, consistent modeling helps external integrators and internal teams understand your data quickly.
* **Improved Accessibility and Governance**\
  Supports accessibility tools and structured outputs for screen readers. Helps with data classification, tagging, and privacy compliance (e.g., `Person`, `ContactPoint`).
* **Future-Proofing**\
  Based on an evolving industry standard maintained by Google, Microsoft, and others. Compatible with linked data, RDF, and semantic web tools.

### Schema.org vs Object Oriented Programming (OOP)

Unlike OOP, schema.org models all **objects relationships as references**, not containment. Exceptions are simple data types like text, number, integer, boolean, date, datetime, time, duration, url, and enumerations.

* **Designed for the Web**\
  Schema.org is built for the semantic web, where data is decentralized and linked across domains.
* **Supports Reusability**\
  Entities like `Brand`, `Offer`, or `AggregateRating` can be shared across multiple objects without duplication.
* **Enables Linking and Identity**\
  Referencing allows objects to have global identifiers (`@id`) that can be dereferenced and resolved independently.
* **Improves Maintainability**\
  Updates can be made to referenced objects without modifying every parent that uses them.
* **Aligns with RDF and JSON-LD Models**\
  Schema.org uses linked data principles, where relationships are represented as edges between nodes.
* **Avoids Tight Coupling**\
  References allow for loose coupling, making data integration and merging across sources easier.
* **Optimized for Search Engines**\
  Crawlers and knowledge graphs can follow references to build richer, connected datasets.

Schema.org in many cases **uses singular names for objects' properties, even when they can accept multiple values**. For example, the review property on a Product can reference either a single review or a collection of reviews. The property name alone does not indicate whether it expects one or many values — this flexibility is by design.

* **Human-Readable Language**\
  Schema.org prioritizes natural language clarity. Saying `"review"` or `"author"` reads more cleanly than `"reviews"`or `"authors"` — especially in structured sentences.
* **Consistency Regardless of Cardinality**\
  Most properties are designed to accept **either one value or many**, and using singular naming keeps the schema consistent no matter the usage:

  ```json
  jsonCopyEdit"author": "Jane Doe"
  "author": ["Jane Doe", "John Smith"]
  ```
* **Semantic Web & RDF Compatibility**\
  Under the hood, schema.org is aligned with **RDF** and **linked data principles**, where properties are treated as **predicates** (e.g., `Product → hasReview → Review`), not array names.
* **Simplifies Schema Maintenance**\
  There’s no need to define both `review` and `reviews` — one property can serve all cases (single or list), avoiding duplication and confusion.
* **Less Redundancy in APIs and Markup**\
  Singular names prevent bloated vocabularies and promote cleaner documentation and code.

Unlike common practice in OOP, **schema.org names objects attributes as "hasX"** but does not represent a Boolean value. \
Schema.org follows natural-language naming conventions (borrowed from OWL, RDF, and human-readable semantics), not a strict programming conventions. \
In schema.org, "hasX" implies a relationship or association with X, not "true/false" ownership. Think of "has" as “has a relationship with…”, not as “returns true if X exists”.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.objectsgrid.com/documentation/usage-guide/objects-schemas.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.