Server managed triples (SMTs) are the portion of a Resource's triples which are generated and/or constrained by the server, and may in some cases be used by the implementation for inspection and identification of said Resources. They are related to LDP-server-managed triples. Clients may not modify these properties directly via PUT/PATCH/POST requests. Instead, they are often generated as a side effect of other actions such as creating a container or a binary, or adding a child resource.

Clients may request to omit server managed triples from RDF responses from the server using the "Prefer: return=representation; omit=http://fedora.info/definitions/v4/repository#ServerManaged" header as described in
the RESTful API documentation

When committing changes to the server via PUT, clients may choose not to provide the server managed triples for the resource by including the "handling=lenient; received="minimal" header as described in the RESTful API PUT documentation, which is based on https://tools.ietf.org/html/rfc7240#section-4.4

Server Managed Predicates

The following predicates are considered to be server managed (see the list of namespace prefixes later in the document):

Additionally, clients may not specify a ldp:hasMemberRelation relationship on a Direct or Indirect Container with a server managed predicate as the object, as this would cause the inappropriate creation of server managed triples. Similarly, relationships generated by Direct/Indirect containers cannot be deleted by clients.

Server Managed Types

In addition to predicates, the following URIs are considered server managed when provided as the object of an rdf:type property:

Relaxable Properties

A subset of SMTs can be modified by clients, but only when the server is put into "relaxed" mode. This concept is described in more detail in the article How to allow user-updates to certain server managed triples. The following properties fall into this category:

Server Generated Properties

Some properties are generated by the server, but not managed thereafter. As such, they may be directly overridden by the clients after creation, including:

Namespaces Referenced in this Document

PrefixNamespace
fedorahttp://fedora.info/definitions/v4/repository#
premishttp://www.loc.gov/premis/rdf/v1#
ldphttp://www.w3.org/ns/ldp#
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
memento

 http://mementoweb.org/ns#

ianahttp://www.iana.org/assignments/relation/