Objects Schemas

By default, our grid objects are modeled in accordance with 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. 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:

  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”.