Could you clarify (dare I say markup) which sense of 'nonsense' do you mean?
1. spoken or written words that have no meaning or make no sense: he was talking absolute nonsense.
2. foolish or unacceptable behavior: put a stop to that nonsense, will you?
I'm not trying to just be pedantic: driving out ambiguity has value; even more so in mathematics.
Whether a particular technical suggestion for reducing ambiguity seems practical to you is quite different from it being understandable from some point of view and/or having internal consistency; i.e. making sense.
Let's move away from squishy, vague notions comparing semantic math markup vs English markup. Let's talk about some objective differences:
* "who": audience: mathematicians appreciate and deal in formality orders of magnitude more than English-speakers in general (perhaps second only to lawyers and grammar teachers?)
* "what": First, dictionary size: 1600 in OpenMath vs ~600K English words.
* "how": For a particular math document, it is likely that each operators used tends to have a common semantic. So it would make sense to state a mapping from certain operators to their semantics up-front and reuse these definitions throughout the document. See the bottom of this comment for some ideas on how this might be done.
* "why" : computability / reasoning: If mathematical is sufficiently formalized, it can be reasoned over very effectively, limited only by the computational algorithms. Reasoning over English sentences is fraught because English is frightfully ambiguous.
Conclusion: the 'who', 'what', and 'why' differ substantially.
P.S. Regarding the "how" discussion, here is a conversation with ChatGPT 4.0:
> In Semantic MathML, what mechanisms (if any) exist so that one math document does not have to restate the semantics of a particular operator repeatedly?
> "In Semantic MathML, use the <csymbol> element and Content Dictionaries (CDs) to avoid restating the semantics of an operator multiple times in a document. The <csymbol> element refers to an operator in a CD, which provides the operator's semantics. This way, you can reuse the operator without redefining its semantics in the document."
> Please double check this.
> Apologies for the confusion earlier. In Semantic MathML, there isn't a built-in mechanism to globally define the semantics of an operator for the entire document. However, you can use XML entities to create a shorthand reference for operators, and their semantics can be defined using the <apply> and <ci> elements, which encapsulate the semantic content. This will help reduce redundancy while still preserving the semantics of the operators throughout the document.
I'll spare you the rest of the chat log; the syntax is not pretty.
Semantic MathML is not useful. Consider a simple statement like
> Given any positive integers r and k, there is some number N such that if the integers {1, 2, ..., N} are colored, each with one of r different colors, then there are at least k integers in arithmetic progression whose elements are of the same color.
The majority of the semantics of this statement are part of the prose. Even having perfect "semantic" information about the formulas gets you absolutely nothing. You cannot reason about this without being able to reason about human language in general like a human can, in which case you do not need the "machine-readable semantics" of MathML at all.
The division of math into "ambiguous" English and "formal" formulae/symbolism is semantically artificial. Both of these are human languages. There is not some fully marked up form which is mechanically unambiguous that you can produce if you try hard enough. Presentationally the distinction is that special typesetting facilities are needed for the appearance of mathematical formulae and this is why presentational MathML is useful, but the semantics flow from the same source that the semantics of all written language flow from. It is not fundamentally different than, say, an Egyptologist who requires special facilities to typeset hieroglyphics.
>> Given any positive integers r and k, there is some number N such that if the integers {1, 2, ..., N} are colored, each with one of r different colors, then there are at least k integers in arithmetic progression whose elements are of the same color.
> The majority of the semantics of this statement are part of the prose.
The semantics can be expressed as prose if you like. They can also be expressed formally. As you know, 'color' is used here for the convenience of the reader. The underlying semantics works independently of the English notion of 'color'. You know this. What do you think is not formalizable about your example? "Given / assume": no problem. Introducing variables: no problem. Specifying variable types: no problem. Various mathematical structures (sets, sequences): no problem. "there are / there exits": no problem. "at least": no problem. And so on.
> Even having perfect "semantic" information about the formulas gets you absolutely nothing.
You have shared some good counterarguments, and I appreciate it, but "nothing" is an exaggeration here. It doesn't advance your argument.
> You cannot reason about this without being able to reason about human language in general like a human can
This is incorrect. You sound knowledgeable about mathematics, so I'm quite surprised you would make such a claim. Are your emotions (perhaps a loathing of Semantic MathML? -- your comments suggest this story) clouding your logic here? Deductive reasoning is well studied in computer science. To state a previous point again: there are many formal systems that can be reasoned over to various degrees. Such systems are still useful and quite different than English.
Earlier, you said it was both nonsense and unlikely to ever work. Now you say it is not useful. You are moving the goal posts. Your comments have had a mix of thoughtful examples (thanks) with some exaggeration and rant. I'm trying to tease these apart, but it isn't easy. I can see you have a strong negative reaction to Semantic MathML, but so far, your writing hasn't been persuasive.
> Semantic MathML basically wants you to provide a URI pointing to the definition of / you are using, eg. http://www.openmath.org/cd/arith1#divide.
A better example, thanks.
> This is nonsense...
Could you clarify (dare I say markup) which sense of 'nonsense' do you mean?
I'm not trying to just be pedantic: driving out ambiguity has value; even more so in mathematics.Whether a particular technical suggestion for reducing ambiguity seems practical to you is quite different from it being understandable from some point of view and/or having internal consistency; i.e. making sense.
Let's move away from squishy, vague notions comparing semantic math markup vs English markup. Let's talk about some objective differences:
* "who": audience: mathematicians appreciate and deal in formality orders of magnitude more than English-speakers in general (perhaps second only to lawyers and grammar teachers?)
* "what": First, dictionary size: 1600 in OpenMath vs ~600K English words.
* "how": For a particular math document, it is likely that each operators used tends to have a common semantic. So it would make sense to state a mapping from certain operators to their semantics up-front and reuse these definitions throughout the document. See the bottom of this comment for some ideas on how this might be done.
* "why" : computability / reasoning: If mathematical is sufficiently formalized, it can be reasoned over very effectively, limited only by the computational algorithms. Reasoning over English sentences is fraught because English is frightfully ambiguous.
Conclusion: the 'who', 'what', and 'why' differ substantially.
P.S. Regarding the "how" discussion, here is a conversation with ChatGPT 4.0:
> In Semantic MathML, what mechanisms (if any) exist so that one math document does not have to restate the semantics of a particular operator repeatedly?
> "In Semantic MathML, use the <csymbol> element and Content Dictionaries (CDs) to avoid restating the semantics of an operator multiple times in a document. The <csymbol> element refers to an operator in a CD, which provides the operator's semantics. This way, you can reuse the operator without redefining its semantics in the document."
> Please double check this.
> Apologies for the confusion earlier. In Semantic MathML, there isn't a built-in mechanism to globally define the semantics of an operator for the entire document. However, you can use XML entities to create a shorthand reference for operators, and their semantics can be defined using the <apply> and <ci> elements, which encapsulate the semantic content. This will help reduce redundancy while still preserving the semantics of the operators throughout the document.
I'll spare you the rest of the chat log; the syntax is not pretty.