Drupal Content Types used in the USGIN Document Repository
The Collection content type acts as an arbitrary logical unit (or container) that groups the Document-like Information Object (DLIO) nodes which hold the actual data resource. At this time, Collections fulfill 3 objectives at once. Perhaps, they need to be separated at a later point.
- Used to internally organize DLIOs into access groups for "Curators" (content providers and managers) as part of the work flow.
- Used for branding (organization names, logos, icons) and shared metadata (resource contact information) of DLIOs that belong to a collection.
- Allow for arbitrary bins (some sort of category) for browsing or searching for DLIOs. Think of it as special collections in a library or museum context. Hence, we called collection managers "curators."
Following are the main fields we are currently using in Collections. The field groups are used in conjunction with the Vertical Tabs module and, at this time, affects the Conditional Fields module.
- Title: Drupal core
- Basic Information group
- Curator: CCK user reference - determines what Collection and DLIO nodes a registered user will see in the workflow pages
- Description: CCK text
- Responsible Party group - the following fields are shared with DLIOs in the same Collection
- Organization: CCK multi-value text - only the first Organization is displayed in the ISO 19139 XML
- Street Address: CCK text
- City: CCK text auto-complete
- State: CCK text auto-complete
- Postal Code: CCK text auto-complete
- Country: CCK text >auto-complete
- Email: CCK email>
- Phone: CCK text>
- Fax: CCK text
- Image Branding group - used to brand Colelctions and DLIOs.
- Disclaimer: CCK on/off check-box - the disclaimer has to be agreed too before any images can be uploaded (uses the Conditional Fields module).
- Icon: CCK image - To include a Collection icon to a DLIO record in Views, I created a custom node-ct_collection.tpl.php template file in the site's Theme that shows only the icon image (strips title, tags, breadcrumbs, etc.) in a "teaser" presentation. We then can use the Collection node reference in DLIO's with a with "teaser" display to show just the icon image. This is a rather crude but effective hack because we do not use a Collection's "teaser" display anywhere else. >
- Logo: CCK image>
Document-like Information Object (ct_dlio)
The Document-like Information Object (DLIO - coined by FAO's AgriDrupal) content type is a digital resource object that contains a bundle of digital files and/or links to human-consumable online-resources (not services for machines). This convenient hybrid object contains both metadata and data; and, it allows us to avoid the nighmare of having to create separate metadata entries for ech individual file or link in bundled resources. For example, one DLIO node may include multiple representations (Access DB, Shapefile, GeoTIFF, word report, etc.) for the same information object. To keep it simple, repository users are just dealing with "submissions" and we avoid complicating things with the DLIO concept.
Following are the main fields we are currently using in DLIOs. The field groups are used in conjunction with the Vertical Tabs module and, at this time, affects the Conditional Fields module.
- Title: Drupal core
- Basic Information group
- Collection: CCK node reference - creates the dependencies and linkages to ct_collection and its fields (including the "Curator" user reference).
- Document Type: CCK text list - originally used to control the visibility of metadata fields via the Conditional Fields module. At this point, the available metadata field do not change depending on the "document type" or "data format." We were not able to come up with a standardized and convenient list of document types/formats. At this point, it is an arbitrary classification list that will have to be revisited.
- Author: CCK auto-complete multi-value text - captures the resource's authors, editors, corporate authors, "originators," etc.
- Description: CCK multi-line text: abstract, description, etc.
- Publication Date: CCK date (year/month/day) - originally we only intended to captured the year.
- Resource Language: CCK text list - defaults to "English" and uses ISO639-2/T three letter language codes as the keys.
- Keywords: Taxonomy - a free form subject descriptor tag
- File Attachments group
- Disclaimer: CCK on/off check-box - the disclaimer has to be agreed too before any files can be uploaded (uses the Conditional Fields module).
- Available Files: CCK multi-value file - hopefully, it is the document described by the metadata
- Web Resources Links group
- Resource URL: CCK multi-value link
- Geographic Extent group - captures a resources spatial extent in form of a minimum bounding rectangle. The following fields are interconnected through several Rules module rules which parses the WKT MBR string and populates either the coordinate fields or WKT MBR field depending on how the user enters the bounding coordinates.
- WKT MBR: OpenLayers WKT (Well Known Text) field - this field provided by the OpenLayers module includes a map GUI for displaying and drawing polygons. One of the Rules module rules converts any entered polygons to their minimum bounding rectangle.
- North bounding latitude: CCK integer (with default value) - decimal degree coordinate with WGS84 datum/projection
- South bounding latitude: CCK integer (with default value) - decimal degree coordinate with WGS84 datum/projection
- West bounding longitude: CCK integer (with default value) - decimal degree coordinate with WGS84 datum/projection
- East bounding longitude: CCK integer (with default value) - decimal degree coordinate with WGS84 datum/projection
- Temporal Extent group - at this time, we are only handling only modern time frame. Geological time periods are not handled here and must be included as keywords.
- Temporal Extent: CCK date range - start and optional end date
- Unique Resource Identification group
- Resource ID: CCK multi-value text - this is the catch-all for ISBN, ISSN, DOI, URI, or any other arbitrary resource ID we may come across. Eventually, we probably will need to create a custom CCK module that includes a drop down list with ID systems to choose from.
- Previous Citation group
- Citation: CCK multi-line text - a catch all citation field for published resources. This is a way of not loosing bibliographic information without having to add many more fields and without prolonging the metadata entry gauntlet.
- Unique Metadata ID group
- Metadata ID: CCK text with default value generated by the UUID module. We also have a Rules module rule which auto-populates this field on safe if it is empty.