Slide 51
Throughout its development history, the CRM has met other ontologies. We’ve found that we’re a little bit different from many of them. Many of these different other
ontologies lack an empirical base. One of the nice things about the CRM is that it has not been built from: “I think therefore I am”, down to deducing the existence of fairy cakes. It’s all worked from: “These are the data structures that we actually use in the discipline, let's extract from those upwards and find the things that are common across all these different sub-disciplines, different data structures that we actually use, so that we are actually grounded in real practice in our domain, in our cultural heritage domain.” Some of these others don't have that, they're just thought of from very high-level concepts and drilled down towards concrete things. Along the way it's very easy to get lost, whereas working from the conceptualisations that we use generally, we’ve got a very firm base. They tend not to have sufficient richness in the relationships in order to get the functions that we require out of it; they tend to be processed by looking at different terminologies and just processing the terminologies, so they are very good at sub-classing things, but they’re very poor at how things relate to each other, because those are not things which are encapsulated in the terminology. And they don't have any idea of what they trying to achieve, whereas we do; we’ve got a very strong idea of what we want to achieve, and it has been driven from the types of things that we want to do within the cultural heritage sector. So we have a good specification of what we are trying to achieve - interoperability in this domain - we have a rich set of relationships, and we’ve built from a strong empirical base. It does mean that we miss things out which we don't document: museums don't tend to document things like contracts; that's not actually part of the way museums work, and archives don't document contracts per se. They document the piece of paper that’s the contract, but not the content of the contract itself. So we don't have concepts that are not in the databases from our domain. But it detects content that isn’t made into lexicons, into thesauri. So we have this idea of Persistent Item because that's something that we need to explain what we actually do. It's not something where we have a list of different types of persistent item out there in the real world; we just know that Persistent Item is something that allows us to hang a whole load of stuff off in our functional requirement. So we’ve got these things because they're functionally required - we need the idea of Persistent Item to make things organised. We need an idea of a symbolic object and a propositional object in order to organise things; we don't have lists of symbolic objects and lists of types of propositional object out in our domain. But we need them in order to make types, appellations and conceptual objects hang together properly. <As for> some of the different ontologies that we've seen out there: there’s Dolce, which is from a lexical base, and uses intuition and processing of terminology. It’s a very good, theoretically motivated logical description, good foundational relationships, <but> has over-specified relationships in many very detailed modes of participation, which we find too heavy. It has a bad model of space-time, so it doesn't have the ability to talk about outer and inner bounds, it doesn’t have Allen operators and things like that. But apart from that it’s got a strong overlap with the CRM, so lots of stuff there. BFO - I can't remember what that stands for - is from a background of philosophy. It has a
very poor model of relationships, it's about classifying things and it believes the world has a deterministic underlying reality, which we don't necessarily believe. What we're
talking about is our observations of reality, not that there is some real truth. All we have is all the things that people have said about the truth, whatever that is, so we are observational-based and they believe there’s some reality out there that they're trying to produce an ontology for. It’s a nice idea, but it gets a bit scary after a while. It means that it’s very difficult to verify it, because there is never going to be any data about what they're thinking about, because it's “truth”. No databases are about truth, they’re about observations. Again, it has a strong overlap with the CRM. Then there is IndeCs and ABC Harmony, which are small ontologies: event-centric like we are, very strong overlap with the CRM and we’ve completely harmonised with them, so that the CRM has everything that they have embedded in it. We did a lot of work with the teams which were working on that, and they’ve agreed that the CRM now covers everything that they wanted to cover, they’ve stopped development and have just started using the CRM instead. Then there is SUMO, which is just lots and lots of concepts. It’s a very large, high-level set of concepts, and there’s no functional specification underneath it at all. It’s not very useful for doing stuff, but it’s a great place to get ideas – concepts that are out there.