I'm very happy to have you here and I'm thankful for the opportunity to learn.
I agree that the article should be much more explained. Your points help me to recognize where I need to put more emphasis.
The mathematico-logical background needs expanding some and needs to be a bit more coherent about the solidity it confers to the principles of what you're aiming to do with rules.
right, nothing is rigorous there, and I may assume a wrong assumption that the expert reader see it all. I think my next answers will shed some light for you:
The section on RDF is a bit loose but that may be just a linguistic challenge (you describe the components of a triple/quad as “words”, which they certainly aren't).
it's both true in formal language formalism and makes sense to the common reader
I'm passingly familiar with EulerGUI and I'm somewhat surprised at your choice (as opposed to Protege, by contrast). It is (unfortunately) ill-resourced and has fallen behind the curve. I note that they claim to support FuXi, which is going back about five years now.
Chime has no current plan to take Fuxi forward and so it is now sadly confined to either the
‘layercake’ frozen Python 2.6/RDFLib 2.4.1 package or
my now-obsolete port for use with RDFLib>=3 (pre SPARQL 1.1). FuXi doesn't work with gromgull's SPARQL 1.1 implementation and isn't likely to without a major refactoring that Chime has no intention of doing, aiui. So, for any forward-looking project, FuXI isn't really a viable option.
Existing tools are only for the beginning. I see the next versions to be SMT solvers based and such. BTW, HunterMinerCrafter and myself (but mainly him) made some advancements on SMT algorithms (If it interests you please join the IRC channel).
I'm very aware of the fact that not everything is efficiently solvable, and the reasoner won't answer all your questions. But, and that's a big but: the network will. How? Either human or machine. Is it a problem to offer Clay prizes over this network, so when the proof is verified, they automatically win the prize?
Some reasoning will be done by the local client, some by other strong computers (""miners""), some by humans, and some will never be solved.
I won't comment on cwm's functionality. aiui, it remains timbl's personal code sandpit and I'm not even sure it's officially maintained. I believe it's not compatible with Python 3 which is not necessarily a show-stopper in itself but that must blight its candidacy as underpinning reasoning technology for any ambitious new project, just in terms of executing in anything less than a geological timescale.
Even in my worst dreams I don't see a release of mine in python
it is only for the quick beginning of the formation of the rules. This is where the big questions are!
I severely doubt that everyday users will be comfortable using Attempto --- I'm fairly sure that successful use requires users to undergo a significant amount of training. You're correct in that it's the only game in town but whilst that might be adequate for research purposes, I question whether it's suitable for imminent deployment - if you can't find at least a handful of successful real-world deployments, I suggest your reconsider the whole NL aspects of the tauchain project with an emphasis on checking what's currently actually feasible and not just researchers' fond imaginings.
I definitely do not expect Attempto to understand Wikipedia. It should be looked like an "easy" programming language.
On the NL side, I did explore Quepy's NL features in relation to a semweb project that I'm currently pursuing. The project's domain of discourse is the re-presentation of transparency information otherwise ineptly published by the UK Parliament (c.f.
owl-o-parl.org) and the Quepy exploration was oriented thus.
I published a
write-up of my Quepy investigation which I shall hesitantly recommend to other readers of this thread in that they might find it accessible and gain some illumination on RDF, etc.
Gonna read now!