Martin> > My question was about logic, and not about a knowledge base. We intend to > > separate these two strictly.
If you encode your ideas in OWL, certain inferences will follow in a very practical sense. I've read the paper (http://www.cidoc-crm.org/docs/OWL_formalisation_of_the_CRM.pdf). I'll wait for a concrete OWL axiomatization before making detailed comments. But here are some very brief comments: - There is no class rdf:Literals (the spelling is rdf:Literal) - E41 should not be made Literal!! E62 String should be - "E50 Date finds a natural correspondent in xsd:date. Since datatypes lie outside OWL proper"... I think that's false, see http://www.w3.org/TR/owl2-syntax/#Time_Instants. And in other places you do use datatypes - "SubClassOf(owl:real crm:E60)": I don't think you can make supertype assertions over datatypes. Here are the datatype constructs allowed: http://www.w3.org/TR/owl2-syntax/#Data_Ranges - http://www.w3.org/TR/owl2-syntax/#Real_Numbers.2C_Decimal_Numbers.2C_and_Integers: "The owl:real datatype does not directly provide any lexical forms." Which means it can't be used in practice. Instead, use xsd:decimal which is an infinite-precision number. Christian> S(x,y) => Exist z( P1(x,z) & P2(z,y) In practical terms, this will infer an unknown resource (blank node) z. Trying later to locate this blank node so you can attach more info to it when integrating richer databases... is a lost proposition. It's OWL2 itself infers many such "Skolem variables". E.g. - if you say Father is someone male who has a child, Peter is a father, and there is no child instance of Peter, then OWL semantics will infer an unknown child. - if you say Legal Objects must have at least one Right (through a restriction axiom), OWL will infer an unknown Right for each Legal object The utility of such Skolem variables was criticized strongly a 3-4 years ago the "OWL 2 Much?" seminar . > Does the implication also go in the opposite direction? Intuetivele it > should, but maybe I am wrong here. I think it should, using owl:propertyChainAxiom. Detlev> artifact A was created by agent B. If we assume that all of these > statements imply the existence of a creation event, then we have a clear > migration path in cases where additional information needs to find > a suitable representation. When you have extra info, you can make the longpath and extra node. Before you have that info, why make the node? Are you familiar with the "You are not gonna need it" (YAGNI) principle? A modern view on Occam's Razor :-) > Another use case is integrating "low-res" and "high-res" knowledge bases, > where "low-res" statements have to be translated into a more > complex representation CRM already forces everyone to make "high res" statements in many cases. E.g. you don't say "birth date" but make a Birth event, same for Production, etc. But when CRM provides a more economical representation, why LOGIC should force everyone to also use a more long-winded representation, that adds no value because it has no extra data? Integrating a "high-res" database to a forcefully-Skolemized "low-res" database is not going to be any fun. How do you locate the unknown nodes (blank nodes), and how can you be sure you're talking of the same event, so it's legitimate to merge them? The whole system of shortcuts is more complex than most people think. - *all* properties are shortcuts of E13 Attribute Assignment. ** Does that mean we should infer an unknown E13 for *every* statement? ** How about E13's own properties P140 and P141: should we reify those with E13, ad infinitum? - There are longcut chains that cross over, e.g.: P8 is shortcut of P7-E53-P87-E46-P58i P59 is shortcut of P58-E46-P87i So P87 is a common link in both: I have not analyzed what would be a consequence of that (if any)... - there are some unstated shortcuts. E.g. P57 has number of parts is clearly the result of some measurement... But what is the Type (items, volumes, pages, paragraphs)?
