Models, models everywhere

Lorcan Dempsey examines the nature of metadata specifications used within the libraries, museums and archives communities. One of the distinctions Lorcan makes is between what he calls:

• "conceptual models", such as the FRBR model or the CIDOC Conceptual Reference Model; and
• the "abstract models" used within different resource description standards/specifications, such as the RDF model or the DCMI Abstract Model

One of the comments on Lorcan's post requested some clarification on the difference between these two different types/classes of model. I started to write a comment on Lorcan's post, but it got quite long so I decided to write something here instead.

The first thing to say is that I recognise that our use of terminology needs some refinement here! After all, Wordnet tells me that a concept is "an abstract or general idea inferred or derived from specific instance", so I'm not sure that the adjectives "conceptual" and "abstract" do much to help to explain the difference. And I think any model is probably by definition abstract or conceptual (Wordnet again: "a hypothetical description of a complex entity or process").

But leaving aside the adjectives for a moment, I think the key point is that we are talking about models of two different things (or sets of things).

What Lorcan calls a "conceptual model" (and what Andy Powell calls here (and following slides) an "application model") is a model of "the world" (or some part of the world) that is of interest to some community. That "interest" is usually determined by the requirement to develop a software application to provide some set of functions. So this sort of model describes what information is needed to deliver those functions. Typically it specifies what types of thing are being described, the types of relationship that exist between those different types of thing, and the various attributes of those things. Such a model is always an "abstraction", a theoretical construct: we often introduce entities in our models which have no visible analogues in the physical world (the Work, Expression and Manifestation entitiy types in the FRBR model being a good example) and we make choices about how much of the complexity of the "real world" we need to include in our model, based on what particular set of functions we are seeking to deliver (to sell me CDs, Amazon is interested in my home address and credit card number but not my hair colour or National Insurance number).

An "abstract model" like the DCMI Abstract Model, on the other hand, is a model of a class of information structures. This sort of model specifies not the set of things to be described in a metadata application, but rather the nature of the descriptions themselves. So, the DCMI Abstract Model describes an information structure which it calls a DC metadata description set. It specifies the component parts which make up an instance of that information structure (description, resource URI, statement etc) and the relationships between those components (a description set contains one or more descriptions; a description contains one or more statements; and so on). And it also specifies how an instance of that information structure is to be interpreted (a statement in a description says that the resource identified by the resource URI is related in the way specified by the resource identified by the property URI to the resource identified by the value URI (!)).

But the DCMI Abstract Model doesn't say anything about the types of resources that can be described in DC metadata description sets, or the attributes of those resources, or the relationships between them. The DCMI Abstract Model can be used with an infinite number of "application models" ("conceptual models" in Lorcan's post); and conversely a single "application model" could be implemented using several different metadata "abstract models".

I'm probably glossing over some more complex issues here, but I think the key difference is that these two classes of model are models of different things: the former specifies what types of things are being described, and the latter specifies the nature of the descriptions themselves.

Comments

[Mikael]

abstract model vs. domain model?

I think domain model is commonly used in the ontology field.

[PeteJ]

Yes, I like "domain model", and I think I've used that term sometimes. I guess Andy's use of "application model" in his presentation was an attempt to indicate the "narrowing of the scope", i.e., if FRBR is a "domain model" for the bibliographic domain, then the ePrints data model is an adaptation of that "domain model" for some subset of that domain.

But I think I'd be happy enough to call them both "domain models".

[AndyP]

I also used 'application' in 'application model' to tie in with 'application profile', i.e. an 'application model' underpins an 'application profile'.

But I'm happy to use 'domain model' if that is more appropriate.

[Jonathan Rochkind]

Thanks, that was helpful.

The terminology is indeed in need of some improvement. Neither of those two types of things seem any more or less "abstract" OR "conceptual" then the other one. But I start to see how they are two seperate things--I had noticed that the DCMI was a very different sort of model then, say, FRBR, but was having trouble getting clear what this was about. It's still somewhat confusing!

I've seen people write about how important the DCMI is for DC, and how lack of a common model filling the function of the DCMI caused all sorts of problems---I still don't entirely see THIS, to be honest. I think some specifics on what sorts of problems this lack caused would help me, but haven't been able to find them.

This stuff sure is confusing, because it's just so abstract. I think it's probably important though.

[PeteJ]

Jonathan,

I've tried to answer your question about what problems we were trying to fix through the development of the DCAM in a separate post here http://efoundations.typepad.com/efoundations/2006/11/why_an_abstract.html