What is an OCFL digital object?

[zimeon]

We need a good definition for the glossary (https://github.com/OCFL/spec/blame/master/GLOSSARY.md#L2 ).

[zimeon]

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.

[ahankinson]

Do you think the definition in the discussion paper provides a good starting point?

[zimeon]

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:

• I think an OCFL digital object has a very well defined boundary and, like BagIt, a notion of testable completeness (how that maps to boundaries in other models is arbitrary, but out of scope)
• It omits the idea of having an identifier
• I think the description of what the metadata describes is an overreach (it should enable all of those things to be described, but they are note required.

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

[julianmorley]

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.

[ahankinson]

I believe yes, it is a standardised form of an AIP.

[rosy1280]

@julianmorley its a specification that AIPs can conform to.

from @rotated8 its a grouping of files that represent an intellectual endeavor

[ahankinson]

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.

[ahankinson]

OCFL is an application-independent specification that describes the storage of OCFL Objects in a structured, transparent, and predictable manner.

[awoods]

@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.

[zimeon]

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?

[awoods]

Would it be easier to wordsmith against a PR?

[zimeon]

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 ;-)

[awoods]

Resolved with: https://github.com/OCFL/spec/pull/25