Conceptual model (2.2)

“The conceptual model as declared in the FRBR-LRM is a high-level conceptual model and as such is intended as a guide or basis on which to elaborate cataloguing rules and implement bibliographic systems. The FRBR-LRM is not intended to be implemented directly as it stands.” p.5

“Most of the attributes and relationships declared are not mandatory for implementation. Should some of them be omitted as unneeded in a particular application, the resulting system can still be considered an implementation of FRBR-LRM.” p. 6

“The FRBR-LRM provides a number of mechanisms that permit the expansions that are likely to be needed in any actual implementation. Category attributes are defined for many entities, permitting implementations to create those sub-types of the entities that might be useful. Additional specialized attributes can be added for any or all entities, following the patterns provided, to cover, for example, particular resource types or to provide more details about agents.” p. 6

Advertisements

8 thoughts on “Conceptual model (2.2)

  1. Pingback: World-wide review of the FRBR-Library Reference Model, a consolidation of the FRBR, FRAD and FRSAD conceptual models | FRBR Open Comments

  2. “Previous experience in creating IFLA vocabularies for the FR family of conceptual models indicated that a highly structured document can more readily be transferred to the appropriate registries for use with linked open data applications. The context has changed since the FRBR model was originally developed, and new needs have emerged, particularly in terms of reuse of data in semantic web applications, making this step an integral part of the model definition from the outset.” p. 7

    “The FRBR-LRM is not intended to be implemented directly as it stands.” p. 5

    “The model aims to uncover general principles behind the logical structure of bibliographic information, without making any presuppositions about how that data might be stored in any particular system or
    application.” p. 5

    I find a contradiction between these statements (as well as others in the document). First, it is a conceptual model but also a “highly structure document” that “can be more readily transferred to the appropriate registries for use within linked open data applications.” The term transferred gives me pause. Then there is for use with linked open data applications. There are numerous steps to be taken between a conceptual model and the creation of a linked data vocabulary (which is what the “appropriate registries” register in this case, as FRBR uses the Open Metadata Registry that is also used by RDA). Having an RDF vocabulary as one possible goal for the LRM is not in itself a bad thing, but to assume that what is here is sufficient to be transferred to a registry in the form of a vocabulary is greatly short-sighted.

    This also contradicts the statements in the document that the conceptual model is flexible.

    “The conceptual model as declared in the FRBR-LRM is a high-level conceptual model and as such is intended as a guide or basis on which to elaborate cataloguing rules and implement bibliographic systems.” p. 5

    It may be extensible, but there is no option to use alternatives of the model as defined here. I’ll cover more of that in other sections.

    Like

  3. P. 5:
    “The model is comprehensive at the conceptual level, but only indicative in terms of the attributes and relationships that are defined.”
    P.6:
    “Most of the attributes and relationships declared are not mandatory for implementation.”

    This is shows a complete misunderstanding of what a conceptual level ERD is. If the model is comprehensive at the conceptual level, then ALL actual and possible attributes and relationships must be there. You can and must indicate if they are optional or mandatory. A conceptual model is NOT created with implementation in mind. This follows later with Logical and/or Physical models, derived from the Conceptual model.

    Like

    • The same remarks on optional/mandatory elements apply to these statements about Attributes on p. 24:

      “Attributes characterize specific instances of an instance of an entity. None of the attributes defined in the model are required for any given instance of an entity, attributes may be recorded if applicable and easily ascertainable, when the data is considered relevant to the purpose of the application.”
      “The attributes listed under each entity are representative and are not in any way to be considered an exhaustive listing of attributes that might be determined to be useful in a particular application. An application can define additional attributes to record additional relevant data or to record data at a greater level of granularity than is illustrated. Certain attributes that are important to the model or are frequently relevant in bibliographic systems are listed here. However, the listing of an attribute in the model is not intended in any way to imply that these attributes are mandatory or required for any application.”

      Like

  4. P. 6:
    “The FRBR-LRM provides a number of mechanisms that permit the expansions that are likely to be needed in any actual implementation. Category attributes are defined for many entities, permitting implementations to create those sub-types of the entities that might be useful. Additional specialized attributes can be added for any or all entities, following the patterns provided, to cover, for example, particular resource types or to provide more details about agents. Other attributes, such as the Manifestation Statement, are intended to be sub-typed according to the provisions of the cataloguing rules applied by the bibliographic agency. Many relationships are defined at a general level, again with the intention that implementations would define pertinent sub-types. The model provides a structure and the guidance needed so that implementations can introduce detail in a consistent and coherent way, fitting it into the basic structure of the model.”

    P. 24:
    “Category attributes: Apply to many entities. Serve to sub-type or sub-categorize the entity according to a typology or categorization scheme relevant to a particular application.”

    More mixing up of conceptual and physical models. On the conceptual level subtypes are described with super/subtype entities or super/subclasses, like is done with RES and the rest, and Agent and Person-Collective Agent. In Physical models this is implemented by creating a Category field indicating the type. If you want to describe subtypes on the conceptual level, don’t use attributes.
    Also, the statement “Many relationships are defined at a general level, again with the intention that implementations would define pertinent sub-types.” Is puzzling. Relationships don’t have subtypes. And what is the “general level”? I think that what is meant is that additional entity subtypes can be defined with their own relationships.

    Like

  5. P. 24:
    “Note attribute: Declared for the entity res, the Note attribute can be sub-typed to apply to any entity. Notes permit the association of unstructured information relating to an instance of an entity with that entity. The Note attribute can be implemented to accommodate information which is stored as free-text as opposed to as a specific attribute or relationship.”

    Note attributes are specifically used on the implementation level, not on the conceptual level. Unless an entity actually has a note attribute. A conceptual super entity like RES does not have a note! Also a Work does not have a note, unless the creator has explicitly made that part of the content. A person as such does not have a note. A person may have a name, a gender, a birth date, etc.

    Like

    • Agreed. A note is about the entity, not a characteristic of the entity. So this is a step into implementation that goes quite a bit beyond a conceptual model. Looking at the attributes again, I also have questions about “Context of use” and “Reference source” for NOMEN. To me these are “meta” – they are about the nomen, not characteristics of the nomen. (Reference source is defined as “A source in which there is evidence for the use of the nomen”)

      Like

  6. P: 25
    “Most attributes are repeatable”

    No, no, no! This is not MARC! If you have a repeatable attribute in an entity on the conceptual level, it signifies a relationship to another entity. You must model it as such. On the physical level you may decide to implement it as a repeatable attribute (which is what happens in MARC), for specific reasons.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s