Talk:Conversion Specification

A physical "Book" in a catalog, filtered into bibframe, is shaped something like this:

Instance -> carrier volume

mediaType unmediated

a bf:Print

instanceOf -> Work

Work -> a bf:Monograph

contentType -> Text

Neither one of the types is really helpful and types don't mean certain properties exist or certain allowed values. Some of this is in the BF profiles [1] or the MARC conversion specifications [2]

The types you included are only allowed for Works - the only two subtypes that are really used for a bf:Instance are bf:Print and bf:Electronic. The other three that are specified (bf:Manuscript, bf:Tactile (aka Braile) and bf:Archival) are very rare in our data see http://id.loc.gov/ontologies/bibframe.html#c_Instance

I think perhaps you want to pick an example, which we find in the LC catalog, look at the BIBFRAME @ id.loc.gov and we can distill the important properties and values and go from there?

The types you included are only allowed for Works

This highlights the differences in approach between the two vocabularies we are trying to translate between.

@Kirkhess Firstly, you are no doubt right, and more knowledgeable about than me, about which types are allowable for bf:Work and bf:Instance.

However in Schema.org the approach is very different, with no directSchema.org mapping between bf:Work, bf:Instance, and bf:Item. Describing these in Schema.org starts from the position that they are all of type schema:CreativeWork and/or one of its subtypes.

The differences between a conceptual Work and the description of a more physical entity are handled [in Schema.org] by multi-typing (using the schema:Product type) and the use of properties such as schema:sku (for local physical identifier such as a barcode).

@sschindehette bf:Item should be multi-typed to schema:IndividualProduct (instead of schema:Product). I've always thought of bf:Instance as more aligned with schema:ProductModel but would like to get feedback from others before making that change.

This then approximates to:

• bf:Work = schema:CreativeWork
• bf:Instance = schema:CreativeWork + schema:Product
• bf:item. = schema:CreativeWork + schema:IndividualProduct + (various item-ish properties such as schema:sku)

This is further complicated (when looking down the Bibframe end of the telescope) by the Schema.org approach of identifying the type of entity (book, article, sheet music, etc.) by assigning the appropriate type (schema:Book, schema:Article, schema:SheetMusic, etc)

So, taking my example conversion specification for a bf:Instance (deliberately chosen to highlight this exact issue early on):

1. As an bf:Instance, it needs to defined as a schema:CreativeWork + schema:Product
2. The values of some of the properties required to populate a schema:CreativeWork are properties of the bf:Work that the Instance is bf:instanceOf.
3.  For example the value of the bf:instanceOf/bf:subject is used to populate the schema:about property
4. Using the same approach it is possible to derive the appropriate schema types for the entity by identifying the extra types of the instance’s associated work. Hence if bf:instanceOf/rdf:type = bfStillImage, we add the type schema:ImageObject.

In producing our conversion specification there are things we will need to to take account of, as the result of cataloguer decisions there are not simple obvious signals (such as the bf:Work also being bf:StillImage) for us to decide upon.

From personal experience, it appears that the most difficult assertion to make is that an entity is a Book. The rough consensus being that if it is not identifiable as anything else, it must be a book!  ;-).

Your above description kind of reinforces this.

Seriously though, developing mapping strategies that relate to lists as carriers.html (which is far more comprehensive than the available schema:CreativeWork subtypes); and identifying combinations of bf property values as signals is the core of what we need to do to produce a credible and therefore useful specification.

~Richard.

Subclasses for music and spoken word in BIBFRAME2

Not sure if this is the right location to ask, but it seems that BIBFRAME2 doesn't seem to differentiate between music and spoken word. At least there seems to be no existing subclasses under Audio. Is this being handled in any other way, or is this a deliberate simplification to BF2, so when describing itms with either spoken word or music they will be considered as audio class without any further specification?