Alexander: What's a content model other than a list of datastreams?

Bill: Interested in fedora CModels

Tom: And we should also talk about our "don't call it a content model" document

Lynn: We should also talk about content modeling strategies

Lynn told us about hydra content models. When hydra started out is was focused on creating content models for discrete data types (data sets, articles, etc). It evolved into more of a pattern of additive behaviors.

Matt Z. reminded us of this document: https://wiki.duraspace.org/display/hydra/don%27t+call+it+a+CONTENT+MODEL

Lynn: Fedora CModels are so you can associate behaviors with objects. We want to build up CModels that cover parts of an object. Something can satisfy both the simple object pattern and the metadata pattern, for example. We don't use disseminators much, though, and that's mostly where CModels are useful, so we haven't really leveraged CModels as much as we could be.

Hydra objects have common components (based on METS), all expressed as datastreams:
(these are on the hydra wiki too)
descriptive metadata - bibliographic / MODS
technical metadata - file formats, validation, checksums
rights metadata - access and use
content metadata - mets structmap, list of the contents of an object
provenance metadata - history

How do ruby content models relate to fedora CModels? CModels describe the gross anatomy of an object. Ruby content models describe instead display issues and exactly how an object is built.

Matt Z. explained how fedora content models work, using the hydra CModels as examples. The actual CModel XML is available in the hydra space on the duraspace wiki.

Lynn: The notion of optional datastreams is also important to us. We don't want to have to reference a different CModel if an object stores a thumbnail vs. if it doesn't.

Eddie: Hull is starting with an existing repository of objects, and they want to put hydra on top of that. All they can do is inspect their objects and determine what CModel they are. Hull also cares about creating a layer of indirection through disseminators. You shouldn't access a datastream directly, you should do it via a disseminator.

Matt Z.: But that ties you more closely to fedora, too. Also, while many CModels can be combined together, some of them will be contradictory.

Alexander: In Islandora, objects get different display based on what CModel they use. Similar use of CModels as hydra.

Bill: So every model in ruby has a corresponding CModel in Fedora?

Matt: You need a model that defines the full object. You might need 10 CModels to define an object, but in ActiveFedora, all of that is in the same model, all in the same place. You don't need CModels to use ActiveFedora.

Tom: There are some differences in the CModels that different partners are using. What MUST be there?

Eddie: content, descriptive, and rights are essential. Otherwise hydra just won't work.

Matt: You also have to assert relationships, like conforms to model, and isPartOf for tying files to an object.

Stephen: We use atomistic modeling. At the top you have first class objects that point to many different children. Can an AF model recursively walk a tree?

Matt: It could. It doesn't do that by default, though. AF gives you everything you need to interact with fedora object as fedora objects. It's closely based on how the CMA works. Anything else, you have to write the code for it yourself.

There was then a long discussion of how to handle very hierarchical tree models of objects.

Lynn: We also use explicit relationships like "isPartOf" "isMemberOf".

Matt: I also want to talk about modeling beyond just fedora CModels. The main things about fedora are the object model and disseminators. With microservices, are people discouraged from having nested directories?

Neil: No, in fact we often get objects with complex internal structure. We just want to put that in a directory with a URI.

Matt: So, in fedora we'd put all of that stuff each in its own fedora object.

Neil: I don't think we'd do that. Our storage layer is designed to hold onto things that would be very expensive to implement in that way.

Matt: How do you uniquely identify a specific file from that kind of object?

Neil: The path. The object has a unique id and then the URI of the files is that unique id + the path to that file. We don't have time to curate this lump that's been given to us. For the majority of our stuff, yes, we want the atomistic model. But for some cases, this is our only viable option.

Rick: Akubra doesn't support choosing which storage you want based on the kind of object yet, but it will. Large master files in our system that aren't accessed routinely are stored offline. At the moment we're mostly all fedora, and when we store something externally we still register it in fedora.

Neil: We do something similar, e.g. for virtual machine images.

Action item: Lynn is going to make sure that the relationship vocabulary we use in hydra is on the wiki.
Action item: Alexander is going to make an islandora content model that can display a hydra object