Archiving and Fedora
First-Class Fedora Objects
All tDAR objects in Fedora will, of coarse, conform to the Fedora Digital Object Model. Below are the definitions of tDAR specific objects. All objects are required by Fedora to have Dublin Core, RELS-EXT, and Audit datastreams. Also, all object metadata will be expressed in MODS. It will also be assumed that datastreams listed in the below definitions are in addition to these.
Project
Datastreams
No datastreams are required for project as it is only metadata.
Disseminations
List members?
Relationships
Children will define "isMemberOf" relationships.
Dataset
Datastreams
name |
mime-type |
note |
|---|---|---|
SOURCE |
text/csv, application/vnd.ms-excel, application/vnd.ms-access |
|
ACTIVE-DATA |
text/plain |
this is the PostreSQL dump |
DATA-DEF |
text/plain, text/xml |
placeholder in case we need to create a serialized mapping of the data columns - have not determined if this will still be required |
Disseminations
- Zip of all Datastreams?
Relationships
- hasCodingSheet
- hasOntology
- isMemberOfCollection
Ontology
Datastreams
name |
mime-type |
note |
|---|---|---|
OWL |
text/xml |
Disseminations
Relationships
Associated objects define relationships.
Coding Sheet
Datastreams
name |
mime-type |
note |
|---|---|---|
SOURCE |
text/csv, text/xml |
Disseminations
Relationships
Associated objects define relationships.
Image
Datastreams
name |
mime-type |
note |
|---|---|---|
SOURCE |
image/jpeg, image/png, image/gif, |
interested in archival quality images? |
Disseminations
- Thumbnail
- Medium-Res
Relationships
- isMemberOfCollection
Document
Datastreams
name |
mime-type |
note |
|---|---|---|
SOURCE |
application/pdf, application/msword, text/html, text/plain, text/xml |
Disseminations
Relationships
- isMemberOfCollection
Citation
Datastreams
name |
mime-type |
note |
|---|---|---|
RIS |
text/plain |
if we are going to accept semi-structured citations |
Disseminations
Relationships
- isMemberOfCollection
tDAR RELS-EXT Ontology
The relationships between the objects (expressed in Fedora as RELS-EXT) can come from the RELS-EXT ontology or from one of our own making. For instance, to express the that Document (with id of D:2) is a member of Project (with an id of P:5) we can use a predefined Fedora property:
or create our own:
The above examples are expressed with N-Triples.
Is it preferable for tDAR Fedora objects to explicitly state certain relationships to others or is it OK to infer relationships from more generic statements depending on the types of Ferdora object to which it is related? For example, are properties such as hasCodingSheet or hasOntology more appropriate than inferring the exact nature of a hasDescription property depending on the type of object that is providing the description? One benefit of explicit definition is in querying the relationships -- we would not have to filter the hasDescription query ex post facto.