The BIBFRAME vocabulary has been developed using advice on structure from a variety of sources, many conflicting, so in some cases decisions have been made that are not consistent with previous approaches. Sometimes a cue was taken from the data being modeled based on how it has been treated in the past. For example only a few classification scheme have direct tagging in MARC and many more can be input to a MARC record with a code indicating the type. Perhaps we have enough experience now to investigate whether consistent approaches can be developed so that eventually we can have a guide for adding additional elements.
One issue is how to handle a concept that needs to be typed. Some examples are the various title types, provider types, identifier types, note types, classification types, title relationship types, agent to title relationship types, and annotation types. As one can see there are both numerous and varied in scope.
The following table shows how these are currently handled. For each category some types are identified via specific property names (type-as-property) and in some cases a mechanism is then provided to designate the “other” types (type-as-value).
| Category | Type as Property | Type as Value | |
|---|---|---|---|
| Titles | The following properties are defined for different types of titles: bf:workTitle, bf:instanceTitle, bf:keyTitle, bf:abbreviatedTitle, bf:titleVariation. | bf:workTitle, bf:instanceTitle, and bf:titleVariation have range bf:Title, which has property bf:titleType which further refines the type: e.g., spine title, translated title. | |
| Providers | bf:publication, bf:production, bf:distribution, bf:manufacture, are subproperties of general property bf:provider. | General property bf:provider, and its subproperties, have range bf:Provider, which has property bf:providerRole for indication additional roles (e.g., construction, release, printing). | |
| Identifiers | Properties are defined for approximately 25 specific identifier types: e.g. bf:issn, bf:lccn. These are all subproperties of general property bf:identifier. | General property bf:identifier, and its subproperties, have range bf:Identifier which has property bf:identifierScheme to indicate additional types, for example, "publisher number', "nbn", "system number", "doi", "isbn", "ismn", "issn", "istc", etc. | |
| Notes | Properties are defined for approximately 25 specific note types:. e.g. bf:languageNote. These are all subproperties of general property bf:note. | General property bf:note, and its subproperties, have range literal so there is no other way to indicate additional note types. | |
| Classification | bf:classificationDdc, bf:classificationLcc, bf:classificationUdc, bf:classificationNlm are subproperties of general property bf:classification. | General property bf:classification, and its subproperties, have range bf:Classification which has property bf:classificationScheme for indication of additional classification schemes (e.g., International patent classification, ipc). |
|
| Work/Instance to Work/Instance Relationships | Properties bf:relatedWork, bf:relatedInstance, bf:hasExpression, plus properties for approximately 40 specific relationship types, based on RDA and MARC, are defined. | Work/Instance to Work/Instance relationship propertes all have range of bf:Work, bf:Instance, or bf:Resource. There is is no "type-as-value" mechanism provided to indicate the relationship type. | |
| Agent to Work/Instance relationships | bf: creator and bf:contributor are subproperties of bf:agent. In addition it is prescribed that relators from external vocabularies may be used. For example, relators:act (where relators: is the prefix for http://id.loc.gov/vocabulary/relators). | General property bf:relator has range bf:Relator which has property bf:relatorRole for indication of additional roles. |
Approaches
There are a number of models/approaches that could be used:
- Establish a general property and many sub-properties, as for identifiers. See example 1.
- Establish a general property whose range is a structure that has a type-as-value property to enable any type to be conveyed. See example 2.
- Employ a combination of 1 and 2. See example 3.
- Establish properties for a few of the most commonly occurring, as currently with title.
- Allow the use of any list to specify a type-as-property in its own namespaces, as currently with relators:.
Examples
Following is an example of approach 1. InstanceXYZ has an identifier, and the identifier scheme, issn, is conveyed by the property bf:issn.
Example 1. <http://example.com/xyz//InstanceXYZ> |
Following is an example of approach 2. In this case the general property bf:identifier is used and the scheme is conveyed by the property bf:identifierScheme.
Example 2. <http://example.com/xyz//Work1> |
In the following example (approach 3), the scheme is conveyed both by the property, bf:issn, and the property bf:identifierScheme.
Example 3. <http://example.com/xyz//InstanceXYZ> |
This example is the same except that a URI is supplied rather than a literal for bf:identifierScheme.
Example 4. <http://example.com/xyz//InstanceXYZ> |
Questions
- In example 3 where an identifier structure is used to represent the type-as-value, and in addition the type-as-property mechanism is employed, what guidelines are needed to clarify how the two can be used together, e.g., use type-as-value to refine the type-as-property? Provide a literal for the type-as-property? Provide a URI for the type-as-property?
- Should the type-as-value be allowed to be either literal (as in example 3) or URI (example 4)? Should guidelines say that a URI is preferred?
- If type-list namespaces are allowed, what guidelines can be developed to encourage communities to use the same lists, to improve interoperability and processing efficiency, and to encourage use of publicand well-maintained lists rather than private or local.
