WIP: Object definition expansion - #44
Conversation
| An OCFL Object is a group of one or more content bitstreams (data and metadata), and their administrative | ||
| information that are together identified by a URI. The object may contain a sequence of versions of the | ||
| bitstreams that represent the evolution of the object's contents. | ||
| An OCFL Object is a group of one or more files, directories, and administrative |
There was a problem hiding this comment.
I think there is a problem including "directories" as a fundamental component of an OCFL object because OCFL doesn't actually store directories (e.g. empty dir will be ignored). It does support "files organized in directories" so maybe that could be used as a replacement?
There was a problem hiding this comment.
How about instead:
An OCFL Object is a group of one or more files, administrative information, and the directories they are organized in, that are together identified by a URI.
| <p> | ||
| A file is defined as a content bitstream that can be stored and transmitted. Directories (also called "folders") | ||
| allow for the organization of files into tree-like hierarchies. The content of an OCFL Object is the files and | ||
| directories that are stored <i>within</i> the hierarchy layout provided as part of the spec. |
There was a problem hiding this comment.
Same issue with directories as above
There was a problem hiding this comment.
but isn't this section defining what a directory is? i guess i'm not sure how you can define a directory without using the word directory, or maybe i'm misunderstanding the comment (probably this).
There was a problem hiding this comment.
I think this still has the problem that it implies directories are an element of content whereas we support them only in so much as they are where the files live. I propose following @rosy1280's suggested construction above...
The content of an OCFL Object is the files and the directory hierarchy they are organized in.
though that is pretty much redundant with the definition above. Maybe just the first two sentences of @ahankinson's proposal are enough?
| An OCFL Object is therefore: | ||
| </p> | ||
| <ol> | ||
| <li>A conceptual gathering of all files (data and metadata), folders, and their changes over time which together |
There was a problem hiding this comment.
are we calling them directories or folders? It was directories above. We should be consistent
| </p> | ||
| <ol> | ||
| <li>A conceptual gathering of all files (data and metadata), folders, and their changes over time which together | ||
| form the digital representation of a complete intellectual endeavour (i.e., content); and</li> |
There was a problem hiding this comment.
I still feel that introducing the notion of a "complete intellectual endeavour", whatever that might mean, is spurious. We also need to decide on US or UK spelling and use that consistently: endeavor or endeavour. I think I would scratch everything from "An OCFL object is therefore:" onward -- if it isn't clear from the first portion then we should fix that instead of offering a second try
There was a problem hiding this comment.
My concern with not including something like a "intellectual endeavor" (US spelling or bust) is that folks aren't going to understand what to put in an OCFL object.
We often had this argument in the early days of DPN. Some folks felt that an object was an entire collection, others felt that it was a single book, while still others package up their entire repository.
Contrast that with some of the staff here at my library who have argued that an object is a single file i.e. the PDF is an object and each TIF that makes up a page are also individual objects. The goal of OCFL -- in my mind at least -- is to say that we are putting a wrapper around the book, not a collection of books nor the individual files that make up the book nor the entire repository the book is in.
I realize this is flame war worthy, but like using US spelling, I'm willing to duke it out because I think this is an important conversation to be had.
There was a problem hiding this comment.
I don't think we should be too proscriptive about what is in an OCFL object - as long as it has enough metadata to describe itself then I don't see why there is a problem. In particular, I want to store people, places and collections as distinct objects. What about WARC files or disk images?
There was a problem hiding this comment.
Not to get us off into the weeds further, if we were to draw a parallel with PREMIS (http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf - just because I happen to look at that tody) then I think an OCFL object would map to a PREMIS digital Representation (minus the recursion)
The point about whether you have an OCFL object for a page, a book, or a set of books is entirely up to the repository and data managers in my opinion. OCFL is completely agnostic on the issue, the object is merely a set of files organized with a directory hierarchy (or not) that are managed as one lump, with versioning
zimeon
left a comment
zimeon
left a comment
There was a problem hiding this comment.
I think we need to discuss this more. I'm happy with saying file and then generalizing the definition of file, but the rest seems murky
|
Merging with caveat that this will be worked on this week. |
5 participants
Attempts to coalesce issues #28 and #30. Makes the distinction between
the 'structure' of an OCFL object, and the 'content' it contains, as per
our discussions on the editors meeting call (11.07.2018).