I’ve a maturing idea regarding a knowledge store.
For the purposes of this question, the store would be used by a police force for the recording and querying of crimes. I believe that historically, police forces used to hold vast index card systems, allowing cross-correlation and querying.
The knowledge store would contain a collection of known facts, collated in a way that supports unknown future questions.
Obviously if I knew the future questions “how many crimes this month”, “what tool is most commonly used for breaking and entering” it would be fairly straightforward to store, collate, and present the data.
My requirement for unknown future questions presents the problem.
I imagine a series of authors collating details of crimes. They’d submit details, making heavy use of relationships: “crime occurred in the evening”, “burglar used a brick”, “crime committed by Person_A”. The when considering a crime, the user would enter “brick” and be presented with collated knowledge related to that concept.
- frequently used at night
- frequently used in opportunist burglary
- frequently used in in assault
- most common entry object used in Neighbourhood D
- most used object by Person_A, Person_B
The user would then browse/wander through the information set learning more about past crimes.
The underlying information store seems close to that in a Graph Database – but I don’t want to “sleepwalk” into using one of those if there’s a more natural, AI based solution that not only solves the storage/retrieval problem but which also provides expert-system style deductions.
Description Logic is fine for this job. So using OWL and a reasoner is a good approach. In a simplified explanation, OWL full is almost as powerful as first order logic and so you won’t need more. The question is which OWL version is suitable for your task, e.g., powerful enough and at the same time very efficient for interference with a reasoner.
Take care that using OWL and a reasoner is still a young topic. The tools seem to me a bit like in beta. (hard to find up to date information. you cool tool can be discontinued in 5-6 months). You will need to be very familiar with logic (first order and description logic) to make anything that will work. just a warning 🙂
Prolog is not so popular any more (unfortunately so or not?), so I guess it is harder to find up-to date material and tools for Prolog for this task. (although Prolog is very good! really!)
EDIT regarding comment:
Running queries on relations is not so interesting, as it is not a big improvement over relational data bases. RDF and sparql is just a a nice way to combine different sources of data around the web.
Her is one example in pseudo logic/code:
Forall x element burglers :
used_brick(x) and left_fingerprints(x) => opportunist_burgler(x)
(the above rule would be stored in some OWL format)
So if a burgler used a brick left fingerprints, this implies that he is a opportunistic burgler.
So if your data store has the following information:
used_brick(john).
left_fingerprints(john).
then you run your OWL reasoner (e.g., at night if you have a lot of data).
this will result in the following data being added to your data store:
opportunist_burgler(john).
Now if you query your data set “give me all opportunist burglers”, as a result “john” will pop up. In your data set, it is not stored that ‘john’ is a opportunist, this is inferred from you OWL rules.
Now you can solve the same problem in the statistic software R, and use descriptive statistics as well as statistics test, e.g., clustering, principal components, anova, etc., and hook the R software to your web app. Then you could also use ‘Bayesian interference’ and ‘Bayesian graphs’ in R, and this would be closer to artificial intelligence the other options. But the maths behind it is quite difficult.
2
Sounds like a job for Prolog
If you decide to implement this system using Prolog, then this article will help you with choosing an appropriate data store. It dates back to 2002 but Prolog has been around a lot longer than that so the information should still be useful.
4