Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Generally speaking, within Fedora, opaque identifiers that hold no semantics should be favored over semantically meaningful identifiers. There are justifiable reasons for having structural hierarchies of resources in your repository, but having meaningful identifiers is likely not one of them. 

 

REST Examples


Properties

Resources (both containers and binaries) can be adorned with properties. A property is effectively a name/value pair. All resources have a set of system properties, that are managed by Fedora and not editable by users. 

 

REST Examples

Relationships

Fedora also allows a resource to effectively have an unlimited number of user-defined properties. The "name" of the property in the name/value pair can be any term coming from any namespaced vocabulary (except, of course, from the Fedora system property vocabulary). The "value" in the name/value pair can be a URI or a literal. 

The result of these name/value pairs on resources is that when a request is made on a resource (i.e. HTTP /GET) the response that is returned is RDF with a set of RDF triples (subject - predicate - object) that further describe that resource. The "subject" of those triples is the resource being requested. The "predicate" of those triples is the namespaced term created as the "name" in the property's name/value pair. The "object" of those triples is the URI or literal created as the "value" in the property's name/value pair.

REST Examples


Relationships

As may be expected, relationships between resources within, as well as external to the repository are defined like any other resource property, presumably with a URL as the "value" of the property which references the other resource. In the case where the resources within the repository are physically structured, Fedora adds a properties that note the containment of the child resources (http://www.w3.org/ns/ldp#contains and http://fedora/info/definitions/v4/repository#hasParent). As a slightly more advanced use, the user can define an additional default relationship properties that will be applied to parent and child resources. 

 

REST Examples