Thursday Notes

26-October-2006, Richard Jones

Outline of the day

• Look at authorisation approach as part of workflow study
• Data model
  • aggregation
  • bitstream relationships
• Concrete data model/storage
• History, provenance, audit
  • Admin, curatorial -> workflow

Morning Session

Data Model

RT proposal for data model:

...

• RJ: This works only horizontally; / RT: Structure of representations is done by the Representation Metadata package
• JD: FRBR model: work->expression model / RT: departure from current system, may be confusing
• MS: attach attributes to the Files to explain to the system how to use them
• RJ: manifest file? / JD: this enforces the concept of an external metadata representation / MS: the system requires a metadata record / MS: lifecycle management issue requires that the data is there - doesn't file embedded metadata make the job harder / JD: yes, but that's concrete level
• RT: it's too difficult to put metadata in the relevant metadata buckets.
• JD: metadata needs to be a property at each level, not a separate entity at the top level (more FRBR) see diagram 2 below
• JD: make the model map to FRBR and let that squish; JMO: FRBR may not be appropriate in our use case at every level
• RJ: can we represent the "work" by collecting Items in metadata. MS: Item is an Expression, Representation a Manifestation, File = part of Manifestation

...

This discussion has currently ceased because of an argument over where metadata "files" live. It will be returned to later

Lunch

Afternoon Session

Event Mechanism

• Model
• History
• Listener/Callback

...

• LS: what do we really want to do with the History system? Do we want to be able to publish this in the AIP?

Return of the Data Model

• Files -> Content Files to avoid confusion between logical and physical
• RT: Versioning was done via identifiers, and is therefore orthogonal to the model in diagram 2. See the below diagram for an updated model:

...

Two possible structures for storage are presented, as presented in the below diagram:

back to use cases

1) as before. see above

• Versions problem: revisions vs variants

...