Differences between revisions 5 and 6
Revision 5 as of 2008-10-14 12:01:34
Size: 2324
Editor: abr
Comment: Mjoelner changed their minds
Revision 6 as of 2008-10-14 12:34:12
Size: 2991
Editor: abr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
= Fedora Object Prototypes = = Fedora Object Templates =
Line 4: Line 4:
It is easily possible to create data objects from the definition in a content model, which was the basic strategy for the DOMS GUI. This strategy has one drawback, however. With just the information contained in the content models, almost no data can be automatically filled in. But for most data objects there are much data that could be filled automatically, based on the context. As a general solution to this problem, we introduced the concept of Object Prototypes (templates, stem-objects and so on). It is easily possible to create data objects from the definition in a content model, which was the basic strategy for the DOMS GUI. This strategy has one drawback, however. With just the information contained in the content models, almost no data can be automatically filled in. But for most data objects there is much data that could be filled automatically, based on the context. As a general solution to this problem, we introduced the concept of Object Templates (prototypes, stem-objects and so on).
Line 6: Line 6:
A prototype is for all intents and purposes a normal data object. It has a special relation "doms-relations:isPrototypeFor" (see DomsNameSpaces) to a content model. This marks it as a prototype for this content model. There can be any number of prototypes for each content model, but each to them must have at least one. This one will be the blank object, ie. the object that could be automatically created from the content model. A template is for all intents and purposes a normal data object. It has a special relation "doms-relations:isTemplateFor" (see DomsNameSpaces) to a content model. This marks it as a template for this content model. There can be any number of templates for each content model, but each to them must have at least one. This one will be the blank object, i.e. the object that could be automatically created from the content model.
Line 8: Line 8:
A prototype object is not guaranteed to be valid in regards to the content models that describe it. It is guaranteed not to contain anything not allowed, but it might not contain everything required, as this should be filled in when the prototype is used. A prototype is therefore never in the STATE "published", but always in "intermediate", (see FedoraTransactionsReplacement). This prevents the validation services from marking the object as broken, and the dissemination services from publishing the object to the customers. A template object is not guaranteed to be valid in regards to the content models that describe it. It is guaranteed not to contain anything not allowed, but it might not contain everything required, as this should be filled in when the template is used. A template is therefore never in the STATE "published", but always in "intermediate", (see FedoraTransactionsReplacement). This prevents the validation services from marking the object as broken, and the dissemination services from publishing the object to the customers.
Line 10: Line 10:
A template object must always be part of a collection, like ordinary data objects.
Line 11: Line 12:
== Using a prototype == == Using a template ==
Line 13: Line 14:
The way to create a new object via the prototype goes like this:
 1. Select the content model you wish to create a new object from
 1. Query the triple store for all objects having a "doms-relations:isPrototypeFor" relation to this content model
 1. Have the user select one of the found prototypes
 1. Load the object from Fedora.
 1. Change the PID so that when resaved it does not overwrite the prototype
 1. Remove the "doms-relations:isPrototype" relation from the object.
 1. Open the loaded+changed object in the GUI
 1. Have the user perform any other changes
 1. Ingest the object with the new PID.
The way to create a new object via the template goes like this:
 1. Find the possible template object
  1. Select the collection
  1. Find all templates in this collection
  1. Narrow the list to all templates that have a "doms-relations:isTemplateFor" relation to a acceptable content model
 1. Have the user select one of the found templates
 1. Load the object from Fedora and change it to a normal data object
  1. Generate a new PID for the object
  1. Replate all "doms-relations:isTemplateFor" relations with "fedora-model:hasModel" relations.
  1. Set the state to "draft"
  1. Save the new object to Fedora
 1. Open the new object in the GUI
Line 24: Line 27:
So, the relations from the prototype will be copied into the new object, along with the content of any datastreams. So, the relations from the template will be copied into the new object, along with the content of any datastreams.

== Abstract Content Models ==

Templates are meant to be the one and only way to create new objects, aside from batch ingests, import and other yet-to-be defined ways. So, for content models without templates, there are no way to make objects of this content model. Such content models are referred to as abstract content models, and many of the content models in the Base collection will be abstract.

Note, you can still create objects of other content models, that extends the abstract models. Just not of the abstract models themselves.

Fedora Object Templates

It is easily possible to create data objects from the definition in a content model, which was the basic strategy for the DOMS GUI. This strategy has one drawback, however. With just the information contained in the content models, almost no data can be automatically filled in. But for most data objects there is much data that could be filled automatically, based on the context. As a general solution to this problem, we introduced the concept of Object Templates (prototypes, stem-objects and so on).

A template is for all intents and purposes a normal data object. It has a special relation "doms-relations:isTemplateFor" (see DomsNameSpaces) to a content model. This marks it as a template for this content model. There can be any number of templates for each content model, but each to them must have at least one. This one will be the blank object, i.e. the object that could be automatically created from the content model.

A template object is not guaranteed to be valid in regards to the content models that describe it. It is guaranteed not to contain anything not allowed, but it might not contain everything required, as this should be filled in when the template is used. A template is therefore never in the STATE "published", but always in "intermediate", (see FedoraTransactionsReplacement). This prevents the validation services from marking the object as broken, and the dissemination services from publishing the object to the customers.

A template object must always be part of a collection, like ordinary data objects.

Using a template

The way to create a new object via the template goes like this:

  1. Find the possible template object
    1. Select the collection
    2. Find all templates in this collection
    3. Narrow the list to all templates that have a "doms-relations:isTemplateFor" relation to a acceptable content model
  2. Have the user select one of the found templates
  3. Load the object from Fedora and change it to a normal data object
    1. Generate a new PID for the object
    2. Replate all "doms-relations:isTemplateFor" relations with "fedora-model:hasModel" relations.
    3. Set the state to "draft"
    4. Save the new object to Fedora
  4. Open the new object in the GUI

So, the relations from the template will be copied into the new object, along with the content of any datastreams.

Abstract Content Models

Templates are meant to be the one and only way to create new objects, aside from batch ingests, import and other yet-to-be defined ways. So, for content models without templates, there are no way to make objects of this content model. Such content models are referred to as abstract content models, and many of the content models in the Base collection will be abstract.

Note, you can still create objects of other content models, that extends the abstract models. Just not of the abstract models themselves.

FedoraObjectTemplates (last edited 2010-03-17 13:12:47 by localhost)