The Fedora 4 Object Model
If you're interested in the differences between the object model of Fedora 3 and earlier and the object model of Fedora 4, start here.
(Cribbed heavily from the JCR Repository Model documentation)
This document describes the objects and structures that compose a Fedora repository.
A Fedora 4 repository is composed of one or more workspaces, each consisting consists of a directed acyclic graph of nodes resources where edges represent a parent-child relation.
For those without a computer science background, in repository terms:
- A node resource is an object or datastream.
- An edge is a relationship (in this case, a parent-child relationship) that links two nodes resources. Edges are represented as RDF properties in a Fedora object.
- A graph is a set of nodes resources connected by edges. The entire set of objects in the workspace and their relationships to each other form a graph.
- A directed graph is a graph whose edges have direction associated with them: that is, the relations that link the nodes resources move in a given direction from one node resource to the next. An example of an edge with a direction is isAChildOf. The relationship expresses a direction from the child to the parent. The relationship isParentOf can also link the same two nodesresources, but in the opposite direction.
- A directed acyclic graph is a graph in which edges never form loops (i.e., cycles) of nodesresources. That is, if you start at node resource A, then follow a set of identical relations from that node resource to other nodes resources in a chain, you will never end up back at node resource A.
- A hierarchical tree, such as the one modeled in the Fedora repository workspace by the relationships provided by the JCR underpinnings of Fedora, is a classic example of a directed acyclic graph of nodesresources. In this sense, no Fedora object can ever be its own grandpa. Of course, the additional relationships that you, the user, distribute amongst your objects are entirely up to you. You can make them as simple or complex as you like.
Each persistent workspace is identified by a unique name within the repository. There is a default workspace, which has an empty workspace identifier.
Each workspace The repository contains at least one item, the root noderesource. The root node resource is the only item in the workspace without a parent node; all other items have at least one parent.
Nodes Resources can have zero or more child nodesresources. Nodes Resources can have zero or more properties. Properties can hold one or more values. Fedora doesn't currently support blank nodes.
The location of an item in the workspace graph can be described by the path from the root node resource to that item. The path consists of the name of each interceding node resource in order from root to target item, much like a file system path.
The name of a an item consists of the namespace prefix and a local name component. The namespace prefix must be registered before use.
The local name of a node resource is limited to the range of valid XML characters (http://www.w3.org/TR/xml/#NT-Char)
...
In addition to a path, every node resource also has an identifier. The identifier is independent of the path and provides an identity to the node resource that is stable across moves within the workspacerepository.
Some nodes resources may possess a "jcr:data" property consisting of a binary binary" payload with a length and digest. These nodes resources are normally leaf nodes leaves in the tree (meaning they have no child nodes resources of their own), and they are almost always named "jcr:content". They are the best match in Fedora 4 to the Fedora 3 concept of "datastream".
The binary content of the jcr:data property is (by default) de-duplicated across the repository. If you store the same binary stream in five jcr:data propertiesbinary resources, it will only be persisted once, unless you expressly configure otherwise.
...
Fedora internal properties exist in the following namespacesnamespace:
http://fedora.info/definitions/v4/repository