Entity and Occurrence representations

benfinoradin

Has there ever been discussion of implementing support for representations of entities and occurrences? In a system that is primarily for the cataloging of works of art (as opposed to archival collections) this makes it quite difficult to allow for uploading media for entities and occurrences with the same rich records that object representations have.

Of course one could create a object type called "documentation" (with sub-types such as image, moving image, document, etc) and put materials here instead, then associate the relationship between the object and entity or occurrence - but this seems totally backwards when considering the great efficiency and usability that is afforded by object representation bundles.

For instance - why should it be so difficult to upload a head-shot of an entity? Or if my occurrences are exhibitions, events, etc why should I not be able to simply upload documentation of these right from their respective cataloging UIs?

benfinoradin

I'm realizing now that if I allow for representations in the navigation, this eliminates the need for an object type for documentation. If I can create an "object representation" that is not related to an object, and specify that it depicts (through my own ontology) a particular entity or occurrence, why call them "object representations", and why not allow the bundle in entity and occurrence UI? Seems a natural next step, with much added value.

Julia

Hi Ben. We have an attribute type called "media" (http://docs.collectiveaccess.org/wiki/Attribute_settings:_Media) that is specifically designed for use cases like the entity headshot you describe. When the media attribute is used the cataloguer doesn't want to store the headshot as a "collection" item or as a digital asset with metadata to be managed, they only care about the visual information the media provides. The reason we have no notion of "entity representations" (or "occurrence representations," etc.) as separate from and in addition to "object representations" is that in our experience users find it incredibly difficult to locate media when it is stored in a variety of different areas, especially given that our basic search, browse and advanced search is broken out by table. Because of that we support "representations" as independently navigable and autonomous from objects (and any other record type) as you've discovered. All the table terminology can be adjusted in the messages.po file of the English locale so there is no need for you to keep the name "object representations" if you want to simply call them "representations" or "documentation" or anything else. See: http://docs.collectiveaccess.org/wiki/Translations#Translating_system_terminology

benfinoradin

I have experimented with the media bundle. One would think that users find this media harder to find, considering its stark absence of any metadata. I am hesitant to use the media attribute/bundle specifically for this reason.

This is less about expanding scope, and more about making media uploads with good metadata less object-centric. If I have a video that is an interview with an artist, but my system is designed for cataloging works of art – what am I supposed to do with that interview? It is not an object representation, and therefore it has no home other than the "media" attribute ghetto.

Your above suggestion would get us half of the way there, but it is still a kludge. Let's say I implement this, and upload my interview by creating a new representation record. Now I have rich metadata for my artist's interview, but when I am viewing that artist's entity record I can not find that video. The only way to get all of the way there would be to lift the restriction from displaying the object representation bundle in entity and occurrence UIs.

In my experience, Collective Access' primary directive is to be as flexible and agnostic as possible, which is precisely why it has wide adoption across very different kinds of collections. I really do think that this re-thinking of representation records is in that spirit, and could benefit the project as a whole.

Julia

Hi Ben, you're right that CA's primary directive is to be flexible and agnostic (I like that). However, the CA data model was built with one basic assumption: the assets a user catalogs are assets that have been accessioned---a term I use loosely here to mean that they have enough value to be managed and therefore preserved and maintained. Given that notion there are assumptions built into the workflow, basically that a representation is either documentation of a collection object, or autonomous media that (because of its preservation-worthy status) should be seen as independent from (albeit interconnected with) other record types.

I think we can definitely do more to support this collection management/digital asset management hybridization. For example I think you're right that we should expose the bi-directionality of the representation x entity/occurrence/etc. relationships in the UI, especially given that the relationship can already be input on the rep UI.

In terms of simulating the object-object rep model where one appears to be part of another, that would be a much larger change and implementation would mean a not insignificant departure from the current and original base models.

Would exposing the bi-directionality of the relationships be sufficient to support your use case?

benfinoradin

Would exposing the bi-directionality of the entity/occurrence_x_object_representation relationship mean write access to the ca_object_representations bundle from the entity/occurrence UI (screenshot attached for clarity's sake)? Or would this be a read-only bundle that simply shows the relationship that was created from the interface of the respective object representation? If we are talking about the former, then this would certainly be a start.

Going the full nine yards to me, means also displaying associated media in the upper left of the (entity/occurrence) record, the same way that the object UI does. This is not in my mind a significant departure, and in fact reinforces and makes more use of what Collective Access is already encouraging out of the box, and that is establishing relationships between media and entities, occurrences, places.

seth

We could do this. There's no technical issue with it. That you're the only one to ask for it up to now means it can't be high on our todo list at the moment. If you were to develop the required extensions we'd love to see them!

akroh

I would agree with the notion that media files should be able to represent occurrences simply because it makes for a better user experience when searching a catalog that has been built using an FRBR like model. In my instance, I'm using PBcore in a media archive. I use the occurrences interface to create PBcore intellectual content (as in FRBR work/expression) records, and attach to those many PBcore instantiation records (or CA object records, FRBR manifestation/item records) since for one given work/expression, we will have multiple physical and digital formats that contain the same content, which we want to keep track of.

However, users of the front-end are interested in the intellectual information (i.e. the intellectual content record, or FRBR work/expression, or CA occurrences record) and seeing or hearing the media that represents it WITHOUT having to choose the physical object that we carry it on. For this reason, I want to be able to associate media files with occurrences. It would allow us to use CA as a collection management back-end and OPAC at the same time.

seth

Yes, and that's the difference between content management and collections management.

We're adding this feature now. I still think it's generally a bad idea to structure things like this, if you're doing collections management. But it'll be there if you want it.

akroh

There are many advantages to doing it this way. The biggest advantage is reducing the amount of redundant description that would occur by describing multiple objects that carry the same content. Most organizations will not need to do this. However, audiovisual media archives are tasked with preserving the content on the objects in their collections and this inevitably means migrating content across carriers as the physical objects degrade or create other roadblocks to accessibility.

I'm not sure what you mean by "that's the difference between content management and collections management." Do you mean that structuring things the way I described previously amounts to content management? It is only content management in the sense that the content is the substance of interest to users, where the physical object is not normally of interest (sometimes it is). However, we have to describe and track the physical objects too in order to properly manage them.

seth

Representations should be, well, representative of the objects in a collection. When you start treating representations as free standing media records divorced from an instantiation (to use PBCore-speak) you are effectively now managing pure content – video, audio images, whatever – as opposed to collections objects in your custody. Using content management patterns in a collections management system can make a mess quickly if one is not careful.

CA was intended for collections management, so we have an interest in preventing such messes. There's really nothing wrong with the patterns you & Ben are suggesting, except that for the majority of CA users they'd be a bad idea.

We would not be implementing the new relationships right now if we thought they were absolutely wrong. It'll be interesting to see what new uses (outside of traditional collections management) they make possible.

akroh

I see your point. Really I'm just using a workaround because I might not be aware of the possibility for organizing a Pawtucket page as such:

Content info from occurrence record - media representation (object 2) link to instantiation record for object 1 (format) link to instantiation record for object 2 (format) link to instantiation record for object 3 (format)

If there is a way to create this aesthetic, by "embedding" the media next to (instead of linked to) the content information (perhaps by using some sort of template) then I wouldn't want to associate the media with the occurrences.

gautier

Hi Seth, akroh and others,

I've a scope of use for occurrence representations for collections : here in France, there's a standardized way of reporting inventory inspections. To do so, I think the best way is to add inspection photos (obvioulsy object representations too) from the occurrence (object inspection report). The object-occurrence link is not the right way of doing that : occurrence (inspection) photo are all object photos, but not all object photos are occurrence (inspection photo). The natural way would be for me to add the object representation from the occurrence, and then link it to the object. But I may have missed the spot...

seth

The preferred way (for me at least) is to store inspection media (images, PDFs, Etc.) in media fields placed directly into the record.

akroh

This makes a lot of sense for the way we do things. Use photos of the physical objects to represent the object. Use a proxy file of some digitized instantiation to represent the a/v content which is described using the occurrences record. We don't really even care about the metadata of the proxy file or tracking it as long as it links to, and adequately represents the content. That information is easily retrievable anyway with tools like ffprobe, mediainfo etc.

benfinoradin

Psyched to see this getting traction. Mind bumping this thread when this is on GitHub?

seth

Yes. It will be up on Git in just a few days. I'll let you know.

seth

There's an implementation of "representations anywhere" in GitHub master. The UI for linking representations to objects has been reworked and generalized for use with any kind of record that can be related to a representation (entities, places, occurrences, collections, lots, storage locations, loans, movements, list items)

Give it a try and let me know how it works for you.

seth

akroh

Thanks Seth.

I'm testing it out right now, some things I'm noticing:

Media IS linkable for occurrences.

The media editor opens when you click on the media icon on the media user interface.

The media editor does NOT open when you click on the media icon in the occurrences record inspector.

When using the media player, the bottom left corner record ID indicates that the media is linked to the object/instantiation related to the occurrence. For instance, my file name is michaelis_0007.wav, I've linked it to the occurrences record michaelis_0007, but when you play the media, the player says it's linked to michaelis_0007_audiotape, which is the object record ID.

Not sure how/if these are related:

In Pawtucket, the objects records show links to the related occurrences record, but not the other way around.

The media does not show up in Pawtucket for either the occurrences or the object. Both the occurrences and objects records are publicly accessible and show up in Pawtucket, the media is also publicly accessible but does not show up.

Alex

akroh

Update: Now the object and occurrences records link as expected. Not sure why it didn't work at first.