...
DSpace 2 data model entities "marked" with property http://www.w3.org/1999/02/22-rdf-syntax-ns#type = info:fedora/fedora-system:def/model#FedoraObject are mapped to Fedora objects. Entities having property http://www.w3.org/1999/02/22-rdf-syntax-ns#type = FedoraObjectDatastream are indirectly mapped (binary property has direct datastream mapping) to Fedora objects datastreams. Entities having no #type property, by default are mapped to Fedora objects. Datastream dependence to object is indicated using info:fedora/fedora-system:def/recovery#pid property.
All necessary administrative Fedora object and datastream properties are taken from corresponding entity properties. If multiple properties with same name exist and only one is needed - first one is taken.
| HTML Comment | ||
|---|---|---|
| ||
| Wiki Markup | ||
| {HTMLcomment:hidden}
<!--
dependence to object is indicated using info:fedora/fedora-system:def/view#hasDatastream relation. Datastream entites must have exactly one file (binary type) property (datastream itself). Format type entities having http://www.w3.org/1999/02/22-rdf-syntax-ns#type = http://purl.org/dspace/model#Format property are mapped to Fedora objects. Its RELS-EXT is supplemented with later property for fast supported formats listing (possibly in DSpace UI, when user needs to select mimetype for file).
|
Properties
Properties of DSpace 2 entities are mapped to Fedora RELS-EXT, RELS-INT, DC datastream entries and separate datastreams. If property has name http://purl.org/dspace/model#ContentFile, is binary type (InputStream java class) and is located in FedoraObjectDatastream entity, then it will directly result as a datastream. Only one http://purl.org/dspace/model#ContentFile property is allowed per FedoraObjectDatastream entity. Any string property starting with http://purl.org/dc/elements or http://www.openarchives.org/OAI/2.0/oai_dc/ will end up in DC datastream. Any other non DC and non administrative (administravite starts with info:fedora) string property will go into RELS-EXT for FedoraObject entities and RELS-INT for FedoraObjectDatastream entities.
String properties can be freely defined by user which may not provide namespace, so in such cases "local" namespace http://localhost/model# will be forced.
...
When designing DSpace2 model implementation, designer (user) should also keep in mind, that entities relations pointing from parent to child can be inefficient, since parent entities usually tend to have a lot of child entities (consider the example of parent Library and child Book above). If parent references all of its children, parent Fedora object will possibly have large rapidly changing and growing number of RELS-EXT entries. This problem does not arise in child to parent referencing.
| HTML Comment | ||
|---|---|---|
| ||
| Wiki Markup | ||
| {HTMLcomment:hidden}
<!--
are some things to note, which user must keep in mind creating relations in DSpace2 model implementation. DSpace 2 model may have various relation types between entities, for example: "hasBook", "hasFile", "isResearcherAt", "scannedBy". In general, if parent entity has relation to child entity, then this relation can be called "hasChild" and from child perspective it may be "isChildOf". So basically child can have reference in its RELS-EXT to parent the same way parent may have reference in its RELS-EXT to child. Problematic is the second case, because parent entities usually tend to have a lot of child entities (consider the example of parent Library and child Book above), thus if it references all of its children, parent object will possibly have rapidly changing and growing number of RELS-EXT entries, which may be inefficient. This problem does not arise in child to parent referencing. In this DSpace2-Fedora3 model mapping, it is proposed that if not defined separately by user, Fedora objects (represented entities) by default will be related with directional child-to-parent relation, despite relation name.
|
Identifiers
It is very likely, that organizations using Fedora, may prefer using their custom Fedora objects PIDs and DSIDs (datastream IDs), so implemented storage-fedora module does allow this functionality. User himself must ensure uniqueness of custom identifiers. DSpace entity identifier must have form of info:fedora/PID for objects and info:fedora/PID/DSID for datastreams, so that it can be interpreted correctly by storage-fedora module. Incorrect entity identifier (incompatible with Fedora resource URI) will result in error. If Fedora object or datastream identifier in not provided - one will be generated automatically.
| HTML Comment | ||
|---|---|---|
| ||
| Wiki Markup | ||
| {HTMLcomment:hidden}
<!--
is very likely, that organizations using Fedora, may prefer using their custom Fedora objects PIDs and DSIDs (datastream IDs), so it is proposed that in storage-fedora module Fedora objects (mapped DSpace2 entities) identifiers can be configurable by user. In this case, user himself must ensure uniqueness of custom identifiers. Also there will be a mechanism allowing generating default PIDs and DSIDs without user intervention.
|
Fedora PID namespace, used for automatic PID generation, is configurable and predefined in storage-fedora module configuration file.
...