Mobile Application
A mobile app identity with the app name and target platforms.
Fields
2 required · 3 recommended. Every field points at its schema.org property — the definition lives in one place, so nothing drifts. The full inherited superset stays available through @0xintuition/schema-org.
| Field | Type | Description | |
|---|---|---|---|
name |
string | required | The mobile application name. schema.org/name |
operatingSystem |
string | required | The supported operating systems. schema.org/operatingSystem |
applicationCategory |
string | optional | The app category when needed. schema.org/applicationCategory |
downloadUrl |
url | optional | The store or download URL. schema.org/downloadUrl |
sameAs |
string[] | optional | Canonical URLs that identify the same mobile application. schema.org/sameAs |
The canonical shape
What a Mobile Application atom's data looks like. These exact bytes are what calculateAtomId hashes — shared shape is shared identity.
{
"@context": "https://schema.org/",
"@type": "MobileApplication",
"name": "Spotify",
"operatingSystem": "iOS, Android",
"applicationCategory": "Music",
"downloadUrl": "https://apps.apple.com/app/spotify/id324684580"
}
import { buildAtomData } from "@0xintuition/classifications";
import { calculateAtomId } from "@0xintuition/ids";
const atomData = buildAtomData("mobile-application", {
name: "Spotify",
operatingSystem: "iOS, Android",
applicationCategory: "Music",
});
// deterministic — same bytes, same ID, offchain and on
const atomId = calculateAtomId(atomData);
What a Mobile Application can say
The recommended triple vocabulary for this classification — each row is a claim shape the graph already understands, with the kind of atom expected on the other end.
Enrichment
Paste a bare reference and the enrichment engine fills a Mobile Application in from its sources (default pipeline: mobile-application) — titles, canonical sameAs URLs, and the fields above, merged onto the same deterministic atom.