Vocabulary Terms

The library ships a generated PHP class for every term of twelve OData and SAP vocabularies, and one for every record type those terms use. They are generated from the vocabularies' published sources, so a term the vocabulary adds arrives with the next release.

Shipped vocabularies

Vocabulary	Namespace	Purpose
Core	Org.OData.Core.V1	Fundamental terms (Description, LongDescription, Computed)
Capabilities	Org.OData.Capabilities.V1	Service capabilities (FilterRestrictions, SortRestrictions)
UI	com.sap.vocabularies.UI.v1	UI rendering hints (LineItem, FieldGroup, Hidden, DisplayFormat)
Common	com.sap.vocabularies.Common.v1	Common reusable terms (Label, Text, ValueList)
Measures	Org.OData.Measures.V1	Units and measures (Unit, ISOCurrency)
Authorization	Org.OData.Authorization.V1	Authorization metadata
Communication	com.sap.vocabularies.Communication.v1	Communication-related terms
Aggregation	Org.OData.Aggregation.V1	Data aggregation terms
Analytics	com.sap.vocabularies.Analytics.v1	Analytics features
PersonalData	com.sap.vocabularies.PersonalData.v1	Personal data handling
Validation	Org.OData.Validation.V1	Validation rules
CodeList	com.sap.vocabularies.CodeList.v1	Code lists for currencies and units (CurrencyCodes, StandardCode)

Commonly used terms

Core vocabulary

Term	Purpose
Description	Human-readable description of an element
LongDescription	Extended description
Computed	Property value is computed by the server

UI vocabulary

Term	Purpose
LineItem	Columns for a table display
FieldGroup	Fields for a form display
Hidden	Element should not be shown in UI
DisplayFormat	How to format a value (e.g., 'Date')
HeaderInfo	Header for an object page
SelectionFields	Fields shown as filter bar items

Common vocabulary

Term	Purpose
Label	Display label for a property
Text	Human-readable text representation
ValueList	Configuration for a value help dialog
SemanticKey	Properties forming a human-readable key

Capabilities vocabulary

Term	Purpose
FilterRestrictions	Which properties support filtering
SortRestrictions	Which properties support sorting
CountRestrictions	Whether $count is supported

Using vocabulary classes as PHP attributes

Each vocabulary term is a PHP class that implements TypedAnnotationInterface. These classes can be used as PHP attributes on your model classes and properties. When registered via discoverModel(), ModelDiscovery reads them automatically and includes them in the $metadata output.

Class-level annotations work directly on the model class:

use LaravelUi5\OData\Vocabularies\Core\V1\Description;

#[Description('A flight entity')]
class Flight extends Model
{
    // ...
}

Property-level annotations go on the class too, in an #[ODataAnnotate] that names the column:

use LaravelUi5\OData\Service\Discovery\Attributes\ODataAnnotate;
use LaravelUi5\OData\Vocabularies\Ui\V1\Hidden;

#[ODataAnnotate('internal_code', new Hidden())]
class Flight extends Model
{
}

changed in 4.0They used to need a PHP 8.4 hooked property on the model.

How a term class takes its value since 4.0

Every term class has its value as constructor parameters and a qualifier last. What the value is follows the term's type in the vocabulary:

The term's type	Example	Written as
A primitive	new Label('Product')	String="Product", Int, Bool, …
An enumeration	new FieldControl(FieldControlType::Mandatory)	EnumMember="…FieldControlType/Mandatory"
A flags enumeration	new Permissions([Permission::Read, Permission::Write])	the members, space-separated
A collection of records	new LineItem([new DataField(value: new Path('name'))])	one <Record Type="…"> per element
One record	new PresentationVariant(maxItems: 10, includeGrandTotal: true)	a <Record> with the fields you set
An open primitive type	new Minimum(0), new Minimum('2026-01-01', EdmPrimitiveType::Date)	the kind of the value, or the one you name
A boolean marker	new Hidden()	the term without a value

In every row a Path can stand in for the value; see Path values.

• Record types are classes too. DataField, SortOrderType, CodeListSource and the rest are the vocabulary's complex types, with its inheritance: a term that takes UI.DataFieldAbstract accepts every record type deriving from it.
• Pass fields by name. Each field of a record, and each field of a term whose type is one record, is a named, optional parameter. Your editor shows the vocabulary's description of each.
• What the vocabulary requires is checked when the schema is built. A missing required field, a term without the value it needs, or a plain value where the vocabulary wants a record throws a LogicException that names it.

changed in 4.0Collection terms took a list of strings, record fields were written as strings, enumerations as integers and booleans in a form UI5 did not read. Required fields were required constructor parameters, ahead of the optional ones, and `Minimum`, `Maximum` and the other terms of an open primitive type took the `EdmPrimitiveType` first. All of them now follow the table above.

See Applying Annotations for the full explanation and both attribute-based and programmatic approaches.