Hi Alexiev,
On 19/9/2014 12:19 μμ, Vladimir Alexiev wrote:
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.
To be more explicit about what I mean. The CIDOC CRM is an ontology,
a conceptualization of possible states of affairs in this (real) world.
The exercise we do here is to define the real world logic, and then to
control to which degree
OWL or whatever can describe it. We are not interested in "how nice what
OWL can do for me",
but what are the limits with respect to the logic we hold to assume for
the real world.
The second step will be, to define what knowing means. Standard example:
We know everybody has exactly one father (categorical), but our
knowledge (factual) is about zero,
one or many. We will discuss in the next meeting with Carlo Meghini a
quite successful theory to do that. That's a philosophical problem, not
a question of encodings.
From that, we should be able to provide more objectively justified
implementation guidelines
for certain scholarly tasks.
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)
How important ;-)
- E41 should not be made Literal!! E62 String should be
To be discussed in the meeting.
- "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.
For all datatypes with explicit lexical forms, we have the problem that
they are not complete with respect to what we want to cover with the
CRM. They represent useful subsets of the logical
forms, such as with real numbers. Here ontology in the true sense and
database schema diverge.
No simple answers possible.
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
How that? (Blank nodes are an implementation choice)
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 .
Well, such criticisms may be done under certain assumption of
implementation environments, capacities of database engines and user
funtionality, or in the confusion of real world semantics
with the latter. Not helpful without the underlying assumptions. Again,
we discuss real world semantics here.
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?
You have not understood: the question was, if the intermediate exists,
and if it is unique or not.
Not, if you materialize it.
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?
Logic doesn't force any implementation. Only utility does.
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),
Instance matching S/W.
and how can you be sure you're talking of the same event, so it's legitimate to
merge them?
That makes the difference between a scholar and a techie ;-) .
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?
Well, that's why we need a theory of knowing, and who knows what's in a
database.
That's why a database does not contain knowledge, only information.
- 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)?
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: mar...@ics.forth.gr |
|
Center for Cultural Informatics |
Information Systems Laboratory |
Institute of Computer Science |
Foundation for Research and Technology - Hellas (FORTH) |
|
N.Plastira 100, Vassilika Vouton, |
GR70013 Heraklion,Crete,Greece |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
