Semantic code project: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
Line 4: | Line 4: | ||
Standard propositions will be coded with a “c-” and you can find a complete list of the formats here: | Standard propositions will be coded with a “c-” and you can find a complete list of the formats here: | ||
<categorytree mode="pages" namespaces="Template" depth="0">Template propositions</categorytree> | {{subtable:'''Canonical propositional forms''':<categorytree mode="pages" namespaces="Template" depth="0">Template propositions</categorytree> | ||
Completed propsitions:<categorytree mode="pages" namespaces="Template" depth="0">Containers</categorytree>}} | |||
The idea is you take an existing Template proposition and “subst” it into a new structure as per the below. Ho | The idea is you take an existing Template proposition and “subst” it into a new structure as per the below. Ho |
Revision as of 20:57, 2 January 2021
Create (or select) a standard proposition
Select a standard proposition. These are things like “right” or “obligation” or “condition precedent” — basically the standard building blocks of a legal contract. My hunch is that a limited number of these “canonical propositions” could be used to apply to most contractual provisions without amendment. For example a “definition” is fairly straightforward: there is a “term” and a “definition” and an “operator” (which almost always “means” or “includes”). This can be represented as:
|
Standard propositions will be coded with a “c-” and you can find a complete list of the formats here:
{{subtable:Canonical propositional forms:
Completed propsitions:
}}
The idea is you take an existing Template proposition and “subst” it into a new structure as per the below. Ho
If there isn’t one, create a new one — but note, the name of the game is to have as few “canonical” propositions as possible. The form should be:
Name: t-[NAME]<noinclude>{{c|Template propositions}}</noinclude> |
Note:
- Change [NAME] and {VAR1}, {VAR2} and {VAR3} to suit your proposition. Note ALL ARE CASE SENSITIVE. Suggest using only lowercase. Bear in mind the command calling the template also has to be case-correct.
- “Label” above is fixed text and will help in correctly taxonomising. Don’t change this. Also leave <noinclude>{{c|Template propositions}}</noinclude> as is — this adds the template to the correct category and helps you to find it later.
Create a corresponding proposition in your agreement schema
You should have an agreement schema (a structured skeleton of the agreement in question. This has a unique taxonomised template name following this format: [Code] [Agreement] [Edition Year] [Clause reference]. For example, Section 1(a) of the 2002 ISDA is {{Code 2002 ISDA 1(a)}}
Create the new template (e.g. {{Code 2002 ISDA 1(a)}}) and call the template proposition using the “c-” template operator. For example, to: if you want to put an “application” operator in {{Code ISDA 2002 1(a)}} template, insert: {{c-application|ISDA 2002 1(a)1}} there. Note the 1: this is to distinguish between different instances of “application” that appear in clause 1(a), so not necessary if only one, but good practice.
If there is not an existing container, this should prompt you for a bunch of inputs which are not there yet (eg {{{label}}}, {{{action}}} etc).
Render
You choose your rendering by the parameter “format” in the “c-” template.
- pr means “proposition”: this is the inputs into the proposition listed as they are.
- se means “semantic”: This is the inputs into the proposition constructed into minimal English
- std means “standard” legal English: so idiomatic, but not legalese, but not so spartan so as not to be fun.
- pomp means “pompous” and we have had a bit of fun with this.
To do
Devise a proposition labelling taxonomy, that can neatly (and predictably) cover: proposition type, agreement type, location and clause reference