New Intellectual content element – pbcoreObjectClass

[AllisonAnn]

I would like to see the PBCore Intellectual Content class become more accommodating to cataloguing and exchanging other types of collection objects/information (other than Intellectual Moving Image and Sound).

This could be accomplished by creating a new pbcore element “pbcoreObjectClass” with the following class types:
• Intellectual content object (moving image and sound objects) • Physical object (anything collected in which the physical format is important for historical or cultural reasons - including collectible moving image and sound) • Digital object (born digital collection items - photographs, text, etc. (not born digital moving image or sound – use Intellectual content object))

pbcoreObjectClass refers to the class of object that the item belongs to (it should not be confused with assetType). These classes could be used by local systems to determine the properties (pbcore elements and attributes), relationships, and behaviors of those classes.

[kvanmalssen]

This is an interesting idea. However, the concept of "object" is very ambiguous and is used differently by different communities. As we already have some confusion around the concepts of asset and instantiation, introducing "object" may further aggravate the issue.

I also am not sure if the proposed model align's with PBCore's. PBCore has a separation of content and carrier. In a sense it is similar to a flatter FRBR, with a rough mapping of:

frbr:Work, frbr:Expression = pbcore:Intellectual Content frbr:Manifestation, frbr:Item = pbcore:Instantiation

This isn't perfect, obviously, but that's the basic idea. So if we introduce the concept of "object" at the intellectual content level, that implies there is a specific object type. Intellectual content can be manifested as an audio object, a video, and a photograph simultaneously. That is why repeatable instantiations are useful, because you can have one per type.

I think pbcoreMediaType already supports the need here in many ways. Perhaps we could just add vocabulary to it? http://metadataregistry.org/concept/list/vocabulary_id/135.html

There is also a question of the scope of PBCore and whether we would want to extend it for more detailed description of non AV objects. Is there a lot of demand for this? Are there use cases which people find that PBCore doesn't support their needs in this area?

[AllisonAnn]

I think that without at least thinking about a Physical Object Class as a possibility, we may exclude people in the museum, collector, and natural history communities from potentially using this schema for data exchange (including those who collect rare sound and moving image media).

Currently, pbcore and FRBR work well for published/reproducible intellectual content-based material in which the physical format and concept of "original" is not essential to describing the work. However, for unique, collectible, rare material, the physical format is an integral and essential part of that objects description.

Again, I think pbcore has a lot of potential to meet the needs of all communities (library, archives, museums, etc.). But without considering a pbcoreClass for physical objects at the Intellectual level, we are essentially boxing ourselves into a strategy that forces collectors of unique, historical, natural, or culturally significant physical material to adopt a schema that basically splits the information about their items into both a parent (intellectual content) and child (instantiation) record, and essentially places the original object in the same category as any additional surrogate items representing it.

My opinion is that the physical format for unique and collectible items needs to be retained as parent information to any surrogates/instantiations that are made from (or for) it. Allowing people to use a pbcoreObjectClass = Physical Object to describe collectible, physical objects at the Intellectual content level would accommodate this philosophy very easily, and allow for all types of items (intellectual content and physical) to be successfully aggregated, searched, and delivered using a single schema. In addition, the ObjectClass differentiation could allow system developers a means to inform their system how these two classes of objects need to be represented and/or behave (which would be slightly different).

So, I really think it would be great for us to think about opening up pbcore this way to other communities which might be looking for a way to manage their physical and digital, original and surrogate collections in a more flexible and robust way. I welcome more opinions about it.

[awead]

I'm a little on the fence about this. While I find the idea appealing, I think we need everyone in the PBCore community to identify this as a direction in which we want to go. I don't know enough to say one way or the other. Historically, it seems that the schema isn't interested in this. The thing I find the schema does best is describe media content with multiple representations, hence the parent intellectual object and child content object. This is ideal for a production shop, but a cultural institution is going to have a different set of needs. However, I don't think the current schema model restricts someone from a cultural institution to providing that kind detail should they require it, it's just not not necessarily modeled in a suitable way. For the schema to be successful, I think it needs to clearly articulate what is does and doesn't do. Maybe it's clear about about former, but not so much on the latter? My own belief (currently) is that the only way out of this predicament are custom ontologies created using well-defined existing schemas, expressed using RDF. That way, you could mix, say, EAD terms and structures, with PBCore, VRA, etc. and have your cake and eat it too.

[laurensorensen]

Hi all - +1 to Kara's assessment - I think one of the attractive features of PBCore to users who are new to cataloging is the simple data model, separation of content and carrier for media items.

I like the idea of improving the pbcoreMediaType vocabulary as an alternate solution.

If others feel strongly about this, we could reach out to museums and other communities who collect physical objects in addition to using PBCore to see if this would be a need to them. I can also mine the survey a bit if needed.

Here are the list of goals the PBCore steering team felt were in scope for schema: 1) A guideline for cataloging or describing audiovisual content (as a content standard) 2) A model for custom database/applications 3) A guideline for identifying a set of vocabularies for fields describing av assets 4) As a data model for a configurable collection management system (Omeka, Collective Access, etc.) 5) A guideline for creating inventory spreadsheets 6) As an exchange (import or export) mechanism between applications

[AllisonAnn]

Sorry – but I'm just not ready to give up on this idea yet. I'm enthusiastically persistent, if nothing else. However, I've come to the conclusion that we may only simply need one new class - Physical Objects. Born digital objects (digital photographs and digital art objects) could be treated as Intellectual Content objects.

Just to be clear - I'm not proposing that we create any controlled vocabularies or authorities for physical objects – there are plenty of vocabularies already out there that can be recommended for use with assetType and/or other existing elements in the schema. And I want to assure people that the new proposed class would adhere to the existing pbcore Intellectual Content/Instantiation model, and would use the exact same pbcore elements/attributes as the Intellectual Content class. The only exception would be the addition of DC: format and DC: dimensions elements that would be available to the Physical Object class, but not to the Intellectual Content class.

The new class would work to make pbcore more flexible and accommodating to additional types of objects/collections, as well as to different perspectives about what constitutes a "work," and how original and surrogate resources should be structured in a system. Again, people could still choose to catalogue their media as Intellectual Content/FRBR. Nothing would change in that respect, except for pbcore's potential for managing, searching, and exchanging more types of objects/collections regardless of class, type, status, or cataloguing perspective.

I hope that helps clarify why I think we could use a Physical Object class. I'm also happy to talk with others in the museum community, to get some feedback as well on this. Thanks all.

[AllisonAnn]

For further reading about this issue - google "CIDOC FRBR" to see what international efforts are already underway, to propose a solution to the issues I've raised. Here is a Wikipedia entry that sums it up:

https://en.wikipedia.org/wiki/FRBRoo

[AllisonAnn]

Regardless of whether or not we adopt a Physical Object class, I'd also like to recommend that all (or select) DC: Resource type terms be used in tandem with all Class elements as a type vocab (Intellectual Content, Physical Object, and Instantiation(Digital/Physical) classes).

Maybe like this:

<pbc: objectClass type="Intellectual content" source="PBCore" ref="" version="" annotation="">
    <pbc: resourceType type="movingImage" source="Dublin Core" ref="" version="" annotation=""/>
    <pbc: resourceType type="Film/Video" source="local" ref="" version="" annotation="Classification"/>
</=pbc: objectClass/>

<pbc: objectClass type="Physical Object" source="" ref="PBCore" version="" annotation="">
    <pbc: resourceType type="image" source="Dublin Core" ref="" version="" annotation=""/>
    <pbc: resourceType type="Photographs" source="local" ref="" version="" annotation="Classification"/>
<pbc: objectClass/>

<pbc: instantiationClass type="Digital Instantiation" source="PBCore" ref="" version="" annotation="">
    <pbc: resourceType type="image" source="Dublin Core" ref="" version="" annotation=""/>
    <pbc: resourceType type="Photographs" source="local" ref="" version="" annotation=""/>
<pbc: instantiationClass/>

Using Resource type in this way indicates to the user the higher level nature of the object/instantiation. As a repeatable element, it could also be used to hold local classification terms for how people are naming/organizing/searching their collections internally.

Asset type/Media type can then be used to indicate the more specific/narrow type term/vocab for the asset/item.

[AllisonAnn]

I'd like to revise my last suggestion above regarding resourceType for use with the Intellectual content and Instantation classes.

It might be more effective (and less of a radical change to the existing pbcore model) to create a resourceType element only for the Intellectual Content/Physical Object (parent) class, and use the existing mediaType element (in place of resourceType) with the InstantiationClass. Then, within the Instantiation document, instantiationPhysical or instantiationDigital can be linked to other vocab lists, to more narrowly/specifically define they type of object being catalogued/described.

<pbc: instantiationClass type="Digital Instantiation" source="PBCore" ref="" version="" annotation="">
    <pbc: mediaType type="image" source="Dublin Core" ref="" version="" annotation=""/>
    <pbc: mediaType type="Photographs" source="local" ref="" version="" annotation=""/>
<pbc: instantiationClass/>