Closed zimeon closed 6 years ago
I think we should not try to describe an object in the abstract but instead do it in terms of the OCFL properties. For a first stab, could be something along the lines of:
An OCFL digital object is a collection of zero or more datastreams and administrative information that together have a URI identifier. An object may contain a sequence of versions of the datastreams.
Do you think the definition in the discussion paper provides a good starting point?
My comment was motivated by thinking the definition in the paper is not adequate:
An OCFL digital object is a collection of files and metadata that can have a notional but largely implicitly-understood boundary: “This is the thing, and this is not the thing.” ... The object should also contain a record of the metadata that describes the origin, character, and purpose of the collection of files. ...
because:
Looking at it now, I think my https://github.com/OCFL/spec/issues/9#issuecomment-378752652 was excessively reductionist, and omits both the metadata/data distinction and log files
Is OCFL actually an AIP? Or is it a set of standards that other AIP formats can conform to, to gain compatibility and extended features? For example, what does an OCFL-compliant Moab object look like? What does an OCFL-compliant Bagit object look like? What benefits (aside from cross-compatibility) do they gain from compliance?
I know that I am putting myself on the hook to answer at least some of these questions.
I believe yes, it is a standardised form of an AIP.
@julianmorley its a specification that AIPs can conform to.
from @rotated8 its a grouping of files that represent an intellectual endeavor
An OCFL Object is a group of one or more bitstreams and their administrative information that together have a URI. An object may contain a sequence of versions of the bitstreams that together represent an intellectual endeavour.
OCFL is an application-independent specification that describes the storage of OCFL Objects in a structured, transparent, and predictable manner.
@ahankinson : Your suggested OCFL Object definition and OCFL effort specification definition seem like a great starting points.
I would be inclined to move them into the specification document.
Re. the OCFL Object definition I'd suggest a stronger "together are identified by a URI" rather than just "have". I'm not convinced about "intellectual endeavour" part for versioning, it seems that there might be many reasons for a changes in the set of bitstreams comprising an object. I don't think a format conversion is an intellectual endeavour for example, even the accretion of data in a dataset would be questionable. Is it just that the versions represent the evolution of the object?
Would it be easier to wordsmith against a PR?
If I make the PR it might be biased towards my (changing - noting that I just objected to the "have" I had earlier suggested) views ;-)
Resolved with: https://github.com/OCFL/spec/pull/25
We need a good definition for the glossary (https://github.com/OCFL/spec/blame/master/GLOSSARY.md#L2 ).