5 thoughts on “Metadata …”

  1. I am confused about the difference between a ‘conceptual model’ like FRBR and an ‘abstract model’ like DCMI.
    What is the difference between a conceptual model and an abstract model? Does anyone have any useful thoughts there?
    I agree strongly that getting our thoughts straight about what models ARE and how to use them, and which ones we need—followed by adopting some consensus on models—is the crucial puzzle to be solved in dealing with contemporary metadata issues, in libraries and out. I’ve been thinking about this a lot lately. It’s a very very confusing topic, so much abstraction. But that’s what makes it tough, of course.

  2. Two of your points particularly strike home for me. The first is the importance of recording the relationships between entities, and developing languages to account for them. This extends beyond the realm of traditional descriptive metadata. The various information packaging standards (METS, MPEG21, XFDU) could also benefit from standards describing relationships between metadata records, and records and content. Ontologies applicable across all these standards would be a good thing.
    The second point is that while formats/rules of description/data models may be conceptually distinct, they are in practice highly interdependent. If you want to see more radical change in bibliographic practice, you can’t change just one.

  3. Jerome: Exaclty! We need to look at the full stack if we’re ever going to get out of here alive.
    I’ve done a bit of work creating a joint model of MARC (and the culture of MARC) and FRBR within a Topic Maps Reference Model (a generic frames-based contractual model which can support any abstract or concrete model you like), and also see where models like XOBIS fits into this. It certainly creates interesting cross-sections. I’m starting to think we need to have an abstract layer that can ecapsulate the various bits better, done through an ontological layer and a generic system.
    Personally I think the whole GLAM shebang (catchy title of some report? :) have for too long relied on putting their IP into formats instead of models, which is why smaller sane models (such as FRBR, for example) is good in themselves but not good enough for what we want to do.
    I also doubt very much we’ll have a single vendor helping us out in this respect.

  4. Jonathan, Pete Johnston, one of the authors of the DCMI Abstract model has a post which addresses the difference.
    This is at:
    Among other things, he says: “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.” (The former is the conceptual or application model, the latter is the abstract model here.)
    I am putting this link here as Pete had difficulty leaving a comment.

  5. One thing that would be helpful, especially for FRBR-like systems, would be more rigorous definitions of what inference rules can be applied to the semantic networks they define.
    For example, it seems that the most reasonable interpretation of FRBR is as a non-monotonic inheritance network with exceptions.
    Also, if you’re trying to deal with complicated compound works (e.g. the versions of a number of source files used to run a simulation refered to in a published paper), it would really nice to have much more precise definitions of equivalence for expressions and manifestations. For example, in a digital setting, if two manifestations can automatically be converted into each other it would be nice to be able to infer that they embody the same expression, and conversely, that if they cannot be automatically be converted, they embody different expressions. Unfortunately FRBR is moving in the opposite direction :-(
    Ah well, there’s always the next one. Viva Mess O’ Data?
    Simon // F is to FRBR as S is to SOAP

Comments are closed.