I am taking to heart the advice not to add too much styling to a clause, since the clause might be used by others with different styling conventions (or we might change our conventions in the future).
I have a defined integrated term, which I want to render in the document as (THE “ACT”) – i.e., with “act” in bold, per our firm style for defined terms:
Rather than forcing bold formatting, I am trying to follow the advice in the help pages and use the concept “#Act,” with the associated label “Act”:
My syntax is therefore: (THE “@uppercase(#-ACT)”)
I use the “uppercase” function to make the label appear in uppercase, and the “#-” styling to prevent the word “the” from appearing within the quotation marks. This is fine, except that I cannot figure out how to get the label to render in bold as well.
In my definition styles, I have set definitions in the definitions list to show up in bold; I guess this does not apply to integrated definitions. I suppose Clausebase doesn’t know when the use of the concept label is in an integrated definition or just in regular text. Maybe there could be a way to tag this in Clausebase, i.e., to tag something in order force definition styling for an integrated definition?
You are right that the bold-style for definitions only affects the way the term is rendered in the definition list. (At some point we experimented with also showing the term in bold everywhere in the text, but then we noticed that there were so many cases where this did not make sense, so that users had to force “un-bold” terms in many places, that we quit the idea).
By the way, you can automatically render defined terms in capitals everywhere, by adapting the definitions styling --> general --> capitals style.
The best way to apply bold, is to put the ~ ... ~ in the position you want. Multiple options are available, depending on your drafting style:
This brings to mind another likely challenge with integrated definitions, particularly in a clause-oriented world such as Clausebase: one normally wants to define a term during the first use (or first substantial use). But when you assemble clauses, it’s not really possible to know which clause contains the first use, is it? The clauses don’t have (I don’t think) that degree of sensitivity to each other; if it’s possible to code at all, it strikes me as being quite complex.
This suggests moving further in the direction of using defintion lists. This has not been our firm practice so much – integrated definitions are often more convenient for the reader. But it might make more sense from an automation perspective.
Actually, this kind of functionality was present in the platform up to about one year ago. We eventually removed it for three reasons:
It had a very strong impact (about +30%) on the time it takes to interactively recalculate a complex document.
As a simple example: every time a clause is moved that contains a defined term, there was a theoretical reason that this clause would become the first clause to use the term, so that the integrated definition should be shown. But it did not stop there: eventually there were many different corner cases where we had to specially account for these integrated definitions.
It made our code base much more complex, due to all these special exceptions. At the time we removed the functionality, the code base was reduced with about 8% — for this functionality alone (!).
In theory this was a perfect solution, but in practice I found many documents where it was actually not ideal to integrate the definition in the very first instance, but rather at the second or third instance. So to actually use the functionality, you should have the possibility to manually deviate. And of course AI does not provide a certainty level beyond 80% or so, so that was also ruled out.
That being said, perhaps we can reintroduce a light-version of this feature in the future. The platform can easily tell with 100% certainty where a term is used for the very first time, so it is easy to do things like highlight that first instance or integrate a definition at that point. But I hesitate to do it 100% automatically.
