A named role, such as "writer", that is assigned to a user, group or some other identifying principal within part of the repository. Roles may be used by the policy enforcement point (PEP) to authorize actions taken in the repository.
A binary in a Fedora repository is a nonRdfSource resource. In other contexts, binaries would sometimes be described as bit-streams or files. Binaries are always accompanied by a nonRdfSourceDescription.
A computed fingerprint for binary content, used to ensure a complete transfer or the fixity of stored information. Fedora supports the SHA-1 checksum algorithm for safely uploading content.
The resources which are immediate children of a given container. Properties are not counted as children.
Container (formerly known as: Object)
A container is a resource that represents intellectual entities and can also be used to aggregate other resources in a Fedora repository. Containers may container other containers or binaries and their nonRdfSourceDescriptions.
Within the Fedora 4 model a Datastream comprises a binary and a NonRdfSourceDescription. Treat both together as a datastream; they only ever occur in a pair.
An approach available in Fedora 3 that allowed for binding a service from outside the repository to a content model or type for content. Note: disseminators as such do not exist in Fedora 4 itself, but the API-X effort will provide similar functionality by extending the core with specifications and optional machinery.
Federation (aka Projection)
Fixity is a measurement or characterization of stored information at a given time. An identity between two values of fixity can be interpreted as some measurement of the integrity of the stored information over time. Fedora performs fixity checks on demand by comparing a stored checksum with one that is newly computed.
Creating, modifying or deleting resources in the repository generates events. The indexer monitors and processes these events; by ingesting relevant RDF to an external triplestore, for example.
Linked Data Platform (LDP)
The W3C Linked Data Platform (LDP) specification describes a set of best practices and simple approach for a read-write Linked Data architecture, based on HTTP access to web resources that describe their state using the RDF data model. Fedora 4 implements the LDP specification for create, read, update and delete (CRUD), allowing HTTP, REST, and linked data clients to make requests to Fedora 4.
Managed External Content
Refers to content that sits outside the Fedora-configured datastore, but is managed by Fedora through a projection. Managed external content can be accessible via the Fedora API as well as have Fedora-managed audits.
A namespace is a container for a set of identifiers (also known as symbols, names). In Fedora 4, resource properties may belong to any namespace providing semantic assertions that support interoperable metadata. Namespaces are restricted to being an empty string or to a URI as defined in section 3 of RFC3986. An example of a namespace would be "http://purl.org/dc/elements/1.1/".
NonRdfSourceDescription (formerly the properties of a datastream)
A nonRdfSourceDescription is a resource that describes a binary resource within the Fedora repository. A nonRdfSourceDescription is always accompanied by a binary, and vice versa.
Policy Enforcement Point (aka PEP)
This is a pluggable component in the Fedora framework that is responsible for authorizing all actions take on resources.
A predicate expresses a relationship between the subject and the object of a triple.
Typically a short string representation of an associated namespace. For example the prefix "dc" could be used to represent the namespace "http://purl.org/dc/elements/1.1/". If we wanted to access an element (e.g. "contributor") within that namespace we could do it with the prefix "dc:contributor" or in the full form "http://purl.org/dc/elements/1.1/contributor".
Prefixes are limited to the following grammar:
Projection (aka: Federation)
The process by which a repository may present resources through the API that are actually stored in a different system, such as a file system or database.
Properties are name/value pairs that belong to resources. The name of a property can be any term from a namespaced vocabulary. When RDF is generated in response to a request for a resource that contains properties, the RDF will contain triples for each property where the subject of the triple is the resource itself, the predicate of the triple is the property name, and the object of the triple is the value of the property. Property values can be of any valid rdf:type.
Containers are defined by one or more rdf:types that describe the nature of the container. Similarly, every property will be an instance of a single rdf:type. The official definition can be found here.
Resources are the primary organizational structure in the repository. A resource is any web-addressable entity, such as a container, a nonRdfSourceDescription, or a binary. Every resource has a name and a unique identifier, and can also be identified by a path. They are comprised of zero or more properties / child resources.
A tombstone is a repository resource indicating that a container, binary, or nonRdfSourceDescription used to exist at a given URL. A tombstone is created when a resource is deleted or moved.
A transaction represents a series of changes to the repository that must execute successfully and completely or not at all. Transactions should be used to ensure consistency. Each transaction succeeds or fails as a complete unit; it cannot remain in an intermediate state.
A triple is a fundamental building block of RDF. It consists of: a subject, predicate, and an object. In this way, a triple can describe a relationship (via the predicate) of the subject to the object. The official definition can be found here.
Uniform resource identifier (URI)
Universally Unique Identifier (UUID)
A "practically" unique identifier that is used to identify a resource.
A snapshot of a resource that is saved in version history for later access.