Why is it a semantic fault? Because a concept doesn't literally contain anything, but you are looking for literal containment in a concept, not finding it, and claiming there's a problem with this. There is no problem, because, by definition a concept doesn't literally contain anything.
You've not made a proper distinction.
Seriously, you don't seen to understand that you're being vague. You have a concept (LI) that
is a whole bunch of other concepts including itself (because it too is a concept). It matters not one jot whether you call it "literal containment" (I suspect you're getting confused by
representation again because you can't stop thinking like a coder) or not - it contains itself in
exactly the same way as it contains
any other concept, like fried artichokes on toast or whatever.
Just having groupings of arbitrary concepts pretty much
is naive set theory, which is why you run into the problems, that you keep trying to use vague language and programming bodges to get round.
It makes no logical difference whether you call it "literal inclusion" or not.
It makes no logical difference how you might imagine implementing it. You're not going to implement it; it's supposed to be a
fundamental concept (
the most fundamental concept, apparently), not an elaborate databases replete with endless flags and programming hacks.
Nope. I made a clear distinction; internal borders are infinitesimal.
So it's not a unity at all.
The concept as you have defined it is no different than a married-bachelor, or a true-lie.
It's entirely different because it was
directly deduced from you own construct. This is a
reductio ad absurdum of your LI concept.
In fact it's virtually the same as the pretty much universally accepted proof that the number of subsets in a set is larger than the set itself, even if it is an infinite set.
The proof starts with the opposite assumption and assumes that the number of subsets is the same and we can therefore put the subsets in a one-to-one map with the original elements. The problem is that in such a pairing the element is either in the subset it's paired with or not. So what about the sunset of all the elements that are not in its paired subset?
This is the same proof that continuum infinity has a larger cardinality than countable infinity.
This, of course, will also apply to LI because the concept of all the groups of concepts in LI is going to be bigger than LI itself.
A concept is not literal. This is a category error.
A concept is a concept. I said something was "literally impossible", not that any concept was literal. What's a literal concept anyway?
It is precise enough for you to understand what I mean.
No. You don't seem to understand how exact you have to be if you're going to
prove something like this is possible.
I'm not indulging you any more in comments about me.
I'm just referring to how you are going about constructing your argument here. I'm not trying to be personal.
Your argument at this point reduces to faith that an inconsistency must be there.
No. I've been exact throughout and provided formulas where needed.
Z does not appear capable of working with categories? Do you have access to it? Can you demonstrate how it works?
Since you don't seem to be using formal category theory, not sure that it matters. I studied it a while back, there are probably tools around but you can do it in normal documents.
Anyway, that wasn't my point. I was trying to understand why you aren't being more precise, because software specifications
can be
very precise if done formally, and you don't have to go all the way to Z to do better.
CASE? Do you have access to it? Can you give a demo for how it would be used in this discussion?
That explains something. CASE -
Computer-Aided Software Engineering. It generally involves using visual models. That is diagrams that have a formal syntax that can be used to specify software systems. A good CASE tool will also do a number of automatic consistency checks. At it's simplest you can just draw the diagrams.
Last time I was involved
UML was the modelling language for almost everything, with a variant called
SysML for wider systems that involved hardware too.
Anyway, I digress. The point is that those sorts of systems help one to thing in exact terms and avoid the vagaries of English. For example, to take your previous examples: physical actions, physical events, ideas, and symbols. If you were thinking in terms of putting them on a
UML class diagram, then you'd have to think about how they relate to each other. If action
is a type of event (as I speculated), then that's an inheritance relationship, maybe something like this:
I'm not saying you should do this, but thinking in these terms helps precision.
Anyway, the fundamental problems you have are to do with saying exactly where and how your LI deviates from naive set theory (which is the simplest way of considering informal groups of anything) and how exactly you avoid these contradictions.
And your argument really does need to move away from hand-waving and ad hoc coding bodges.