The entity that a VerifiableCredential makes claims about — most often an Actor identified by a DID or WebID.

The subject of the claim is not necessarily the *holder* of the credential — a parent might hold a credential about their child, or an organisation might hold one about an employee. Modelled as an Object with whatever properties the claim asserts; multiple subjects are permitted via an array.

A credential asserting a degree


The page of an ActivityStreams Collection that contains the most recent items — clients seeking "what's new" start here rather than at `first`.

urn:solid:Collection urn:solid:first urn:solid:last urn:solid:next urn:solid:prev

Distinct from `as:first` and `as:last`: `current` is the *live edge* of a Collection that grows over time. For an inbox or a follower list, `current` is where new arrivals appear; older items live further along the chain. Servers without a meaningful "current" notion may omit it.

Inbox with a current page pointer


A project the person is currently active on.

Repeat to list multiple active projects. Move to `foaf:pastProject` when the person stops being involved. The value can be any resource — typically a `urn:solid:Project` or a `urn:solid:Document` describing the project.

Person actively working on a project


A point or period of time associated with the resource — generic when more specific date predicates don't apply.

Generic date property — prefer the more specific `urn:solid:created`, `urn:solid:modified`, `dcterms:issued`, `dcterms:available` when the role of the date is known. Useful for legacy data or when the date's role is unclear. ISO 8601 values.

Resource with a generic date


The date the resource was formally accepted — typically by a publisher, peer reviewer, or governing body.

Common in academic publishing — captures the gap between submission, acceptance, and publication. Pair with `dcterms:dateSubmitted` and `urn:solid:issued`. ISO 8601 date.

Paper with submit/accept/publish dates


The date of a statement of copyright over the resource.

The copyright year, distinct from `urn:solid:dateCreated` (when the work was made) and `urn:solid:issued` (when published). Often the same year as creation but can differ for posthumous publication or transferred rights. ISO 8601 date.

Document with copyright date


Schema.org's creation timestamp. Functionally equivalent to `dcterms:created` (`urn:solid:created`); pick by namespace flavor — schema.org for SEO-rich JSON-LD on web pages, dcterms for bibliographic/library data.

Article with creation date


The date the resource was last modified.

Schema.org's modification timestamp — equivalent to `dcterms:modified` (`urn:solid:modified`) and `as:updated` (`urn:solid:updated`). ISO 8601. Pair with `urn:solid:dateCreated` for the create-then-edit lifecycle.

Article with creation and modification dates


The date the resource was published — when it became publicly available.

Schema.org's publication timestamp — equivalent to `dcterms:issued` (`urn:solid:issued`) and `as:published` (`urn:solid:published`). Distinct from `urn:solid:dateCreated`: an article can be drafted in private (created) and released later (published). ISO 8601.

Article with publication date


The date the resource was formally submitted — typically to a publisher, conference, or review process.

Pair with `urn:solid:dateAccepted` and `urn:solid:issued` for the full submission → review → publication timeline. Common in academic publishing, grant applications, RFC processes. ISO 8601 date.

Paper with submission date


Marks an Authorization as the default access policy inherited by descendants of a Container.

urn:solid:Authorization urn:solid:accessTo urn:solid:Container urn:solid:mode

Value is a Container URI. The Authorization then applies — by inheritance — to every resource inside that Container (recursively) which does not have its own ACL. Replaces the older `acl:defaultForNew`. Without `default`, an Authorization on a Container governs only the Container resource itself, not its members.

Authorization that grants Read by default to a subtree


A complete explanation of the intended meaning of a SKOS Concept.

Use a single, dictionary-style sentence per language (multilingual via `@language`). Distinct from `urn:solid:scopeNote` (guidance on how to use the concept) and `urn:solid:description` (general dcterms description).

Concept with a definition

A branch of mathematics that studies abstract structures and their relationships via objects and morphisms.


On an ActivityStreams Tombstone, the date-time at which the original Object was deleted.

Always an `xsd:dateTime`. Pair with `as:formerType` so consumers know both *when* and *what* was deleted. Together they let UIs render "Note deleted at 14:32" instead of an opaque error when a previously-cached link points to a removed Object.

Tombstone with deletion timestamp


The value is the IRI of the image itself, not a document containing it. Inverse of `foaf:depicts`. For a profile photo specifically, `vcard:hasPhoto` is often more appropriate in vCard-flavored data.

Person with an avatar


The Object that an ActivityStreams Profile is about — links a profile-style description to its subject.

Reciprocal of the conceptual "profile of" relationship: a Profile uses `as:describes` to point at the entity it documents. Lets descriptive payloads (long bios, alternate display variants) live as separate, fetchable Objects without polluting the subject's primary record.

A Profile describing an Actor


An account of the resource — a free-text description.

Multi-sentence prose describing what the resource is or contains. For a one-line summary, prefer `rdfs:comment` (which is what RDF tooling usually surfaces); for a tagline, `dcterms:abstract`. Repeat with language tags for translations.

Document with description

An introduction to the urn-solid registry and how to use it.

Promoted schema:description from seeAlso to owl:sameAs and added ical:description — same free-text-description predicate across all three vocabularies.


Asserts that two OWL individuals are *not* the same — explicit negation, useful in worlds where the open-world assumption would otherwise leave identity ambiguous.

Symmetric — `A differentFrom B` implies `B differentFrom A`. Distinct from `owl:disjointWith` (which separates *classes*); `differentFrom` separates *individuals*. Necessary because RDF doesn't assume Unique Name Assumption: without `differentFrom`, two distinctly-named resources might still be merged by reasoners.

Two people explicitly marked as different


Asserts that two OWL classes have no instances in common — nothing can be both at once.

Symmetric: if A is disjoint with B, B is disjoint with A. Reasoners use this to detect contradictions: declaring an instance as both `Living` and `Deceased` (when those are disjoint) flags the data as inconsistent. Use sparingly — many seemingly-disjoint pairs turn out to overlap in edge cases.

Person and Document are disjoint classes


Declares which class an RDF property is meant to be applied to — its subject type.

Subject-side constraint: `acl:agent` has domain `acl:Authorization` because authorisations are what carry it. Multiple domain triples mean the property applies to instances of *all* the listed classes (intersection), not any of them — a common trap.

Property declaring its subject type


A direct file URL where a DCAT Distribution can be downloaded.

Distinct from `urn:solid:accessURL`: `downloadURL` is a *direct* file link (returns the bytes), `accessURL` is any landing page or API entry point. A Distribution typically has one or the other.

Distribution with a download URL


The end date-time of an iCalendar Vevent — when the event finishes.

Mirrors `dtstart`. RFC 5545 treats `dtend` as exclusive — an event from 15:00 to 16:00 has `dtend = 16:00` even though no event occurs at 16:00:00 itself. Distinct from `as:endTime` (ActivityStreams equivalent).

Event end time


The start date-time of an iCalendar Vevent or Vtodo — when the event begins or when the task becomes actionable.

urn:solid:Vevent urn:solid:Vtodo urn:solid:dtend urn:solid:startTime

iCalendar's date-time form, distinct from `as:startTime` (ActivityStreams). Use `dtstart` when you need iCal/CalDAV interop. May carry timezone via XSD typed values or a separate property — full RFC 5545 timezone handling is more nuanced than basic `xsd:dateTime`.

Event start time


How long the object lasts — for time-bounded objects like events, audio, or video.

An `xsd:duration` value (ISO 8601 — e.g. `"PT3M30S"` for 3 minutes 30 seconds). Used on Events, audio/video objects, and any time-bounded thing. For start/end points, use `urn:solid:startTime` and `urn:solid:endTime` instead.

Audio object with a duration

Added ical:duration to owl:sameAs — same xsd:duration semantics.


The editor of a CreativeWork — typically a Person who supervised, revised, or curated the content.

Distinct from `urn:solid:author` (the writer) and `urn:solid:contributor` (general secondary participants): `editor` specifically names the editorial responsibility — the person who shaped, reviewed, or curated the work. Repeat for multiple editors.

Anthology with author and editor


A SKOS note for vocabulary maintainers — internal guidance, open questions, things to revisit later. Not intended for end users.

urn:solid:Concept urn:solid:changeNote urn:solid:historyNote urn:solid:scopeNote

The "TODO" of the SKOS note family — "check whether this should subsume Y", "awaiting decision from working group". Renderers SHOULD hide editorial notes from public displays, surfacing them only in editing UIs.

Concept with an editorial note

Reconsider scope after the WG ratifies the new taxonomy in Q3.


The general education level the resource targets — primary, secondary, undergraduate, professional, etc.

Used in educational-resources metadata to declare what level of learner the resource is suitable for. Value is typically a controlled-vocabulary term (e.g. from a `schema:DefinedTerm` set) or a free-form string when no controlled vocab applies.

Course material targeting undergraduates


An email address for the subject, as a plain string.

Schema.org's simple string-valued email predicate (`"alice@example.org"`). Distinct from `urn:solid:mbox` (FOAF, uses a `mailto:` IRI and is inverse-functional) and `urn:solid:hasEmail` (vCard, typically points at a structured vcard:Email). Use whichever matches your data source.

Person with an email string


ISO 8601 datetime marking when an Event, Activity, or other time-bounded object ends. Pair with `urn:solid:startTime`. May be omitted for ongoing or open-ended objects. For PROV-grade activity timing, prefer `prov:endedAtTime`.

Conference session with end time


PROV-grade activity-end timestamp. Pair with `urn:solid:startedAtTime` to record execution windows. May be omitted for ongoing activities. ActivityStreams `urn:solid:endTime` is the equivalent for AS Events; pick by domain — PROV for processes, AS for calendar events.

Build with start and end timestamps


A machine-readable description of how to interact with a DCAT DataService — e.g. an OpenAPI document or SPARQL Service Description.

`endpointURL` is *where* to call; `endpointDescription` is *how* to call it. Common values: a SPARQL 1.1 Service Description graph, an OpenAPI/Swagger JSON document, a Hydra ApiDocumentation. Without a description, clients must rely on out-of-band knowledge of the protocol.

Service with a SPARQL service description


The root URL of a DCAT DataService — the address a client connects to to invoke the service.

Names the operational entry point. For a SPARQL endpoint, the query URL; for a REST API, the base URI. Pair with `dcat:endpointDescription` (a machine-readable description of how to talk to it — OpenAPI doc, SPARQL service description) when the service is non-trivial.

DataService exposing a SPARQL endpoint


Container for additional service endpoints exposed by an ActivityPub Actor — most importantly `sharedInbox`, but also `proxyUrl`, OAuth endpoints, and others.

Value is an Object whose properties are well-known endpoint names. The most-used in practice is `sharedInbox` (a single inbox URL serving multiple Actors on the same server, used to deduplicate fan-out). Federated servers SHOULD prefer `endpoints.sharedInbox` over per-Actor `inbox` when delivering the same Activity to many local recipients.

An Actor advertising a sharedInbox


Asserts that two OWL classes have identical extensions — every instance of one is also an instance of the other and vice versa.

urn:solid:Class urn:solid:subClassOf urn:solid:sameAs urn:solid:equivalentProperty

Stronger than mutual `subClassOf` — `equivalentClass` is two-way subclass, but as a single assertion it makes the equivalence explicit for reasoners. Distinct from `owl:sameAs`, which equates *individuals*. Use to bridge two parallel class hierarchies (e.g. `foaf:Person` and `schema:Person`).

Two upstream Person classes equated


Asserts that two OWL properties always relate the same subjects to the same objects — interchangeable in any triple.

Property analogue of `owl:equivalentClass`. Stronger than mutual `subPropertyOf`. Use to bridge identical predicates across vocabularies — `foaf:name` and `schema:name` are commonly equated this way for cross-vocab interop.

Equating two upstream name predicates


A SKOS mapping asserting that two Concepts in different ConceptSchemes are equivalent for retrieval purposes.

Symmetric and transitive — assert sparingly because chains can produce surprising equivalences across vocabularies. For weaker similarity that doesn't claim full equivalence, prefer `urn:solid:closeMatch`. Use across SKOS schemes; within one scheme, use `urn:solid:broader`/`narrower`/`related` instead.

Concept matching across vocabularies


An example illustrating the use of a SKOS Concept.

Editorial property for cataloguers — provides a sample use of the concept. Repeat for multiple examples. Mirrors the per-term `examples` arrays on urn-solid term files (which are JSON-LD snippets, while `skos:example` is plain prose).

Concept with an example

The List monad in Haskell — sequences with bind/return.


The date-time at which a VerifiableCredential ceases to be valid — verifiers SHOULD reject it after this instant.

Optional — credentials without an expiration are open-ended. VC 2.0 renames this to `validUntil`; both are seen in the wild. Distinct from revocation: expiration is set at issuance and absolute; revocation is dynamic and consulted via `credentialStatus`.

A credential valid for one year


The size or duration of the resource — pages, bytes, runtime length.

Free-form size/duration string in dcterms tradition ("320 pages", "45 minutes", "2.4 MB"). For machine-readable durations specifically, prefer `urn:solid:duration` (xsd:duration). For byte counts, use `schema:contentSize` directly.

Book with extent


The vCard family name (surname) of a person.

vCard's hyphenated form of the family name — distinct from FOAF's `urn:solid:familyName` (camelCase) only by namespace. Pick `family-name` in vCard-flavored data, `familyName` in FOAF/schema-flavored data. Functionally equivalent.

vCard with family name


The family name (surname) of the person.

Modern preferred form (the older `foaf:family_name` and `foaf:surname` are seen too — kept under `rdfs:seeAlso`). Pair with `foaf:givenName` for structured names. Use `urn:solid:name` for a single combined display name.

Person with structured name


The first page of a paginated ActivityStreams Collection — the entry point a client uses to start walking the pagination chain.

urn:solid:Collection urn:solid:last urn:solid:next urn:solid:prev urn:solid:current

On a Collection that is too large to inline, `as:first` points at a CollectionPage which can be followed via `next` (and optionally back via `prev`). For ordered collections (`as:OrderedCollection`), `first` is the chronologically/structurally earliest page; for unordered, the order is server-defined.

Paginated outbox


Older sibling of `foaf:givenName` — kept for compatibility with legacy FOAF data. New profiles should prefer `foaf:givenName` (modeled as `urn:solid:givenName` once added) and `foaf:familyName`. The semantic distinction between first/given is culture-bound; treat them as equivalent in practice.

Person with a first name


Formatted name — the display name of the subject as a single string.

vCard's canonical display-name property — carries the full formatted form ("Alice Liddell"), not the structured given/family fields. `urn:solid:name` is FOAF's equivalent; prefer it for non-vCard data. For structured names, use `urn:solid:givenName` + `urn:solid:familyName`.

vCard with a formatted name


An agent that follows the subject — receiving updates from them.

Schema.org's reverse follower relation (their `schema:follows` is symmetric in the spec but typically used as inverse of `schema:follows`). For ActivityPub, the typical pattern is an `as:Followers` Collection at `as:followers` on the subject; for this lightweight schema.org form, just enumerate followers directly.

Person with a follower


The Collection of Actors who follow an ActivityPub Actor — used both for delivery (servers fan Activities out to followers) and for display.

urn:solid:Actor urn:solid:following urn:solid:Follow urn:solid:inbox

The Actor's audience — addressed as `as:to: <followers-uri>` in many activities to broadcast to the Collection without enumerating each follower. Servers may keep this Collection private (returning only `totalItems`) for privacy. Inverse direction is `as:following`.

An Actor exposing a followers Collection


The Collection of Actors that an ActivityPub Actor follows — the source side of the social graph.

Mirror of `as:followers`. Each entry is an Actor whose Activities the subject has subscribed to via a `Follow` activity. May be private (just a count) for privacy-sensitive deployments.

An Actor exposing a following Collection


The RDF class that a TypeRegistration is for — what type of resources live at the registered location.

The discriminator for TypeIndex lookups: when an app wants to know "where do this user's photos live?", it scans the TypeIndex for a registration whose `forClass` matches the relevant class IRI (e.g. `foaf:Image`).

Registration matched by forClass


The file format, physical medium, or dimensions of the resource.

Use an IANA media type string (`text/html`, `application/ld+json`, `image/png`) for digital resources. For physical media or non-MIME formats, free-form descriptive text is acceptable. Range can also be a `dcterms:MediaType` resource for richer modelling.

JSON-LD document with a format


On an ActivityStreams Tombstone, the type the deleted Object had before it was removed — preserves enough metadata for clients to know what they lost.

After deletion, the Tombstone replaces the original Object at its URL. `as:formerType` records what `@type` it used to have (a `Note`, an `Image`, an `Article`); `as:deleted` records when. Together they let renderers display "a deleted Note" rather than just an opaque hole.

A Tombstone for a deleted Note


The gender of the agent — a free-form string in FOAF tradition.

Privacy-sensitive. FOAF intentionally uses a free-form string rather than an enumerated type so identity can be self-described. `schema:gender` accepts either a `GenderType` (enum) or a string; `vcard:hasGender` uses an enumerated controlled vocabulary. Use whichever matches the consumer.

Person with self-described gender


Inverse of `prov:wasGeneratedBy` — the Entity that this Activity produced.

urn:solid:Activity urn:solid:wasGeneratedBy urn:solid:used urn:solid:invalidated

Convenient when describing the world from the Activity's perspective ("what did this run produce?"). Either direction is valid; pick whichever makes the focal entity the subject. Pair with `prov:used` (inputs) and `prov:invalidated` (entities the Activity consumed/destroyed).

Activity that generated a dataset


The time at which the entity was completely generated by some activity.

PROV's precise generation timestamp — paired with `prov:wasGeneratedBy` it lets you record exactly when a build, run, or process completed. Use `urn:solid:created` for lightweight "when was this resource made" without the PROV ceremony.

Build artifact with generation time


The application that generated the object — typically a software client or service.

ActivityStreams' "created with" attribution — the value is the client app (e.g. a Mastodon instance, a Solid app). Distinct from `urn:solid:wasGeneratedBy` (PROV-grade activity attribution): generator names *what software*, wasGeneratedBy names *what process run*.

Note generated by a client app


The vCard given name (first name) of a person.

vCard's hyphenated form of the given name — distinct from FOAF's `urn:solid:givenName` (camelCase) only by namespace. Pick `given-name` in vCard-flavored data, `givenName` in FOAF/schema-flavored data. Functionally equivalent.

vCard with structured name


The given name of a person — the personal name distinct from the family name.

Modern preferred form for the personal/first name component. Pair with `urn:solid:familyName` for structured names. The older `foaf:firstName` is treated as equivalent in most consumers; prefer `givenName` for new data.

Person with structured name


An activity that contributed to a qualified PROV relation — typically attached to a qualified usage, generation, or derivation.

Used inside qualified PROV relations (`prov:qualifiedDerivation`, `prov:qualifiedUsage`, `prov:qualifiedGeneration`) to name the specific Activity that mediated the relation. Lets you attach a Plan, Role, or timing to the connection.

Derivation referencing the activity that produced it


Links a use of an Entity to the qualified Generation event in which that Entity was created — letting consumers reason about which version was used.

urn:solid:Entity urn:solid:wasGeneratedBy urn:solid:qualifiedUsage urn:solid:qualifiedDerivation

Used inside qualified PROV patterns — e.g. on a `prov:Usage` instance, `prov:hadGeneration` points to the `prov:Generation` of the entity that was used. Pairs naturally with `prov:hadActivity` to fully reconstruct the lineage of a specific use.

Qualified Usage citing the source Generation


An entity that was a member of a PROV Collection.

PROV's collection-membership predicate (`prov:Collection` is distinct from `as:Collection` and `ldp:Container`). Use only in PROV-flavored contexts; for FOAF Group membership use `urn:solid:member`, for vCard Group use `urn:solid:hasMember`, for LDP containers use `urn:solid:contains`.

PROV Collection with members


The Plan that an Activity followed — used inside a qualified PROV Association.

Used inside a `prov:Association` to point at the `urn:solid:Plan` the Agent followed when participating in the Activity. Lets PROV record "who acted, with what role, following which plan" — a build run executes a build plan; a paper review follows a review checklist.

Association with a plan


An entity that is the primary source — the original first-hand source — for the subject entity.

PROV's primary-source predicate, a specialization of `prov:wasDerivedFrom`. "Primary source" means original/first-hand — the eyewitness account, the raw measurement, the canonical document. For derivations more generally (translations, summaries, transformed datasets), `urn:solid:wasDerivedFrom` is broader.

News article with a primary source


The role an Agent or Entity played in a qualified PROV relation — "author", "editor", "raw input", etc.

Used inside qualified PROV relations to name the role taken. Distinct from `urn:solid:role` (vCard's job-title string): `hadRole` is specifically about role within an Activity or Attribution. Value is typically a `prov:Role` resource (which can be any IRI).

Attribution with a role


Inside a qualified PROV pattern, links to the `prov:Usage` event whose entity participated in this relationship — typically used on a `prov:Derivation` to record the use that supplied its input.

urn:solid:Activity urn:solid:hadGeneration urn:solid:qualifiedUsage urn:solid:qualifiedDerivation

A connector between qualified PROV events. On a `prov:Derivation`, `prov:hadUsage` points at the `prov:Usage` of the input entity by the activity, and `prov:hadGeneration` points at the `prov:Generation` of the output. Together they reconstruct the precise link between two entities through an activity.

Derivation citing the Usage of its source


A postal address associated with the subject.

The value should be a `vcard:Address` (or `schema:PostalAddress`) resource carrying structured fields — `vcard:street-address`, `vcard:locality`, `vcard:postal-code`, `vcard:country-name`. For an approximate "based near" location, use `urn:solid:basedNear` instead.

Person with a postal address


A URL of the subject's free/busy calendar — shows availability without exposing event details.

Distinct from `urn:solid:hasCalendarLink` (full calendar with event details). Use for a privacy-preserving free/busy feed — schedulers can find open slots without seeing what's on. Typically a CalDAV free-busy URL or .ifb file.

vCard with a free/busy URL


A URL of the subject's calendar — typically an iCalendar (.ics) feed or web calendar.

Use to point at a public calendar — an .ics URL, a CalDAV endpoint, or a calendar page. For subscriber-friendly links, use a `webcal:` URI; for plain HTTPS, the consumer must know how to subscribe. Distinct from `urn:solid:hasCalendarBusy` (free/busy availability only).

vCard with a public calendar


A vCard's URL for accepting calendar requests — the endpoint where meeting requests, scheduling proposals, or iCalendar invitations should be sent.

vCard analogue of the iCalendar CALADRURI property. Distinct from `vcard:hasCalendarLink` (a public calendar URL to *view*) and `vcard:hasCalendarBusy` (free/busy lookup) — `hasCalendarRequest` is specifically the *write* endpoint for inbound scheduling.

A VCard exposing a scheduling endpoint


A category or tag for the vCard — describing what kind of contact it is.

vCard's category/tag predicate — typical values are "work", "personal", "family", "friend". Repeat for multiple categories. For general-purpose tagging of resources (not specifically vCards), prefer `urn:solid:keywords` or `urn:solid:subject`.

vCard categorized as a work contact


An email address associated with the subject — typically a `mailto:` IRI.

vCard's general email predicate: not inverse-functional and free of FOAF's strong identity semantics. Use `urn:solid:mbox` when the email uniquely identifies the agent (FOAF tradition). Multiple `hasEmail` values are typical (work, personal, etc.).

Person with email


A related resource that is the same intellectual content but in a different format — e.g. a PDF version of an HTML article.

Distinct from `urn:solid:hasVersion`: same content, different file format (PDF vs HTML, MP3 vs FLAC, JSON-LD vs Turtle). Inverse is `dcterms:isFormatOf`. The format itself is described by `urn:solid:format`.

Article available in PDF and HTML


The gender of the agent — typically referencing one of vCard's enumerated Gender values.

vCard's typed gender predicate, distinct from FOAF `urn:solid:gender` (free-form string). Value is typically a `vcard:Male`, `vcard:Female`, `vcard:Other`, `vcard:None`, or a custom resource. Privacy-sensitive — collect only when needed.

vCard with a typed gender


Geographic coordinates associated with the subject — typically a `geo:` IRI carrying lat/long.

Use a `geo:` URI (e.g. `geo:51.5074,-0.1278`) for the value. For richer coordinate modelling with separate lat/long predicates, use `schema:GeoCoordinates` or the WGS84 `geo:` ontology.

Address with geo coordinates


An instant-messaging address for the subject — typically an `xmpp:`, `matrix:`, or other chat URI.

vCard's general IM-address slot — covers any chat protocol via URI scheme (`xmpp:`, `matrix:`, `irc:`). Distinct from FOAF's `urn:solid:jabberID` which is XMPP-specific and a bare string. Repeat for multiple IM identities.

vCard with a Matrix handle


A cryptographic public key associated with the vCard's owner — for encryption or signature verification.

vCard's lightweight public-key pointer. Value is typically a URL of the key file (PGP, SSH, X.509). For richer key metadata (algorithm, usage, controllers), use the W3C Security Vocabulary. Repeat for multiple keys (encryption, signing, etc.).

vCard with a PGP key URL


A language the subject communicates in — typically a BCP 47 language tag.

vCard's communicates-in-language predicate. Functionally similar to schema's `urn:solid:knowsLanguage`; pick whichever matches your data flavor. Distinct from `urn:solid:language` (the language a *resource* is in). Value is typically a BCP 47 tag.

vCard with preferred languages


A logo image associated with the vCard — typically the brand mark of an Organization.

Use on Organization vCards for the brand mark. Distinct from `urn:solid:hasPhoto` (typically a person's portrait). Schema.org's equivalent is `schema:logo`. Value can be a URL or a `urn:solid:Logo` resource.

Organization with a logo URL


vCard's group-membership predicate. Distinct from `urn:solid:member` (FOAF) only by namespace; functionally the same. Use `hasMember` in vCard-flavored data, `member` in FOAF-flavored data. Repeat for multiple members.

vCard Group with members


The predicate that should be used to express membership in a DirectContainer or IndirectContainer.

Used on a `DirectContainer` or `IndirectContainer` to declare which predicate the server should add when a new resource is POSTed — e.g. `schema:comment` so a new POST to a comments container produces `<post> schema:comment <new-comment>`. Alternative: `ldp:isMemberOfRelation` for the inverse direction.

Comments container declaring its member relation


A structured Name resource for the subject — separates given/family/additional/prefix/suffix into a Name object.

Use when name parts need to live on a separate Name resource (e.g. for multi-script names or when the parts have their own metadata). Most data instead attaches `given-name`/`family-name`/etc. directly to the VCard. The flat-string form is `urn:solid:fn`.

vCard with a structured Name


vCard's nickname predicate — the structured equivalent of FOAF's `urn:solid:nick`. Pick `hasNickname` in vCard-flavored data, `nick` in FOAF-flavored data. Repeat for multiple nicknames.

vCard with a nickname


A related resource that is included as a part of the described resource.

Inverse of `urn:solid:isPartOf`. Use to enumerate the constituent parts of a compound resource (chapters of a book, articles in a journal issue, photos in an album). Repeat for multiple parts.

Book with chapters


A photo associated with the subject — typically a portrait.

vCard's photo predicate. Functionally similar to `urn:solid:img`; pick `hasPhoto` in vCard-flavored data and `img`/`depiction` in FOAF-flavored data. Multiple values are typical (gallery, alternates, sizes).

Person with a photo


A related contact for the vCard — typically another person (spouse, child, colleague) connected to the subject.

vCard's general inter-contact relation. Pair with `vcard:hasRelatedType` (work-colleague, family, etc.) for typed relations. Distinct from SKOS `urn:solid:related` (between Concepts) and from FOAF `urn:solid:knows` (between Persons in a social-graph sense).

vCard pointing at a related contact


A vCard's URL pointing at an audio recording — typically a pronunciation of the name or a personal voice intro.

Carried over from RFC 6350 (vCard 4.0) — primarily used for name-pronunciation clips so callers say the name correctly. Niche today; mainstream contact apps mostly ignore it. Modern equivalent is a Profile-attached `as:Audio` Object.

A VCard with a pronunciation recording


A source document for the vCard's information — typically a website or directory the data came from.

vCard-specific source pointer — analogous to `dcterms:source` (`urn:solid:source`) but scoped to vCards and typed for the directory-import scenario. Useful when a contact card was scraped or auto-imported and you want to record the upstream URL.

vCard with an upstream source


An OrganizationalUnit (department, team, division) that is part of the parent Organization.

Inverse of `urn:solid:subOrganizationOf`. Use to enumerate departments/units belonging to a parent. Repeat for multiple subunits.

Company with engineering and sales units


A telephone number associated with the subject — typically a `tel:` IRI.

Use a `tel:` URI (e.g. `tel:+44-20-1234-5678`) for the value, not a bare string. Repeat for multiple numbers. For typed numbers (work/home/mobile), the value can be a `vcard:Tel` resource carrying `vcard:hasValue` and `rdf:type` of one of the work/home/cell sub-types.

Person with a phone


A top-level (root) Concept of the SKOS ConceptScheme — has no broader concept within the scheme.

Use on a ConceptScheme to enumerate its entry-point Concepts — those with no `broader` parent in the scheme. Inverse is `urn:solid:topConceptOf`. A scheme typically has a small handful of top concepts; repeat for each.

Scheme with two top concepts


A topic or tag — used by Bookmarks (and other resources) for free-form classification.

Originally defined for Bookmarks but reusable wherever free-form tagging is needed. Values can be plain strings (folksonomy tags) or NamedNode references to Topic/Concept resources (controlled vocabularies). For ActivityPub-style hashtag references prefer `as:tag`; for schema.org-style keywords prefer `schema:keywords`.

Bookmark tagged with topics


A globally unique identifier for the vCard — typically a UUID or other long-lived ID.

vCard's persistent identifier — the value remains stable across edits, lets clients dedupe two card revisions for the same person. Often a `urn:uuid:`. Distinct from `urn:solid:identifier` (general-purpose secondary identifier); `hasUID` is specifically the vCard tradition's stable ID.

vCard with a UID


A URL associated with the subject — any web link, not necessarily the canonical homepage.

More general than `urn:solid:homepage` — use to enumerate any URLs (social profiles, project links, work pages). Repeat for multiple. Use `homepage` when the URL is the canonical, FOAF-style identifying homepage.

Person with multiple URLs


An OrganizationalUnit that is part of the parent Organization — narrower than `hasSubOrganization`.

Sub-property of `urn:solid:hasSubOrganization` constrained to OrganizationalUnits (so the value is always an internal unit, not another formal organization). Use when you want type-checking on the structure.

Company with internal units


On an OWL Restriction, asserts that the constrained property must have one specific value — the most precise form of class definition.

urn:solid:Restriction urn:solid:onProperty urn:solid:allValuesFrom urn:solid:someValuesFrom

"On property X, the value must be exactly this." Use to define classes like "Things whose `acl:mode` includes `acl:Read`." Value can be any individual or literal. Stronger than `someValuesFrom` (which only constrains the type, not the specific value).

A class of resources granting public read


A related resource that is a version, edition, or adaptation of the described resource.

Inverse of `urn:solid:isVersionOf`. Use on the abstract work to enumerate its versions/editions. Repeat for multiple versions; useful for spec families, software releases, document editions.

Spec series listing its versions


The headline of the article — a short, attention-grabbing title line.

Distinct from `urn:solid:name` — the headline is specifically the newsroom-style top line of an article ("Local CG Founder Ships Registry"), while `name` is the generic title. Keep headlines concise (schema.org recommends ≤ 110 characters).

Article with a headline


The height in pixels of an ActivityStreams Object — typically an Image, Video, or Link to a visual resource.

urn:solid:width urn:solid:Image urn:solid:Video urn:solid:Link

In pixels, not CSS units. Pair with `as:width` so renderers can reserve layout space and avoid reflow when the image loads. For multi-resolution variants, expose each as a distinct Link with its own height/width and let clients pick.

An Image with explicit dimensions


Inverse of `org:holds` — names the Agent currently filling an organizational Post.

Convenient for queries that start at a Post ("who is the CTO?"). For time-bounded historical assertions, model the relationship as a `org:Membership` instead — `heldBy` is a snapshot, not a record.

A Post and its current holder


A non-display label for a SKOS Concept — used to support search but not shown in UIs.

Use for misspellings, deprecated names, slang — strings users might search for that you don't want to surface in the UI. SKOS rule: `prefLabel`, `altLabel`, and `hiddenLabel` values must be pairwise disjoint within a language for the same Concept.

Concept with searchable misspellings


A SKOS note describing the history of a Concept — its origin, evolution, and how its meaning has shifted over time.

urn:solid:Concept urn:solid:changeNote urn:solid:editorialNote urn:solid:scopeNote

Narrative rather than transactional: where the term came from, why it exists, how usage has changed. Distinct from `changeNote` (specific edit log) and `editorialNote` (curator working notes). Public-facing — useful in glossaries and documentation pages.

Concept with a history note

Coined by Norbert Wiener in 1948; usage broadened through the 1960s to cover any feedback-driven system.


On a VerifiablePresentation, the Actor presenting the credentials — typically (but not always) also the credentialSubject.

Three roles in a typical VC flow: `issuer` (signs the credential), `credentialSubject` (the entity it makes claims about), `holder` (the entity presenting it now). They're often the same Actor but can diverge — a parent holding a credential about their child, an organisation holding one about an employee.

A presentation with an explicit holder


An ORG Post (position) that an Agent currently holds within an Organization.

Use to declare that a Person currently occupies a named Post (org:Post) — "holds the position of CTO". A Post is a stable, identified position that may be held by different people over time, distinct from Membership (which is the participation event itself).

Person holding a position


A homepage for the subject — a top-level page about the agent.

Inverse-functional in FOAF: a homepage uniquely identifies its agent. Use the IRI of the actual page, not a description of it. For arbitrary URLs that are not the canonical homepage, prefer `schema:url` or `vcard:hasURL`.

Person with a homepage


An honorific prefix preceding the person's name — Mr, Mrs, Dr, Prof, etc.

vCard's honorific prefix — culture-specific. Pair with `urn:solid:honorific-suffix` for postnominals (PhD, Esq.). Schema.org equivalent is `schema:honorificPrefix`. Note the hyphen in the source name is preserved.

Person with honorific prefix


An honorific suffix following the person's name — PhD, Esq, Jr, Sr, etc.

vCard's postnominal field — degrees, generational suffixes, certifications. Pair with `urn:solid:honorific-prefix`. Schema.org equivalent is `schema:honorificSuffix`. Repeat for multiple postnominals ("PhD, FRS").

Person with honorific suffix


The target URL of an ActivityStreams Link — the resource the Link points at.

urn:solid:Link urn:solid:Mention urn:solid:Hashtag urn:solid:rel

The defining property of a Link — without `href` a Link has no destination. Distinct from `@id` (the Link object's own identifier, often omitted): `@id` identifies the Link, `href` identifies what it links to. Used heavily by `Mention` and `Hashtag` to point at the mentioned actor or topic feed.

A Link with href and rel


The language of the resource at an ActivityStreams Link's `href` — a BCP 47 language tag (`en`, `en-GB`, `pt-BR`).

Lets clients pick the right localisation when a Link offers translations. Pair with `as:rel: alternate` and a separate Link per language so consumers can choose. Mirrors HTML's `<a hreflang>` and Atom's `link/@hreflang`.

A localisation Link


A small image representing the object — typically a square avatar or favicon.

ActivityStreams' small-avatar slot — typically square, low-resolution, used as the visual identifier for an actor or object in lists. The value is an Image or a URL. For a full-size portrait, prefer `urn:solid:img` (FOAF) or `urn:solid:depiction`.

Person with an avatar icon


An unambiguous reference to the resource within a given context.

Use for non-URI identifiers (DOI strings, ISBN, internal IDs, UUIDs) where the resource also has a URI as its `@id`. The resource's primary identifier is its `@id`; this property records additional/secondary identifiers. Repeat to list multiple.

Article with a DOI


An image of the subject — typically a representative picture (avatar, cover, depiction).

Property form paired with the `urn:solid:Image` class. Maps to `schema:image`, the most widely deployed property for representative pictures (used by Open Graph consumers, search engines, and most social platforms). For the FOAF tradition, `foaf:img` (account photo) and `foaf:depiction` (any depiction) are related; pick `image` when matching schema.org / OGP semantics, `foaf:img` for explicit FOAF profile usage.

Person with an avatar image

Initial term — property form completing the Image/image case-pair (Image is foaf:Image; image is schema:image).


An image that represents the person — typically a headshot or portrait.

A sub-property of `foaf:depiction` specifically for a portrait of a person. Prefer `urn:solid:depiction` when the subject is any kind of thing or the image is not a portrait. A person may have at most one primary `img` but multiple `depiction` values.

Person with a portrait


Links a DCAT Distribution to the Dataset it represents — inverse of `dcat:distribution`.

urn:solid:Dataset urn:solid:Distribution urn:solid:downloadURL urn:solid:accessURL

Convenient when the data flow starts at a Distribution (e.g. "what dataset is this CSV part of?"). Either direction is valid; use `dcat:distribution` (Dataset → Distribution) when the Dataset is the focal entity, `dcat:inDataset` (Distribution → Dataset) when the Distribution is.

A Distribution pointing back at its Dataset


The language a CreativeWork is written in — typically a BCP 47 language tag.

Schema.org's resource-language predicate. Functionally equivalent to dcterms `urn:solid:language` — pick by namespace flavor (schema for SEO, dcterms for bibliographic). Distinct from `urn:solid:knowsLanguage` (an Agent's languages).

Article in English


An object the current object is a reply to.

Use to link a reply Note (or other object) back at its parent. Forms reply threads in ActivityPub. Repeat for replies addressing multiple parents (rare). The inverse `as:replies` lives on the parent and points at a Collection of replies.

Reply pointing at its parent note


The SKOS ConceptScheme that the Concept is a member of.

Declares membership of a Concept in a ConceptScheme. A Concept may belong to multiple schemes — repeat for each. The transitive scope of `broader`/`narrower` is bounded by `inScheme` membership.

Concept belonging to a topic taxonomy


An LDN inbox — a container that accepts notifications about the resource via HTTP POST.

From Linked Data Notifications (LDN). The value is a Container that accepts incoming notifications about the subject — anyone can POST to it to leave a notification (subject to access control). ActivityPub re-uses the concept under `as:inbox` (a separate but interoperable IRI).

Person with an inbox


On an IndirectContainer, the predicate the server uses to look up the actual member from the POSTed content.

Used only on `urn:solid:IndirectContainer`. Tells the server: "when a resource is POSTed, look up the value of *this* predicate inside it, and use *that* as the actual member." Common pattern: an IndirectContainer for likes uses `as:actor` so the membership target is the liker, not the Like activity itself.

IndirectContainer using insertedContentRelation


A single resource that's an instance of the class declared by the TypeRegistration.

Use when the user has exactly one instance — typically a settings document or singleton. For collections of instances under a directory, use `solid:instanceContainer` instead. A single TypeRegistration may carry multiple `solid:instance` values.

Registration for a single preferences file


A Container holding instances of the class declared by a TypeRegistration.

Use when the user's data of a given type lives in a directory that may hold many resources (photos in `/photos/`, notes in `/notes/`). Distinct from `urn:solid:instance`, which points at a single resource. A TypeRegistration uses one or the other, not both.

Registration pointing at a container


A process used to engender knowledge, attitudes, or skills using the resource — pedagogy.

Used in educational-resources metadata to describe the teaching method (lecture, problem-set, workshop, MOOC video). Value is typically a controlled-vocabulary term or free-form string. Pair with `urn:solid:educationLevel`.

A workshop's instructional method


An entity used by an ActivityStreams Activity to perform its action — e.g. a tool, a client application, or a means by which the Activity was carried out.

urn:solid:Activity urn:solid:object urn:solid:result urn:solid:target

Captures the *means* used (a microphone for a Listen, a camera for a View, a client app for a Create). Distinct from `as:object` (what was acted on) and `as:target` (where the action was directed). Often left implicit — populate when the instrument is itself a first-class entity worth referencing.

A Listen activity with an instrument


A page about a topic of interest to the agent.

The value is a page (document) representing the topic of interest, not the topic itself. For the topic resource directly (any Thing, not necessarily a Document), use `foaf:topic_interest`. Repeat to list multiple interests.

Person interested in a Wikipedia topic


OWL class expression: defines a class as the intersection of a list of other classes — instances of the new class are instances of all listed classes.

Logical AND across classes. Use to define "a class of things that are both X and Y" (e.g. an Author = Person ∩ has-published-Book). Value is an `rdf:List` of class IRIs or class expressions; reasoners use it to infer membership.

An anonymous class: Person who is also a Member


An Entity that this PROV Activity destroyed, consumed, or rendered unusable — after invalidation the Entity is no longer available for further use.

urn:solid:Activity urn:solid:Entity urn:solid:generated urn:solid:used

Models destruction or consumption explicitly: a delete operation invalidates a record, a publish step invalidates a draft. Distinct from `prov:used` (read without altering) and `prov:generated` (created). Useful in audit trails and data lifecycle tracking.

Deletion activity invalidating a record


The time at which an Entity ceased to exist.

End-of-life timestamp counterpart to `urn:solid:generatedAtTime`. Records when an Entity was deleted, retracted, expired, or otherwise ceased to exist. ISO 8601. Pair with `urn:solid:wasInvalidatedBy` for the responsible Activity.

Document with an invalidation timestamp


Asserts that two OWL properties are inverses — `A p1 B` if and only if `B p2 A`.

Reasoners use this to materialise the reverse direction without storing both. Classic pairs: `as:followers` / `as:following`, `dcterms:isPartOf` / `dcterms:hasPart`, `prov:wasGeneratedBy` / `prov:generated`. Symmetric properties (`owl:sameAs`, `foaf:knows`) are their own inverse.

isPartOf and hasPart as inverses


Points at the resource that *defines* a term — typically the vocabulary document the term was minted in.

A subproperty of `rdfs:seeAlso` with a stronger claim: the target is *the source of truth* for what the term means, not just related. Each `urn:solid:*` term in this registry could (and arguably should) point at `https://urn-solid.com/<Name>/` via `isDefinedBy`.

A term pointing at its definition


A related resource that is the same intellectual content of which the described resource is a different-format rendition.

Inverse of `urn:solid:hasFormat`. Use on the alternate-format rendition to point at the canonical resource it represents in another format. Distinct from `isVersionOf` (different version/edition, not just different format).

PDF pointing at canonical HTML


The predicate the server adds in the *inverse* direction when a new resource is POSTed to a DirectContainer or IndirectContainer.

Inverse-direction equivalent of `ldp:hasMemberRelation`: instead of `<membershipResource> <pred> <new>`, the server adds `<new> <pred> <membershipResource>`. Use whichever direction matches your data model. A container declares one of `hasMemberRelation` or `isMemberOfRelation`, not both.

DirectContainer using the inverse direction


A related resource of which the described resource is a part.

Inverse of `urn:solid:hasPart`. Use to point at the containing resource (the book a chapter belongs to, the journal an article appears in). One value per containing whole; repeat only if the resource genuinely belongs to multiple containers.

Chapter pointing at its book


A document of which the subject is the primary topic — the inverse of `primaryTopic`.

Use on a Person (or other thing) to point at the document that primarily describes them. The canonical case is a WebID: `<#me> foaf:isPrimaryTopicOf <profile-card>`. Inverse-functional in FOAF — the document uniquely identifies the subject, and vice versa.

Person pointing to their profile document


A related resource that references, cites, or otherwise points to the described resource.

Inverse of `urn:solid:references`. Use to enumerate the inbound citations or backlinks to this resource. Repeat for multiple. Often computed by aggregators rather than asserted by the resource itself.

Paper showing what cites it


A related resource that supplants, displaces, or supersedes the described resource.

Inverse of `urn:solid:replaces`. Use on the older resource to point at its successor — readers can follow the chain to the current version. The schema's `supersededBy` field on a urn-solid term file is the registry-internal equivalent.

v1 spec pointing at its successor


A related resource that requires the described resource to support its function or coherence.

Inverse of `urn:solid:requires`. Use on a dependency to enumerate downstream consumers — "this library is required by these projects". Often computed by package indexes rather than asserted by the resource itself.

Library showing what depends on it


A related resource of which the described resource is a version, edition, or adaptation.

Use to point at the abstract "work" the current resource is one version of. Distinct from `urn:solid:replaces` (which says "this supersedes that"); `isVersionOf` allows multiple concurrent versions of the same work without one displacing another.

v2 spec is a version of the spec series


The date-time at which a VerifiableCredential was issued — the credential is not considered valid before this instant.

Distinct from `dcterms:created` and `dcterms:issued` — `issuanceDate` carries the same semantics but lives in the VC namespace so verifiers and standard libraries find it where they expect. Required on every VC. Note: VC 2.0 renames this to `validFrom`; both forms are seen in the wild.

Credential with an issuance date


The date the resource was formally issued or published.

Distinct from `urn:solid:created` (which is when the resource itself was made) — `issued` is when it was made publicly available. For an article drafted in private and published later, the two diverge. ISO 8601 values.

Specification with a publication date


The Actor that issued a VerifiableCredential — the party whose key signed the cryptographic proof and whose authority backs the claim.

Either a string IRI or an Object carrying additional issuer metadata (name, image, URL). The issuer's public key — discoverable from this IRI — is what the credential's `proof` is verified against. Without a resolvable issuer, a credential cannot be verified.

A credential with a structured issuer


The members of an ActivityStreams Collection (or a CollectionPage), in no specified order.

urn:solid:Collection urn:solid:orderedItems urn:solid:totalItems urn:solid:first

Use on a `Collection`/`CollectionPage`; for `OrderedCollection`/`OrderedCollectionPage`, prefer `as:orderedItems`. Either form may inline objects or list `@id` references; servers commonly paginate via `first`/`next` rather than returning all items in one document.

A small Collection with inline items


Inverse-functional in FOAF — a Jabber ID uniquely identifies its owner. The value is a bare JID string like `alice@jabber.example.org`, not a `xmpp:` URI. For other instant-messaging handles, see `vcard:hasInstantMessage`.

Person with a Jabber ID


A keyword or tag describing a DCAT Dataset or Catalog — repeated for multiple keywords.

DCAT prefers repeated singular `dcat:keyword` literals (one per language tag) over schema.org's comma-separated `urn:solid:keywords` string. For controlled-vocabulary topical metadata, prefer `dcat:theme` with SKOS Concepts.

Dataset with keywords


Keywords or tags describing the resource — typically as a comma-separated string or a list.

Schema.org accepts comma-separated text, an array of strings, or `schema:DefinedTerm` references. For ActivityStreams-style hashtag/mention attachments, use `urn:solid:tag`. For broader topical metadata, `urn:solid:subject` (dcterms).

Article tagged with keywords


A person known by the subject — a directed acquaintance relationship.

Asymmetric by default: A knows B does not imply B knows A. Use repeatedly to enumerate the social graph. The FOAF tradition treats this loosely — any acknowledged acquaintance counts.

Alice knows Bob


A topic the agent has expertise in or knowledge of.

Use to declare expertise ("Alice knows about category theory") rather than mere interest (`urn:solid:topic_interest`) or a page about an interest (`urn:solid:interest`). Value can be a string keyword or a SKOS Concept / topic resource. Repeat for multiple areas of expertise.

Person with declared expertise


A language the person speaks, writes, or otherwise communicates in.

Distinct from `urn:solid:language` (which is the language of a *resource*) — `knowsLanguage` is the languages an *agent* communicates in. Value is typically a BCP 47 tag (`"en"`, `"de-CH"`) or a `schema:Language` resource. Repeat for multiple languages.

Person fluent in two languages


A human-readable name for a resource — short, plain text, suitable for UI display.

The most-general human-name predicate in RDF. For people prefer `foaf:name` (mapped to `urn:solid:name`); for SKOS Concepts prefer `skos:prefLabel`; for documents prefer `dcterms:title`. Use `rdfs:label` for everything else (vocabulary terms, classes, properties, opaque resources).

Labelling a class


A web page that gives access to a DCAT Dataset, its Distributions, and additional information.

Distinct from `urn:solid:accessURL` (a Distribution-level access link): `landingPage` is the human-facing introduction page for the whole Dataset, where browsers go for context. Distinct from FOAF `urn:solid:homepage` which is for Agent homepages.

Dataset with landing page


A language of the resource — typically a BCP 47 tag.

Use BCP 47 language tags as values (`"en"`, `"en-US"`, `"de-CH"`). For multilingual resources, repeat. JSON-LD documents can also express language directly on string literals via `@language` — this property is for declaring the resource's overall language(s).

Document in English


The final page of a paginated ActivityStreams Collection — the entry point for clients that want to start at the end (oldest activities, most recent post for chronologically reversed orderings).

urn:solid:Collection urn:solid:first urn:solid:next urn:solid:prev

Optional companion to `as:first`. Useful when the Collection has stable bounds (an outbox with finite history, an archived event log) so clients can deep-link to the end without walking the whole chain. Servers may omit it for unbounded or live-growing Collections.

Paginated outbox with first and last


Older sibling of `foaf:familyName` — kept for compatibility with legacy FOAF data. New profiles should prefer `urn:solid:familyName`. The first/last vs given/family terminology is culture-bound; treat them as equivalent in practice.

Person with first/last names


The latitude of a location, in decimal degrees (WGS-84).

Decimal degrees, positive north of the equator. Pair with `urn:solid:longitude` on a `urn:solid:GeoCoordinates` resource. For a single shorthand `geo:` URI carrying both, use `urn:solid:hasGeo`.

Coordinates with latitude


A legal document giving official permission to do something with the resource.

Value should be the license document's IRI (e.g. an SPDX URL or a Creative Commons license page), not free text. For unstructured rights statements use `urn:solid:rights` instead. SPDX (`https://spdx.org/licenses/MIT`) and Creative Commons URLs are the most interoperable choices.

Document under MIT license


The Collection of Objects an ActivityPub Actor has liked — the Actor's history of `Like` activities, presented as a queryable list.

urn:solid:Actor urn:solid:Like urn:solid:followers urn:solid:following

Third side of the public-facing triad on an AP Actor (`followers`, `following`, `liked`). Often kept private — many servers expose a count via `totalItems` but withhold the items themselves. The reverse direction ("who liked this Object?") lives on the Object as `as:likes`.

An Actor with a liked Collection


The locality (city, town, village) of an Address.

City/town field of a vCard Address. Pair with `urn:solid:region`, `urn:solid:postal-code`, `urn:solid:country-name`. The schema.org equivalent is `schema:addressLocality` on a `urn:solid:PostalAddress`.

Address with locality


The location associated with the subject — typically a Place, address, or geographic coordinates.

Generic location predicate used on Events, Actions, Organizations. The value is typically a `urn:solid:Place`, `urn:solid:PostalAddress`, or `urn:solid:GeoCoordinates`. For a person's home region (intentionally fuzzy), use `urn:solid:basedNear` (FOAF). For structured postal addresses, `urn:solid:hasAddress` (vCard).

Event at a location

Promoted as:location and ical:location to owl:sameAs alongside schema:location — same predicate intent across all three. Note: ical:location values are conventionally strings rather than Place objects; consumers should accept either form.


The login endpoint URL for a Solid OIDC provider.

Advertised by a Solid OIDC provider, points at the URL where users can initiate authentication. Most modern Solid OIDC implementations expose this via OIDC discovery (`/.well-known/openid-configuration`) rather than via this predicate, but the term remains useful for explicit declaration.

OIDC issuer with a login endpoint


The logout endpoint URL for a Solid OIDC provider.

Counterpart to `urn:solid:loginEndpoint`. Advertised by a Solid OIDC provider as the URL where users can sign out. Most modern Solid OIDC implementations expose this via OIDC discovery (`/.well-known/openid-configuration`'s `end_session_endpoint`) rather than via this predicate.

OIDC issuer with login and logout endpoints


The longitude of a location, in decimal degrees (WGS-84).

Decimal degrees, positive east of the prime meridian. Pair with `urn:solid:latitude` on a `urn:solid:GeoCoordinates` resource. For elevation as well, schema.org provides `schema:elevation`.

Coordinates with longitude


A thing the agent made — the inverse of `maker`.

Use on an agent to point at things they made. The inverse `urn:solid:maker` goes the other direction (work → agent). Repeat to list multiple works. For richer attribution semantics, prefer `dcterms:creator` or `prov:wasAttributedTo`.

Person and the document they made


An agent that made the subject — the inverse of `made`.

Use on a document or work to point at the agent that made it. The inverse `foaf:made` goes the other direction (agent → work). For richer creator semantics with role and contribution type, prefer `dcterms:creator` or `prov:wasAttributedTo`.

Document with a maker


Superproperty of all SKOS cross-scheme mapping relations — `exactMatch`, `closeMatch`, `broadMatch`, `narrowMatch`, `relatedMatch`. Asserts that two Concepts in different schemes are related, without specifying how.

urn:solid:Concept urn:solid:exactMatch urn:solid:closeMatch urn:solid:broadMatch urn:solid:narrowMatch urn:solid:semanticRelation

Use the most specific subproperty available — bare `mappingRelation` only when the kind of mapping is genuinely unknown. Distinct from `skos:semanticRelation` (which covers in-scheme relations like `broader`/`narrower`); mappingRelations cross scheme boundaries.

A generic mapping between two concepts


On an OWL Restriction, asserts that the constrained property must have *at most* this many values.

urn:solid:Restriction urn:solid:minCardinality urn:solid:cardinality urn:solid:onProperty

`maxCardinality 1` is how you say "this is functional" inside a class definition without globally declaring the property `owl:FunctionalProperty`. Useful when functionality only holds in the context of a particular class.

Class restricting to at most 5 authors


A personal mailbox — typically a mailto: IRI.

Inverse-functional in FOAF: an mbox value uniquely identifies its owner, so two agents with the same mbox are the same agent. Prefer a `mailto:` IRI as the value, not a bare string. For a plain string email, see `vcard:hasEmail` or `schema:email`.

Person with mailbox


The SHA-1 hash of the agent's mailbox URI — a privacy-preserving inverse-functional identifier.

Inverse-functional like `foaf:mbox` but doesn't reveal the actual email address. Compute the SHA-1 of the lowercased `mailto:` URI (e.g. SHA-1 of `"mailto:alice@example.org"`). Two agents with the same `mbox_sha1sum` are the same agent. Modern profiles often skip both this and `mbox` for privacy.

Person identified by mbox hash


The MIME media type of the object — `image/png`, `text/html`, etc.

ActivityStreams' content-type label — typically attached to `as:content` (to declare the format of HTML vs plain text) or to attachments. Distinct from dcterms `urn:solid:format` only by namespace; carry the same string values (IANA media types).

Note with explicit content media type


An intermediary that mediates access to or use of the resource — typically for educational or curated content.

From the educational-resources tradition: a teacher who selects and uses a textbook is a `mediator`. Used to express that the resource was filtered or curated by an intermediary before reaching its `urn:solid:audience`. Niche outside library/edu contexts.

Course material with a teacher mediator


The material or physical carrier of the resource.

Distinct from `urn:solid:format`: `medium` is the physical/material carrier (paper, vinyl, parchment), `format` is the file format or media type. A book may have format `application/pdf` and medium "paperback". Library and archive metadata uses both fields when both apply.

Book in paperback medium


Use to enumerate the agents that belong to a group. Repeated to list multiple members. The subject should typically be a `foaf:Group`; the value can be any Agent (Person, Organization, Group, software).

Group with two members


An ordered list of members of a SKOS OrderedCollection — preserves sequence in a way that the unordered `skos:member` cannot.

Functional and required on a `skos:OrderedCollection`: exactly one `rdf:List` of Concepts, encoding their canonical order (chapter sequence, taxonomic ranking, presentation order). Use plain `skos:member` for unordered groups.

An OrderedCollection of Concepts


An Organization (or Group) the Agent is a member of — the inverse of `member`.

Inverse of `urn:solid:member` (the FOAF group → member relation, also re-used by ORG). Use on the Agent to enumerate the Organizations they belong to. For role-aware membership with start/end times, attach a `urn:solid:Membership` resource instead.

Person belonging to multiple orgs


The resource that membership triples for a DirectContainer or IndirectContainer are added to.

Used on `urn:solid:DirectContainer` and `urn:solid:IndirectContainer` to identify *where* membership triples land. Pair with `ldp:hasMemberRelation` (the predicate to use) and `ldp:isMemberOfRelation` (the inverse). Not used on plain `BasicContainer`s.

DirectContainer pointing at a membership resource


On an OWL Restriction, asserts that the constrained property must have *at least* this many values.

urn:solid:Restriction urn:solid:cardinality urn:solid:maxCardinality urn:solid:onProperty

Use to express "at least" requirements without an upper bound (`minCardinality 1` = the property is required; `minCardinality 2` = at least two values). Combine with `maxCardinality` for ranges. `minCardinality 0` is meaningless (every property satisfies it).

Class requiring at least one author


An access mode granted by a Web Access Control Authorization — Read, Write, Append, or Control.

urn:solid:Authorization urn:solid:Read urn:solid:Write urn:solid:Append urn:solid:Control

Repeat to grant multiple modes in one Authorization. Standard values are `acl:Read`, `acl:Write`, `acl:Append`, `acl:Control`. `Write` implies `Append`; `Control` is the meta-mode that lets the holder edit the .acl file itself.

Authorization granting Read+Write


The date the resource was last modified.

Updated on every substantive edit; pair with `urn:solid:created` (set once). ISO 8601 (`xsd:dateTime` or `xsd:date`). For RDF Patch / streaming-update systems, the value typically reflects the most recent committed change.

Document with creation and modification dates


On an ActivityStreams Actor, the new identity URI the Actor has migrated to — the forwarding address left behind on the old account.

Forms the second half of the fediverse account-migration handshake. The *old* Actor sets `as:movedTo` pointing at the new identity; the *new* Actor lists the old in `as:alsoKnownAs`. Servers that see both sides confirmed automatically migrate followers; clients render the old account as redirected.

An Actor that has migrated to a new server


The canonical display name. For structured names (given/family), use `foaf:givenName` and `foaf:familyName` directly until urn-solid ships equivalents.

On a Person


Language-tagged variants of an ActivityStreams Object's `name` — keys are BCP 47 language tags, values are the localised name strings.

Provide alongside (or instead of) `as:name` when the Object has translations. Standard fediverse pattern for multilingual content. Clients SHOULD pick the best match for the user's locale; servers MAY mirror one entry into `as:name` as a fallback for non-aware consumers.

A Note with localised names


A SKOS mapping asserting that a Concept in another scheme is narrower than this Concept.

Cross-scheme version of `urn:solid:narrower`. Inverse of `urn:solid:broadMatch`. Use across SKOS schemes when you want to say "the closest narrower concept in *that* vocabulary is this one".

Cross-scheme narrower mapping


A narrower (child) SKOS Concept in a hierarchy — the inverse of `broader`.

Inverse of `urn:solid:broader`. Use to enumerate child concepts in a hierarchy. SKOS treats the relation as transitive only inside one ConceptScheme — for transitive descendants use `skos:narrowerTransitive`. Repeat for multiple children.

Concept with narrower children


The next page in an ActivityStreams CollectionPage chain — the URL the client follows to advance through pagination.

urn:solid:Collection urn:solid:prev urn:solid:first urn:solid:last urn:solid:partOf

Present on every CollectionPage except the last. Clients walk pagination by repeatedly fetching `next` until it's absent — that's the termination signal, not a count check against `totalItems`. Pair with `prev` for bidirectional scrolling.

A CollectionPage linking to the next page


A short informal nickname for the subject — typically a chat handle or screen name.

For informal handles (IRC, IM, screen names) rather than legal or display names. A subject may have many nicknames across different contexts. Use `urn:solid:name` for the canonical display name.

Person with a chat nick


A symbolic identifier for a SKOS Concept within a particular notation system (Dewey numbers, ISBN-style codes, taxonomy IDs).

Unlike `skos:prefLabel` (a human-readable string in a natural language), `skos:notation` is a typed literal whose datatype identifies the notation system — e.g. a Dewey Decimal code typed as `<http://example.org/dewey>` is distinct from a UDC code with the same digits. A Concept may carry multiple notations from different schemes.

Concept with a notation


The OpenID Connect issuer that this WebID trusts to authenticate it.

The Solid OIDC trust anchor: the value is the issuer URL of the OpenID Provider whose tokens this WebID will accept. A WebID may list multiple `oidcIssuer` values for redundancy. Distinct from the older FOAF `urn:solid:openid` (a document-based pre-OIDC scheme).

WebID with a Solid OIDC issuer


On an OWL Restriction, the property being constrained.

Required on every `owl:Restriction`. Pair with the actual constraint predicate — `owl:someValuesFrom`, `owl:allValuesFrom`, `owl:hasValue`, `owl:cardinality`, `owl:minCardinality`, `owl:maxCardinality` — to express "on property X, the constraint is Y".

A restriction on the knows property


On an ActivityStreams Question, the exclusive set of answer choices — voters pick exactly one.

Use exactly one of `oneOf` (single-choice poll) or `anyOf` (multiple-select poll) on a Question — never both. Each option is typically a `Note` whose `name` carries the displayed text; `replies.totalItems` is then the vote count for that option.

Single-choice Question


An OpenID identifier for the Agent — a document used to verify the Agent's identity.

Inverse-functional in FOAF — an OpenID document uniquely identifies its Agent. Predates Solid OIDC; for modern Solid pods use `solid:oidcIssuer` instead, which points at the OpenID Connect issuer URL.

Person with an OpenID document


The ordered members of an ActivityStreams OrderedCollection or OrderedCollectionPage — sequence is significant.

urn:solid:Collection urn:solid:items urn:solid:totalItems urn:solid:first

Use on `OrderedCollection`/`OrderedCollectionPage`; for unordered collections use `as:items`. The JSON array order is the canonical order — for a chronologically sorted outbox, that's typically newest-first. Servers paginate ordered collections via `first`/`next` just like unordered ones.

An OrderedCollectionPage with three items


The name of the organization the person is affiliated with — typically the employer.

vCard's quick organization-name string — useful when you only have the company name as text. For a structured affiliation, prefer `urn:solid:worksFor` pointing at a `urn:solid:Organization` resource.

vCard with an org name


The Actor responsible for an iCalendar Vevent or Vtodo — the owner who scheduled it and who attendees reply to.

Functional — exactly one organizer per event. Distinct from `attendee` (the people invited). RSVPs and changes route back to this address. Typically a `mailto:` URI in classic iCal, increasingly a WebID or DID in pod-native deployments.

Event with an organizer


Where an ActivityStreams Activity comes *from* — the source side of a movement, transfer, or invitation, complementing `as:target` (the destination).

urn:solid:Activity urn:solid:target urn:solid:Move urn:solid:Travel

Used most often with `Move`, `Travel`, `Add`, and `Remove` — together with `target` it forms the source-and-destination pair. `Move` an item from `origin` to `target`; `Travel` from `origin` to `target`. Distinct from `as:actor` (who did it) and `as:object` (what was acted on).

Moving a Note between collections


The OrderedCollection of Activities an ActivityPub Actor has published — POSTing to it is how the Actor sends new Activities to the network.

urn:solid:Actor urn:solid:inbox urn:solid:followers urn:solid:following

Two roles in ActivityPub: GET reads the Actor's published-Activity history (paginated); POST is the client-to-server submission endpoint — the Actor's own client posts here, and the server fans the Activity out to recipient inboxes. Mirror of `as:inbox` (which is the receive side).

An Actor with an outbox endpoint


An agent that owns the resource — typically used to declare pod ownership.

Solid-specific ownership predicate — declares the WebID(s) that own a pod or resource. Pod operators can read this to determine who has full control. Distinct from `dcterms:rightsHolder` (broader copyright/IP ownership) and `urn:solid:creator` (who made it).

Pod root with declared owner


A pod or resource the agent owns — the inverse of `owner`.

Inverse of `urn:solid:owner` — declared on a WebID to enumerate the pods/resources the user owns. Useful for cross-pod ownership claims and discovery. Often co-asserted with `urn:solid:storage`.

WebID claiming pod ownership


A document about the subject — any page that describes or discusses it.

More general than `urn:solid:homepage` — any page about the subject, not just the canonical one. Repeat to list multiple. For the inverse "this page is about", see `foaf:topic` (page → subject).

Person with a page about them


Inverse of `urn:solid:children`. Repeat for multiple parents (biological, adoptive, step-). Sensitive personal data; consider access control. Distinct from `dcterms:isPartOf`/`hasPart` which encode whole-part composition rather than family relations.

Person with a parent


Identifies the parent Collection that an ActivityStreams CollectionPage is a slice of — lets the client jump from a page back to the whole.

Required on every CollectionPage so consumers can recover context — "this page belongs to which Collection?" Without `partOf`, a client that lands on a page mid-pagination has no way to know what whole it's a slice of, which breaks deep-linking and resume-from-here flows.

A CollectionPage referencing its parent Collection


A project the person is no longer active on.

Use to retain history when a person's involvement ends. Repeat to list multiple. Move from `urn:solid:currentProject` here when the person stops being involved. The value can be any resource — typically a `urn:solid:Project` or a Document describing it.

Person with a past project


A phone number for the agent — typically a `tel:` IRI.

FOAF's lightweight phone predicate. The value is conventionally a `tel:` URI, mirroring `foaf:mbox`'s `mailto:` style. For typed numbers (work/home/cell) prefer `urn:solid:hasTelephone` (vCard); for plain string values prefer `urn:solid:telephone` (schema.org).

Person with a phone


Links a Post to the Organization in which it sits.

Identifies which Organization owns the position. Use alongside `org:heldBy` (current holder) and an optional `org:role` (the abstract role the Post embodies) to fully describe a seat in an org chart.

A Post and the Organization it sits in


The postal code (ZIP code) of an Address.

vCard's postal-code field. Stored as a string because postal codes are not always numeric (UK "SW1A 1AA", Canada "K1A 0B1"). Schema.org equivalent is `schema:postalCode`.

Address with postal code


The preferred lexical label for a SKOS Concept — its canonical name in a given language.

Exactly one `prefLabel` per language tag per Concept (SKOS integrity rule). Use language-tagged literals for multilingual vocabularies. Synonyms go under `urn:solid:altLabel`; non-display strings (typos, misspellings used for search) go under `urn:solid:hiddenLabel`.

Multilingual concept label


A document containing the subject's private preferences.

Conventionally a private document linked from the WebID profile, holding application preferences and other personal settings. Should be access-controlled (only the user can read/write). Apps discover it via the WebID and follow links from it (e.g. to the private TypeIndex).

WebID with a preferences file


An ActivityPub Actor's preferred short username — the local part used in `@user@host` mention syntax.

The handle, not the display name: `as:preferredUsername` is `alice` (used in webfinger and `@alice@host` mentions); `as:name` is "Alice Smith" (the human-readable display string). Lowercase, alphanumeric, no spaces — meant for routing and addressing, not presentation.

An Actor with a handle and display name


The previous page in an ActivityStreams CollectionPage chain — the URL the client follows to scroll back through pagination.

urn:solid:Collection urn:solid:next urn:solid:first urn:solid:partOf

Mirror of `as:next`. Optional but recommended — without `prev`, a client that lands on a deep page can only walk forward, never back. Servers commonly omit on the first page (where it would have no value).

A middle page exposing both next and prev


An object that provides a preview of the subject — typically a thumbnail image or a snippet.

ActivityStreams' general-purpose preview slot — useful for link unfurling, video posters, document covers. Distinct from `urn:solid:thumbnail` (specifically a smaller image of an Image) and `urn:solid:icon` (small avatar). The value can be any AS Object with a `urn:solid:url`.

Video with a preview poster


The primary topic of a document — the thing the document is principally about.

A document has at most one primary topic. WebID profile documents canonically have their subject Person as `foaf:primaryTopic`. The inverse is `foaf:isPrimaryTopicOf`. For documents about multiple things at equal weight, use `foaf:topic` (no primacy) instead.

WebID profile document


The private TypeIndex for a WebID — an access-controlled registry of where personal data of each type lives.

Linked from a WebID, points at the user's access-controlled TypeIndex. Used by trusted apps (after auth) to discover where personal data is stored. Pair with `urn:solid:publicTypeIndex` for the world-readable counterpart.

WebID pointing at its private TypeIndex


The subject (Person) that a profile document is about.

Solid-specific name for the relation FOAF expresses as `foaf:primaryTopic`. Use on a profile document to point at the Person it describes. Most existing data uses `foaf:primaryTopic`; this is the modern Solid-namespaced equivalent.

Profile document with subject


A cryptographic proof attached to a VerifiableCredential or VerifiablePresentation — what verifiers check to confirm the document hasn't been tampered with and was signed by the claimed party.

urn:solid:VerifiableCredential urn:solid:VerifiablePresentation urn:solid:verificationMethod urn:solid:proofPurpose

An Object carrying the proof type (e.g. `Ed25519Signature2020`, `DataIntegrityProof`), the signature value, and metadata: when, by which key (`verificationMethod`), and for what purpose (`proofPurpose`). Defined in the W3C Security Vocabulary; used unchanged by VC, DID Document signing, and ActivityPub HTTP Signatures.

A credential with a proof block


A statement of any changes in ownership and custody of the resource since its creation — its provenance trail.

dcterms's narrative provenance pointer — for human-readable custody/transformation history. For machine-actionable provenance graphs, use the PROV vocabulary (`urn:solid:wasDerivedFrom`, `urn:solid:wasGeneratedBy`, `urn:solid:Bundle`). Both can coexist: dcterms:provenance gives the headline, PROV gives the audit trail.

Document with a provenance statement


The public TypeIndex for a WebID — a world-readable registry of where public data of each type lives.

Linked from a WebID, points at the user's publicly-readable TypeIndex. Distinct from `urn:solid:privateTypeIndex` (access-controlled, only readable by the user and their authorized apps). Public type registrations are typically for data the user intends to share (public contact info, published content).

WebID pointing at its public TypeIndex


A document listing the publications of the person.

Points at a publications-list document (CV-style, ORCID page, etc.) — not at the publications themselves. For the works directly, use `urn:solid:made` (FOAF) or `dcterms:creator` on each work.

Person pointing at their publication list


The date and time the object was published — when it went public.

ActivityStreams' publication timestamp — the wall-clock time a post went out. Distinct from `urn:solid:created` (when the resource was constructed) and `urn:solid:issued` (dcterms' formal publication date). ISO 8601 `xsd:dateTime`.

Note with publication timestamp


An entity responsible for making the resource available.

The publisher distributes or hosts the resource — distinct from the creator (who made it). For self-published content the same agent may fill both roles, but model them as separate triples to keep the semantics clear.

Document with creator and publisher


A qualified PROV Association linked to the activity — adds role and plan to a `wasAssociatedWith` relation.

urn:solid:Association urn:solid:wasAssociatedWith urn:solid:hadRole urn:solid:hadPlan

Use to attach a `urn:solid:Association` that names which Plan an Agent followed and what role they took during an Activity. Pattern: keep both the unqualified `wasAssociatedWith` triple AND the qualified form.

Build with qualified association


A qualified PROV Attribution linked to the entity — adds role and timing to a `wasAttributedTo` relation.

Use to attach a `urn:solid:Attribution` resource that qualifies the basic `urn:solid:wasAttributedTo` link with role (author, editor, photographer, contributor). Pattern: keep both the unqualified `wasAttributedTo` triple AND the qualified form for SPARQL convenience.

Qualified attribution for a photo


A qualified PROV Derivation linked to the entity — adds role, activity, and other context to a `wasDerivedFrom` relation.

Use to attach a `urn:solid:Derivation` resource that qualifies the basic `urn:solid:wasDerivedFrom` link with role, plan, or activity. Pattern: when you need richer derivation metadata, keep both the unqualified `wasDerivedFrom` triple (for SPARQL convenience) AND the qualified form.

Qualified derivation for a translation


Links an Entity to the `prov:Generation` instance describing the activity, time, and role in which the Entity was created.

urn:solid:Entity urn:solid:wasGeneratedBy urn:solid:qualifiedUsage urn:solid:hadGeneration

The qualified counterpart to `prov:wasGeneratedBy`. Use when a plain `wasGeneratedBy` triple isn't enough — to record the time of generation, the role the Entity played in the activity, or to attach further provenance to the generation event itself.

Entity with a qualified Generation


Links an Entity to a `prov:Invalidation` instance describing the activity, time, and circumstances in which the Entity ceased to exist.

urn:solid:Entity urn:solid:invalidated urn:solid:qualifiedGeneration urn:solid:qualifiedUsage

The qualified counterpart to `prov:wasInvalidatedBy`. Use when a plain triple is insufficient — to record the time of invalidation, the role the Entity played, or to attach further provenance to the invalidation event itself (deletion log, retention policy reference).

Entity with a qualified Invalidation


Links an Activity to a `prov:Usage` instance that adds detail (which entity, when, in what role) to a plain `prov:used` link.

urn:solid:Activity urn:solid:used urn:solid:qualifiedGeneration urn:solid:qualifiedDerivation

Use when the bare `prov:used` triple isn't enough — e.g. an Activity used the same Entity twice in different roles, or you need to record the time of use, or attach a `prov:Role` reified link. The Usage instance carries the extra context; the Activity points at it via `qualifiedUsage`.

Activity with a qualified Usage


The radius around an ActivityStreams Place's centre point that the Place covers — a circular area, in metres unless `as:units` says otherwise.

urn:solid:Place urn:solid:latitude urn:solid:longitude urn:solid:accuracy urn:solid:units

Describes *area* (the size of the Place); `as:accuracy` describes *uncertainty* (how confident we are in the centre). A neighbourhood might have a 2000-metre radius with 90% accuracy; a GPS-pinned café might have a 50-metre radius with 95% accuracy.

A neighbourhood Place with radius


Declares the type of values an RDF property is meant to take — its object type.

Object-side constraint. `foaf:knows` has range `foaf:Person`. May also point at an XSD datatype (`xsd:string`, `xsd:dateTime`) for literal-valued properties. Like `domain`, multiple range declarations mean intersection — the value must be an instance of all listed types.

Property declaring its value type


The web resource a Bookmark points at — the URL being bookmarked.

The bookmarked target — a NamedNode pointing at the URL the Bookmark refers to. Idiomatically a single value (one Bookmark recalls one resource); use multiple Bookmarks rather than overloading one with multiple targets.

Bookmark recalling a URL


A related resource that is referenced, cited, or otherwise pointed to by the described resource.

Use to record outbound citations or references. The inverse is `dcterms:isReferencedBy`. For richer bibliographic citations with structured metadata, prefer `dcterms:bibliographicCitation` (string) or attach a separate `dcterms:BibliographicResource`.

Article citing a source


The region (state, province, prefecture) of an Address.

vCard's sub-national administrative region — US states, UK counties, Indian states, Japanese prefectures. Often a 2-letter code ("CA", "NY") for US data. Schema.org equivalent is `schema:addressRegion`.

Address with region


The link relation type of an ActivityStreams Link — semantic role of the connection (canonical, alternate, prev, next, …).

Values are IANA-registered link relation types from <https://www.iana.org/assignments/link-relations/> (`canonical`, `alternate`, `enclosure`, `self`, `next`, etc.) — same vocabulary HTML and HTTP `Link:` headers use. Repeat to express multiple relations on one Link.

A Link declaring its relation


A SKOS Concept that is associatively (non-hierarchically) related to the subject Concept.

Use for non-hierarchical conceptual associations — "category-theory related-to functional-programming". Symmetric in SKOS. Distinct from `urn:solid:relation` (dcterms generic relation between resources) and from `broader`/`narrower` (hierarchical).

Related concepts


Asserts an associative (non-hierarchical) link between two SKOS Concepts in different schemes — the cross-scheme analogue of `skos:related`.

urn:solid:Concept urn:solid:related urn:solid:exactMatch urn:solid:closeMatch urn:solid:mappingRelation

Use when two Concepts are *meaningfully associated* but neither narrower nor broader than the other — e.g. "Birds" in one taxonomy associated with "Aviation" in another. Distinct from `closeMatch` (similar meaning) and `exactMatch` (interchangeable); a `relatedMatch` is a see-also, not a substitute.

Cross-scheme associative mapping


A related resource — generic relation when more specific predicates don't apply.

The most generic dcterms relation predicate — fallback when more specific dcterms relations (`hasPart`, `references`, `source`, `replaces`, `isVersionOf`) don't fit. Avoid when possible; the specific terms carry more semantic weight. For a similarly-loose RDF predicate, see `rdfs:seeAlso`.

Resource related to another


A related resource that the described resource supplants, displaces, or supersedes.

Use to record that this resource is the new official version of an older one (a v2 spec replacing v1, a new policy replacing the prior one). The inverse is `dcterms:isReplacedBy`. For term-level supersession inside the urn-solid registry itself, the schema's `supersededBy` field on a term file is the right place.

v2 spec replacing v1


A Collection of objects that are responses to the subject — the reverse of `inReplyTo`.

The inverse of `urn:solid:inReplyTo`. Lives on the parent object and points at a `urn:solid:Collection` (or `OrderedCollection`) of replies. ActivityPub servers compute this by aggregating inbound `inReplyTo` from across the network.

Note with a replies collection


A related resource that is required by the described resource to support its function or coherence.

Use for hard dependencies — software that needs another library, a document that requires its referenced datasets, an API spec requiring an auth scheme. Repeat for multiple dependencies. The inverse is `dcterms:isRequiredBy`.

Document requiring another resource


Describes the result produced by an ActivityStreams Activity — for example, the booking returned by a Reservation.

urn:solid:Activity urn:solid:object urn:solid:target urn:solid:instrument

`as:result` describes what the Activity *produced*; `as:object` describes what it *acted on*. A Like activity has the liked Note as its `object` and may have nothing meaningful as its `result`; a booking activity has the requested room as `object` and the confirmed booking as `result`.

Activity with a result object


A review of the subject — typically a Review instance with a rating and a body of text.

Property form paired with the `urn:solid:Review` class. Maps to `schema:review` — the standard property used to attach reviews to Products, CreativeWorks, Places, etc., consumed by search engines and aggregators. For a single rolled-up score, use `schema:aggregateRating` instead.

Product with a review

Initial term — property form completing the Review/review case-pair.


Information about rights held in and over the resource — copyright, IP, access restrictions.

Free-form rights statement (e.g. "Copyright 2026 Acme Corp. All rights reserved.") or a link to a `dcterms:RightsStatement` resource. For machine-actionable permissions, use `urn:solid:license` with an SPDX or Creative Commons URL.

Document with a rights statement

Copyright 2026 Alice Liddell. All rights reserved.


An agent owning or managing rights over the resource — the copyright holder, IP owner, or licensing controller.

urn:solid:rights urn:solid:license urn:solid:creator https://schema.org/copyrightHolder

Distinct from `urn:solid:creator` (who made it) and `urn:solid:owner` (Solid pod ownership): `rightsHolder` is specifically about IP/copyright control. A work-for-hire has a creator (the worker) and a separate rightsHolder (the employer).

Document with a rights holder


The job role or function the person performs within an organization.

vCard's role string — typically a job title or function ("Senior Engineer", "Treasurer"). For schema.org-flavored data, prefer `schema:jobTitle`. For PROV-grade role-in-Activity attribution, use `prov:hadRole`.

vCard with a job role


An iCalendar recurrence rule — declares the pattern by which a Vevent or Vtodo repeats (daily, weekly, every other Tuesday, …).

Encodes RFC 5545's RRULE syntax — `FREQ=WEEKLY;BYDAY=TU;UNTIL=20261231T000000Z`. The base event carries `dtstart` plus `rrule`; each instance is computed at read time, not stored. Recurrence is the single most-bug-prone area of calendar interop — many libraries diverge on edge cases (DST transitions, BYDAY in monthly rules, COUNT vs UNTIL).

A weekly meeting on Tuesdays


An external reference URL that unambiguously identifies the subject — typically a profile or canonical page on another site.

Distinct from OWL's `owl:sameAs`: schema.org's `sameAs` is a soft "this is also at" reference (Wikipedia page, social profile, registry entry), without the strong identity-equivalence semantics that OWL reasoners apply. Use schema's form for everyday cross-site identity hints; use OWL's form only when you mean true identity equivalence in a reasoning sense.

Person with external profile links


A homepage of a school (or other educational institution) the person attended.

FOAF's lightweight "I went to that school" pointer — the value is the school's homepage URL, not a structured Organization resource. For richer educational-history data, prefer `urn:solid:alumniOf` pointing at a `schema:EducationalOrganization`. Repeat for multiple schools.

Person with a school homepage


A SKOS note clarifying the intended scope or usage of a Concept — "use this for X but not Y".

Distinct from `urn:solid:definition` (the meaning itself) — `scopeNote` is editorial guidance for catalogers and users about when to apply the Concept. Mirrors the disambiguation-style notes on urn-solid term files themselves.

Concept with usage guidance

Use for the mathematical theory; for the database concept of "category" use the `taxonomy/category` concept instead.


Points at a related resource that may carry additional information about the subject — a generic "more about this here" link.

Weakest of the cross-reference predicates: makes no claim about authority or canonicality, just relevance. Use when you want to surface a related resource without asserting it's a definition or an equivalence. `isDefinedBy` and `owl:sameAs` are stronger statements when those apply.

A resource pointing at related material


The SKOS superproperty for any conceptual relation between Concepts — `broader`, `narrower`, `related`.

Rarely asserted directly — superproperty of `skos:broader`, `skos:narrower`, `skos:related`, and their transitive variants. Useful when reasoning generically over any conceptual link, or when you have a relation you can't classify more specifically.

Generic conceptual link


A Dataset that a DCAT DataService makes available.

Repeat once per Dataset the service exposes — a single SPARQL endpoint or API may publish many. The inverse direction (`dcat:Dataset` → service) is not standard; lookups go through the service.

Service serving two datasets


On a DID Document service entry, the URL where the service is reachable.

A DID Document carries `service` entries (messaging endpoints, profile servers, credential exchange endpoints); each one carries one or more `serviceEndpoint` URLs. Distinct from DCAT's `dcat:endpointURL` (data-service flavour) — same general idea, different domain vocabulary.

A messaging endpoint on a DID


The SHA-1 cryptographic hash of the resource's content.

Use to record content integrity for files, datasets, or releases. SHA-1 is cryptographically weakened — for new data, prefer SHA-256 (`schema:sha256` or a custom predicate). Value is the lowercase hex digest of the bytes.

Document with content hash


An ActivityPub Actor-server endpoint that accepts deliveries for any local recipient — used to deduplicate fan-out when one Activity targets many followers on the same server.

Lives inside an Actor's `as:endpoints` object. Federation pattern: when delivering an Activity addressed to many followers, a sender SHOULD POST once to each receiving server's `sharedInbox` rather than once per follower's per-Actor `inbox` — saves bandwidth and quadratic delivery cost on large fediverse instances.

An Actor advertising a sharedInbox


A Collection of `Announce` activities (shares / boosts / reposts) directed at an Object — discoverable from the Object itself.

urn:solid:Object urn:solid:Announce urn:solid:likes urn:solid:replies

The standard ActivityPub way to expose "who reshared this?" without mailing every share to every reader. Servers append each `Announce` of an Object to its `shares` Collection; clients dereference the Collection to count and display shares. Mirrors `as:likes` for like activities.

A Note exposing its shares Collection


A sibling of the person — sharing at least one parent.

Symmetric — if A is sibling of B, B is sibling of A. Use repeatedly for multiple siblings. Sensitive personal data; consider access control before publishing.

Person with a sibling


On an OWL Restriction, asserts that at least one value of the constrained property must be an instance of a given class — an existential quantifier.

Reads as "there is at least one value on this property in this class." Use to define classes like "Articles that have at least one Author who is a Person." Pairs with `allValuesFrom` (universal — every value is in the class).

A class requiring at least one Person author


A related resource from which the described resource is derived.

Use to record the upstream origin of derived works (translations, adaptations, summaries, scraped data). For PROV-grade derivation chains with role and timing, prefer `prov:wasDerivedFrom`. Repeat to list multiple sources.

Translation pointing at its source


The spatial coverage of the resource — what places it is about or applies to.

Distinct from `urn:solid:location` (where the resource itself *is*) — `spatial` is the geographic *subject* of the resource (a study about Wales, a dataset covering the Pacific). Value is typically a `dcterms:Location` or a `urn:solid:Place`. Pair with `urn:solid:temporal` for the time dimension.

Dataset with spatial coverage


Asserts that one PROV Entity is a more constrained version of another — same identity, narrower aspect (e.g. a single revision of a document is a specialization of the document as a whole).

urn:solid:Entity urn:solid:alternateOf urn:solid:wasDerivedFrom urn:solid:wasRevisionOf

Specialization preserves identity — the specialized Entity *is* the general one viewed at finer granularity (e.g. "the CSS file as of commit abc" specializes "the CSS file"). Contrast with `prov:wasDerivedFrom`, which links *different* entities causally, and `prov:alternateOf`, which links two specializations of a common general entity.

A document version as a specialization


The person to whom the subject is married.

Symmetric in practice — if A is the spouse of B, B is the spouse of A. Sensitive personal data; consider access control before publishing. For other family relations, schema.org provides `parent`, `children`, `sibling`, `relatedTo`.

Person with a spouse


ISO 8601 datetime marking when an Event, Activity, or other time-bounded object begins. Pair with `urn:solid:endTime` (or `urn:solid:duration`). For PROV-grade activity timing, prefer `prov:startedAtTime`.

Event with start and end times


PROV-grade activity-start timestamp. Use on a `prov:Activity` to record when execution began. ActivityStreams `urn:solid:startTime` is the equivalent for AS Events; pick by domain — PROV for processes, AS for calendar events.

Build start time


A free-form status string for the agent — e.g. "online", "away", or a custom message.

FOAF's lightweight presence/status field — IM-style "away", "busy", or a free-form message ("writing the registry"). For ActivityPub-style profile bios, `as:summary` on the actor is more common today.

Person with a current status


The root of a personal data store (Solid pod) for the subject.

From the PIM space vocabulary. The value is the root URL of the user's pod (a Container). A WebID may list multiple `pim:storage` values when the user has multiple pods. Apps use this to discover where to read/write data on behalf of the user.

WebID with a pod storage root