Fedora objects to demonstrate UW-Madison's Content Models and Disseminations September 2009 Note: These objects are intended primarily to provide an example of how we've structured our content. Some of the disseminations will not work out of the box, as they rely on disseminators running on access-controlled servers at UW. Files: Content Models CModelCompositeObject.xml CModelContentObject.xml CModelFirstClassObject.xml CModelImageWithDefaultRes.xml CModelImageWithXLarge.xml CModelImageWithZoom.xml [not used in the example object] Service Definitions SDefineFirstClassObject.xml SDefineImageWithDefaultRes.xml SDefineImageWithIcon.xml SDefineImageWithXLarge.xml SDefineImageWithZoom.xml [not used in the example object] Service Deployments SDeployFirstClassObject.xml SDeployImageWithDefaultRes.xml SDeployImageWithDefaultResJP2.xml SDeployImageWithIcon.xml SDeployImageWithXLarge.xml SDeployImageWithXLargeJP2.xml [not used in the example object] SDeployImageWithZoom.xml [not used in the example object] Content Objects FdExmpl.WillCU1482.xml FdExmpl.WillCU1482.01.xml FdExmpl.WillCU1482.02.xml The demonstration object is a postcard with both front and back views. It is represented by three Fedora objects: Parent object. demo:FdExmpl.WillCU1482 - The logical object for the postcard - It will be returned in search results - A dissemination of this object with the method viewMETS() will include data from all of its child objects, packaged in a single METS file - It records its relationship to its child objects in RELS-EXT with a fedora:hasMember relation - Content models: * demo:CModelContentObject: requires ORIGIN datastream with provenance metadata: the ProjectID of the project it was created under, and Submitter (with affiliation). This is mainly a convenience CModel, used to separate content objects from administrative objects (CModels, SDefines. SDeploys, XSLTemplates, etc.), and to require ORIGIN datastreams for all content objects, for archival and preservation purposes. It uses a homegrown XML schema, which includes PREMIS administrative data elements along with locally-defined ones. Others may want to use their own schemas for this, or perhaps dispense with it all together. * demo:CModelCompositeObject: means that it has child objects. Requires STRUCT datastream which is a METS listing (and optionally ordering) children. * demo:CModelFirstClassObject: requires BIB0 datastream (MODS). We export only FirstClassObjects for Solr indexing. Child content objects. These may be of any type, of arbitrary number, structure and complexity. In the case of postcards, there will probably be two children, each a simple image. For this example, we've provided images that rely on static JPEG derivatives. Becuse we have to deal with legacy objects that may not always have an extra large size, we've made ImageWithXLarge a separate Content Model, to handle just that size. demo:FdExmpl.WillCU1482.01 - Image of the front of the postcard - Label ("Front") provided as the content of in the DC datastream. - It will encode its parent in RELS-EXT with a fedora:isMemberOf relation - It does NOT encode a relationship to its sibling; that's handled in the parent's STRUCT - Content models: * demo:CModelContentObject: requires ORIGIN datastream with provenance metadata. At this level, it may only include the ProjectID of the project it was created under. It is presumed that it inherits the Submitter of its parent object. * demo:CModelImageWithDefaultRes: requires datastreams THUMB, REF, LARGE, each of MIME type image/jpeg. * demo:CModelImageWithXLarge: requires datastream XLARGE, of MIME type image/jpeg demo:FdExmpl.WillCU1482.02 - Image of the back of the postcard - Label ("Back") provided as the content of in the DC datastream. - It will encode its parent in RELS-EXT with a fedora:isMemberOf relation - It does NOT encode a relationship to its sibling; that's handled in the parent's STRUCT - Content models: * demo:CModelContentObject: requires ORIGIN datastream with provenance metadata. At this level, it may only include the ProjectID of the project it was created under. It is presumed that it inherits the Submitter of its parent object. * demo:CModelImageWithDefaultRes: requires datastreams THUMB, REF, LARGE, each of MIME type image/jpeg. * demo:CModelImageWithXLarge: requires datastream XLARGE, of MIME type image/jpeg Additional datastreams could be defined; e.g. to hold text transcribed from each image. Because Content Models can only encode required datastreams, you'd want those to be optional. Or you could put transcribed text in in DC. Note that we don't yet have technical metadata streams in these objects. We plan to, and will add them to the appropriate CModels. Fedora object naming conventions: To aid searching and readability, we've established the following naming conventions for our Fedora objects: CModel*: objects that are Content Models (i.e., demo:CModelFirstClassObject) SDefine*: objects that are Service Definitions (i.e., demo:SDefineFirstClassObject) SDeploy*: objects that are Service Deployments (i.e., demo:SDeployFirstClassObject) Thumbnail*: objects that hold generic thumbnail images to represent non-visual media types (i.e., demo:ThumbnailForRealAudioStream) XMLSchema*: objects that hold XMLSchema for validation purposes (i.e., demo:XMLSchema-METS-1.7) XSLStylesheet*: objects that hold XSLT for content processing (i.e., demo:XSLStylesheetMets2Solr) Collection*: objects that aggregate content objects into groups (i.e., demo:CollectionAfricaFocus) Content objects' PIDs are generally constructed from a Project ID followed by the logical object's unique ID within the project, followed by any child objects of the logical object. Example: demo:FdExmpl.WillCU1482.01 "demo:" -- the Fedora namespace "FdExmpl" -- the Project ID "WillCU1482" -- the logical object (the postcard) "01" -- the first component of the logical object (image of the front of the card) Peter Gorman pgorman@library.wisc.edu Scott Prater sprater@doit.wisc.edu