During the 34th joined meeting of CIDOC CRM and 27th FRBR CIDOC CRM Harmonization meeting resolving the issue 276 and discussing about shortcuts and knowledge creation process the sig decided that a statement is needed about “What a knowledge base is” and how to address the inconsistencies in databases and particular in knowledge databases. We agreed that we need ways( algorithms) to isolate minimal subsets that create inconsistencies (multiple fathers) in a particular KB. Carlo will define requirements for a KB IT service.
Posted by George on 5/2/2016
So I am attaching the last draft of the text Chryssoula mentioned, which was born of Oyvind, myself and then the group discussion. With regards to ‘What a knowledge base is’, if Carlo has a starting text or pointers to where to start, I am happy to lend a hand in trying to formulate.
George's text is here
Posted by Carlo on 10.2.2016
I like the text and fully agree with it. From my point of view, a KB is simply a set of statements of some language, which is the same vision assumed by the text. So, I just added a few comments.
The vision of a KB that emerges is that of a 2-layered system:
1. the curation layer, whose individuals are the statements of the domain layer; the statements of this layer express facts about the domain statements, such as their authority attributions, their provenance etc. For that, a curation ontology is used.
2. the domain layer, dealing with the individuals of the domain of discourse and the facts that concern them, expressed in statements over a domain ontology.
We are playing with the curation ontology in our narrative system, using a bit of the CRMinf, a bit of RDF, a bit of this and a bit of that. Maybe we can pull the strings?
Carlo's text is here
Posted by Martin on 10/2/2016
I also do agree. I tried to answer your concerns in your comments.
My argument, also for PARTHENOS, is that most data come in large units
from a single authority. The individual statement on individual facts exist, are
important, but do not constitute the mass of data. It is important not only
to know for each fact it's provenance, but also the sibling facts simultaneously
believed by its source. So, marking each fact with provenance is not only
difficult, but insufficient. (I have learned this from the scholars at the Getty's
working on ULAN. They ask for instance: "Is there one source which confirms birth date and birth place,
or is birth date from another source than birth place?")
Opinions?
Martin's text is here
posted by Carlo on 11/2/2016
I guess we need an abstraction mechanism to set provenance boundaries, i.e. a kind of class which defines sameness of provenance. Maybe we can re-use classes. “simultaneously believed” seems to be an equivalence relation, i.e. a reflexive, symmetric and transitive relation that partitions the KB into non-empty, disjoint sets of simultaneously believed statements, which maybe identified with the believer. That can be managed (similarly to co-reference). If the situation is more complicated than that, i.e. “simultaneously believed” is not reflexive, or not symmetric, or not transitive, then I do not know.
Posted by Martin on 12/2/2016
In our argumentation paper we implemented such a construct. The same proposition can be believed by different actors.
So far, I think tracing provenance of knowledge by named graphs is sufficient. It does not partition the graph. We imply that one Named Graph is a set of what is simultaneously believed. We can be relatively relaxed. I have no problem to say the whole British Museum database is simultaneously believed by the team of curators as default.
In our implementation, we distinguished also the fact that an Actor believes n propositions from the believe that he believes that all n are simultaneously correct. This was to model the detection of contradictions. For a CRM KB in a first approximation, I do not think we need such subtleties. What is important is to distinguish who's opinion something is.
What do you think?
In the 35th joined meeting of the CIDOC CRM SIG and 28th FRBR - CIDOC CRM Harmonization meeting, the crm-sig discussed and accepted the proposals by Oyvind, Bruseker, Martin and Carlo. The final text is incoroptated in the version 6.2.2 of CIDOC CRM
The issue is closed.
Prato, February 2016