|
Size: 2810
Comment:
|
Size: 3967
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| The Doms system defines import and export of objects to/from Fedora as disseminators on content models. The main problem of import and export, is that in an atomistic datamodel, importing from an external system will probably generate more Fedora objects, and export to another system will probably need to draw on information from more then one object. | The Doms system defines import and export of objects to/from Fedora as disseminators on content models. The main problem of import and export, is that in an atomistic datamodel, importing from an external system will probably generate more than one Fedora object, and export to another system will probably need to draw on information from more then one object. |
| Line 5: | Line 5: |
| Basically, a number of disseminators are reserved for communication with external systems. The idea is that import-disseminators will generate a number of related objects in Fedora, and return the PID of on object of the content model the disseminator is defined on. Export-disseminators will bundle together a number of objects and generate an external representation based on that information. This will be described in more detail below. | Basically, a number of Fedora disseminators are reserved for communication with external systems. We are somewhat abusing disseminators for this purpose, since they were not designed to have side effect, which import functions will have. However, since disseminators give us a good place to describe webservices associated with a content model, we chose to bend the rules a little here. The idea is that import-disseminators will generate a number of related objects in Fedora, and return the PID of an object of the content model the disseminator is defined on. Export-disseminators will bundle together a number of objects and generate an external representation based on that information. This will be described in more detail below. |
| Line 13: | Line 15: |
| The disseminator may take input parameters, usually this will include an ID from the system to import from. | The disseminator may take input parameters, usually this will include an ID from the system to import from, and username/password, because we need them to import objects into Fedora. |
| Line 17: | Line 19: |
| Calling the disseminator will have the side effect of a number of objects being ingested in Fedora. These objects will be interrelated, and usually part of the same view. | Calling the disseminator will have the side effect of a number of objects being ingested in Fedora. These objects will be interrelated, and usually part of the same view. Or put in another way, when designing import webservices, we will try to design them, so calling an import disseminator will generate objects that are shown as a single entity when using the GUI. |
| Line 21: | Line 23: |
| The disseminator will return a single string, that is the PID of one of the created objects. The Content Model of this PID will always be of the Content Model the import disseminator is called on. | The disseminator will return a single string, that is the PID of one of the created objects. The Content Model of this PID will always at least implement the Content Model the import disseminator is defined in. |
| Line 23: | Line 25: |
| Disseminators are always called on objects, never just on a content model. Therefore, to call the disseminator you need to select an object to call it on. It is expected that it is always called on template objects, and the implementation of disseminators are allowed, but not required, to use information defined in the template objects. | Disseminators are always called on objects, never on content models. Therefore, to call the disseminator you need to select an object to call it on. It is expected that it is always called on template objects, and the implementation of disseminators are allowed, but not required, to use information defined in the template objects. |
| Line 27: | Line 29: |
| Export is also defined as disseminators on content models. | Export is a lot simpler. Basically, export functions are no different than any other Fedora disseminator, and are only defined because we need a way to describe a set of disseminators used for the use case of exporting data to other systems. |
| Line 35: | Line 37: |
| Calling the dissemintor on an object will generate output in a format defined by the disseminator, and may draw on the given object, and any other objects. Usually, it will use information from the same view. | Calling the disseminator on an object will generate output in a format defined by the disseminator, and may draw on the given object, and any other objects. Usually, it will use information from the same view, for some view. |
| Line 38: | Line 40: |
Often, disseminators will be implemented by bundling together all objects from a given view, and then running an XSLT on these to generate the output. Use cases are among others: * Bundling together objects for indexing by a search engine * Bundling together objects, and then transforming them to Quadriga XML, to give as input to Quadriga digitalisation software |
Import and Export of Fedora objects using Content Models
The Doms system defines import and export of objects to/from Fedora as disseminators on content models. The main problem of import and export, is that in an atomistic datamodel, importing from an external system will probably generate more than one Fedora object, and export to another system will probably need to draw on information from more then one object.
Basically, a number of Fedora disseminators are reserved for communication with external systems. We are somewhat abusing disseminators for this purpose, since they were not designed to have side effect, which import functions will have. However, since disseminators give us a good place to describe webservices associated with a content model, we chose to bend the rules a little here.
The idea is that import-disseminators will generate a number of related objects in Fedora, and return the PID of an object of the content model the disseminator is defined on. Export-disseminators will bundle together a number of objects and generate an external representation based on that information. This will be described in more detail below.
Import
Given a content model, it may have disseminators for Import of objects to this content model.
The disseminators are recognisable as import disseminators by naming: The name of the disseminator will have the prefix "import_".
The disseminator may take input parameters, usually this will include an ID from the system to import from, and username/password, because we need them to import objects into Fedora.
You can find the disseminators and the required parameters using ["Fedora 3.0 API/Access#listMethods"]
Calling the disseminator will have the side effect of a number of objects being ingested in Fedora. These objects will be interrelated, and usually part of the same view. Or put in another way, when designing import webservices, we will try to design them, so calling an import disseminator will generate objects that are shown as a single entity when using the GUI.
You can call the disseminator using ["Fedora 3.0 API/Access#getDissemination"]
The disseminator will return a single string, that is the PID of one of the created objects. The Content Model of this PID will always at least implement the Content Model the import disseminator is defined in.
Disseminators are always called on objects, never on content models. Therefore, to call the disseminator you need to select an object to call it on. It is expected that it is always called on template objects, and the implementation of disseminators are allowed, but not required, to use information defined in the template objects.
Export
Export is a lot simpler. Basically, export functions are no different than any other Fedora disseminator, and are only defined because we need a way to describe a set of disseminators used for the use case of exporting data to other systems.
The disseminators are recognisable as export disseminators by naming: The name of the disseminator will have the prefix "export_".
You can find the disseminators and the required parameters using ["Fedora 3.0 API/Access#listMethods"]
The disseminator may take input parameters, but this is not required.
Calling the disseminator on an object will generate output in a format defined by the disseminator, and may draw on the given object, and any other objects. Usually, it will use information from the same view, for some view.
You can call the disseminator using ["Fedora 3.0 API/Access#getDissemination"]
Often, disseminators will be implemented by bundling together all objects from a given view, and then running an XSLT on these to generate the output. Use cases are among others:
- Bundling together objects for indexing by a search engine
- Bundling together objects, and then transforming them to Quadriga XML, to give as input to Quadriga digitalisation software