# Presentation: 513422

## SEMANTIC UNITS PERTAINING TO OBJECTS

## Object entity

- Aggregates characteristics relevant to preservation management that are properties of the object
- Semantic units may not all be applicable to each type of object (representation, file, bitstream)
- Main types of information
- identifier
- object characteristics
- creation information
- software and hardware environment
- digital signatures
- relationships to other objects
- links to other types of entity

## preservationLevel and objectCategory

**objectCategory**
- Values: representation, file, bitstream
**preservationLevel**
**What preservation treatment/strategy the repository plans for this object**
- Varying preservation options dependent on factors such as value, uniqueness, preservability of format
- A business rule only relevant in a given repository
- Examples: full, bit-level
- Now mandatory, but revision will change to optional

## objectCharacteristics

- Applicable only to file and bitstream
- Technical properties common to all/most file formats, not format specific
- Container for subunits:
- compositionLevel
- fixity
- size
- format
- significantProperties
- inhibitors

## fixity

- Information used to verify whether an object has been altered; compare message digests (“checksums”) calculated at different times
- Container for messageDigestAlgorithm, messageDigest, messageDigestOriginator
- Automatically calculated and recorded by repository
**messageDigestAlgorithm***: *controlled vocabulary, example: SHA-1
**messageDigest***: *output of message digest algorithm
**messageDigestOriginator***: *agent that created original message digest; could be a string or a pointer
**Example:**
- 	messageDigestAlgorithm=	Adler-32
- 	messageDigest=7c9b35da
- 	messageDigestOriginator=	OCLC

## format 

**Identifies the format of a file or bitstream**
- Container semantic unit
- Preservation activities depend on detailed and accurate knowledge about formats
- Should be ascertained by repository on ingest (for example, using JHOVE)
- May be a format name (formatDesignation) or a pointer into a registry (formatRegistry)

## formatDesignation and formatRegistry

**formatDesignation**
**Identifies the format of an object by name and version**
- Format may be a matter of opinion:  Is it text, xml, or METS?
- MIME type is most widely used authority list
- May need more granularity; may be multipart (tiff 6.0/geotiff)
**formatRegistry**
**Identifies format by reference to an entry in a format registry**
- Detailed specifications on formats may be contained in a future format registry
- formatRegistryName, formatRegistryKey, formatRegistryRole
- Role includes purpose or expected use

## Examples of format

- formatDesignation
- 	formatName=.eps
- 	formatVersion=2.0
- formatRegistry
- 	formatRegistryName=PRONOM
- 	formatRegistryKey=eps
- 	formatRegistryRole=Basic
- formatDesignation
- 	formatName=PDF
- 	formatVersion=1.5
- formatRegistry
- 	formatRegistryName=LC digital format descriptions
- 	formatRegistryKey=fdd000123
- 	formatRegistryRole=assessment

## significantProperties

**Characteristics of an object considered by a repository to be important to maintain through preservation actions**
- May apply to all objects of a certain class or may be unique to each individual object
- May be determined by business rules of the repository
- Not an intrinsic property of an object; a particular archive's assessment of which of the object's properties need to persist over time
- Related to the preservation strategy chosen by the archive
- Listing significant properties implies that the repository plans to preserve those properties and would note any modifications to them in eventOutcome
- May need to be further developed in the future

## Examples of significantProperties

- For a PDF with embedded links that are not essential use: “Content only”
- For a TIFF file: “Color accuracy (Adobe RGB 1998)”
- For a Web page: “One of two embedded FLASH files for splash page”

## inhibitors

**Features of the object intended to inhibit access, use or migration**
- It is necessary to record the kind of encryption and the access key to allow future use of the object
- Applicable to file and bitstream
**inhibitorType**
- Inhibitor method employed, e.g. “DES”, “password protection”
**inhibitorTarget**
- The content or function protected, e.g. “function: print”
**inhibitorKey**
- The decryption key or password
**Example:**
- 	inhibitorType=DES
- 	inhibitorTarget=all content
- 	inhibitorKey=[DES encryption key]

## compositionLevel

**An indication of whether the object is subject to one or more processes of decoding or unbundling**
- How to describe layers of encodings so they can be correctly reversed?
- Treat each layer as a “composition level”
- Repeat description of object characteristics for each composition level
- A file with no compression and no encryption has compositionLevel 0 (zero)
- Each layer of encoding results in new format and incremented compositionLevel
- Only applies if object is encrypted or compressed
- Value is an integer

## Files again

**FILE** = a named and ordered sequence of bytes that is known by an operating system.
- chapter1.pdf
- photo.tiff
- mapofGlasgow.jp2
- Can be zero or more bytes
- Has a file format
- Has access permissions and file system statistics such as size and modification date

## Bitstreams again

**BITSTREAM** = contiguous or non-contiguous data within a file that has meaningful common properties for preservation purposes.
- the video stream within an AVI file
- an image within a TIFF file
- Not known to operating system
- Can be located by starting position within the file
- Can not stand alone as a file without the addition of a header, other structure, or reformatting

## But some files aren’t that simple

- format = PDF
- size = 500,000 bytes
- messageDigest = [something]

- chapter1.pdf

- chapter1.gz

- Unix gzip
- utility

- format = gzip
- size = 324,876 bytes
- messageDigest = [something else]

## compositionLevel

| compositionLevel |  |  | 0 |
| --- | --- | --- | --- |
| fixity | messageDigest
Algorithm |  | SHA-1 |
| fixity | messageDigest |  | [big string] |
| fixity | messageDigest
Originato |  | Submitter |
| size |  |  | 500000  |
| format | format
Designa-tion | format
Name
 | PDF |
| format | format
Designa-tion | format
Version | 1.2 |

- chapter1.pdf

| compositionLevel |  |  | 1 |
| --- | --- | --- | --- |
| fixity | messageDigest
Algorithm |  | SHA-1 |
| fixity | messageDigest |  | [another
string] |
| fixity | messageDigest
Originator |  | Repository |
| size |  |  | 324876  |
| format | format
Designa-tion | format
Name
 | gzip |
| format | format
Designa-tion | format
Version | 1.2.3 |

- chapter1.pdf.gz

## Ok, but what if you have this:

- package.tar

- file1.pdf

- file2.pdf

- Inside the TAR file, file1 and file2 are simple PDF files.
- Neither the containing TAR nor the contained PDFs are encrypted or compressed.

## Then you have 3 objects!

- package.tar

- file1.pdf

- file2.pdf

- package.tar is a file object with compositionLevel 0 and a storageLocation in the file system
- file1.pdf is a file object with compositionLevel 0 and a storageLocation as an offset in package.tar
- file2.pdf is a file object with compositionLevel 0 and a storageLocation as an offset in package.tar

## In conclusion

- Remember: Composition level increments only when you have a single file object with multiple successive encodings.
- Bonus question: why aren’t the PDF files within package.tar considered bitstream objects?
- Because the PDFs inside the TAR are independently interpretable

## Creation information

**creatingApplication**
**Information about application which created object**
- Useful for later problem solving
- Container with 3 subunits: name, version, date
- Applies to objects created externally or by repository, e.g. by migration event
- Repeatable if more than one application processed it
- Example: MS Word 2000 [date created]
**originalName**
**Name of object as submitted to or harvested by repository**
- *Supplements repository supplied names
- Only applicable to files

## storage 

**How and where the object is stored**
- Container for contentLocation and storageMedium
- May be repeated if more than one identical copy in a different location
**contentLocation**
- Information needed to retrieve a file from a system or a bitstream from within a file
- Subunits type and value
- Could be fully qualified path or identifier used by storage system; for bitstream a byte offset
**storageMedium**
- Physical medium on which the object is stored
- Useful for media management (e.g. media migration)
- May be name of system that knows the medium
- Examples: hard disk, TSM

## Example of creation information and storage

- creatingApplication
- 	creatingApplicationName=Adobe Acrobat
- 	creatingApplicationVersion=5.0
- 	dateCreatedByApplication=2004
- originalName=main.pdf
- storage
- 	contentLocation
- 		contentLocationType=FDA
- 		contentLocationValue=fda/prod/data/out/classa/ DF-	2005-001002
- 	storageMedium=3590 [a type of tape unit]

## Environment

- What is needed to render or use an object
- Operating system
- Application software
- Computing resources
- Why is obligation optional?
- Preservation strategies may differ in need for this information (e.g., may be unneeded for bit-level preservation)
- We currently lack practical methods to collect and store this information
- Relevance to long-term preservation: Ability to render an  object and interact with its content may depend on knowing these technical details
- Applies to all types of object (representation, file, bitstream)

## Environment semantic units

**environmentCharacteristic**
- Multiple environments can support an object, but often not equally well
- Suggested values: unspecified, known to work, minimum, recommended
- Repository does not need to record all possible environments
**environmentPurpose**
- Use supported by the specified environment
- Suggested values: render, edit
- example: for x.pdf Adobe Acrobat (edit), Adobe Reader (render)

## Environment semantic units (cont.)

**software and hardware**
- identify by name, version, type (broad category)
- Many may apply; at least one should be recorded
**dependency**
- non-software component or file needed
- dependency vs. swDependency
- e.g. fonts, schemas, stylesheets
- name and identifier
**environmentNote**
- Any additional information
- Should not be used as substitute for more rigorous description

## Environment example: ETD (PDF file)

- environmentCharacteristic=known to work
- environmentPurpose=render
- software/swName= Mozilla Firefox
- software/swVersion= 1.0
- software/swType=renderer
- swOtherInformation=requires swDependencies as plug-ins
- software/swDependency= Adobe Acrobat Reader 7.0
- software/swDependency= RealPlayer 10
- software/swName= Windows NT
- software/swVersion=5.0
- software/swType=operatingSystem
- hardware/hwName=Intel Pentium II
- hardware/hwType=processor
- dependency/dependencyName=Mathematica 5.2 True Type math fonts

## Environment registries

- Information may be complex and increasingly granular
- Information often applies to whole class of objects
- PREMIS does not assume the existence of an environment registry, but defines the information that would be needed in one
- PRONOM has some elements of environment registry
- for any file extension, gives list of software that can
- create
- render
- identify
- validate
- extract metadata from

## Digital signatures

- In a transaction, verifies the identify of the sender and that the file was unchanged in transmission.
- Some archives sign stored objects for verification in the future.
- PREMIS digital signature semantic units are based on W3C’s *XML Signature Syntax and Processing*
*de facto* standard for encoding signature information
- PREMIS adopts structure/semantics where possible
- Some departures: e.g., PREMIS permits a given signature to be a property of only 1 object.

## signatureInformation Container

*Who signed it?*
- signer (name or pointer to an Agent)
*How was it signed?*
- signatureInformationEncoding (e.g., Base64)
- signatureMethod (e.g., DSA-SHA1)
*How can we validate it?*
- signatureValidationRules (could be a pointer to documentation for the validation procedure)
- signatureProperties (additional information)
- keyInformation: the signer’s public key and other info
- Type: e.g., DSA, RSA, PGP, etc.
- Other info: e.g., certificate, revocation list, etc.
*And of course, the signature itself*

## signatureInformation example

- signatureInformation
- 	signatureInformationEncoding=base64
- 	signer=Florida Digital Archive
- 	signatureMethod=RSA-SHA1
- 	signatureValue=MC0CFFrVLtRlkMc3Daon4BqqnkhCOTFEALE=
- 	signatureValidationRules=T1=C1
- 	signatureProperties=2003-03-19T12:25:14-05:00
- 	keyInformation
- 		keyType=x509v3-sign-rsa2
- 		keyValue=<DSAKeyValue>
- 			      *keyvalue*
- 			      </DSAKeyValue>