legaldocml — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Re: [legaldocml] eContract in Akoma Ntoso
Dear Dazza,
it is a pleasure to hear these words.
Let me work with TC AKN on this task, and then we could organize a
list of written questions on the topic.
It could be very useful to have some examples marked up in
eContracts.
Cheers,
Monica
Il 20/03/2023 16:14, Dazza Greenwood ha
scritto:
It seems you are seeking more information about the
econtracts specification and the work of that TC.
I chaired the econtracts TC for entire 7 years of its work. If you
make a specific request, I d be happy to gather the views of
members who remain available on your question. Just send that
request to: [email protected]
Best,
- Dazza
Daniel "Dazza"
Greenwood, JD
CIVICS.com & Law.MIT.edu
Sent
from an iPhone
On Mar 20, 2023, at 7:34 AM, Jim
Cabral <[email protected]> wrote:
ï
Thanks for the explanation.
<BE3C44E1CEE944218E6EAD258C528AD5[61873648].png>
Jim
Cabral
Vice
President, Court Relations
502-640-4970
Visit
the site
Check
out the blog
Contact
us
From:
monica.palmirani
Sent: Sunday, March 19, 2023 5:36 PM
To:
[email protected]
Subject: Re: [legaldocml] eContract in Akoma
Ntoso
Dear Jim,
there is a great interest in the private sector to reuse
the legislation and the case-law digital knowledge, now
often available in AKN, for modelling and drafting
contracts. To use AKN in this area of application could
also add semantics, descriptiveness and prescriptiveness
to artificial intelligence tools (e.g., GTP-4, etc.).
During the last year several stakeholders asked to
model bank/insurance contracts, privacy policies,
license, etc. in AKN.
AKN has elementary structures for
modelling them, but now we would like to reuse the
knowledge coming from eContracts for revamping the work
inside of AKN framework and to improve the modelization
of this typology of documents with specific
tags/attributes.
Best regards,
Monica
Il 16/03/2023 01:15, Jim Cabral ha
scritto:
Fabio,
Thanks for this analysis.
Although I didn t directly
participate on this TC, I was involved with LegalXML
at the time the eContracts specification was being
developed and knew many of the authors. When I
encounter people working with digital contracts, I
usually ask them if they are using or even aware of
this specification. To my recollection, the only
group that has ever claimed to me that they use it was
a Lexis Nexis division in the UK.
I m curious. Is there a reason for
a renewed interest in the eContracts specification?
Or is this just an attempt to mine
this work as you expand the scope of Akoma Ntoso to
other legal documents, including contracts?
<BE3C44E1CEE944218E6EAD258C528AD5[61873648].png>
Jim
Cabral
Vice
President, Court Relations
502-640-4970
Visit
the site
Check
out the blog
Contact
us
From:
Fabio Vitali
Sent: Wednesday, March 8, 2023 11:55 AM
To:
[email protected]
Subject: [legaldocml] eContract in Akoma
Ntoso
You
don't often get email from
[email protected] .
Learn why
this is important
Dear all,
please find a first analysis of
the eContract XML schema (a 2006 OASIS standard of
our domain, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-econtracts
).
We have received requests as to
integrate the useful stuff into AKN. This is a
systematic analysis of the final schema. There is
little comment, as I had little time to write it.
We can discuss it in greater detail during the
call. Anyhow, most of the proposals are pretty
straightforward. The only potentially complicated
is discussed in note (16).
To
better understand the nesting please use a
monospaced font for the rest of the message.
Ciao.
Fabio
--
=================
eContract example
=================
<?xml version="1.0"
encoding="utf-8"?>
<contract
xmlns="urn:oasis:names:tc:eContracts:1:0">
<title>
<text>Sample of the
elements</text>
</title>
<subtitle>This file
is to test</subtitle>
<contract-front>
<date-block>
<date><em>Long time
ago</em></date>
</date-block>
<parties>
<party></party>
</parties>
</contract-front>
<body>
<item number="1">
<title><text>First
level</text></title>
<item
number="1.1"><title><text>Second
level</text></title>
<item
number="1.1.1">
<title><text>Third
level</text></title>
<block><text>Content under third
level with title.</text></block>
</item>
</item>
<item
number="1.2">
<title><text>Second
level</text></title>
<block><text>This is a two level
list:</text>
<item
number="(a)">
<block><text>First level list
item.</text></block>
</item>
</block>
</item>
</item>
</item>
</body>
<back>
<party-signature>
<signatory-group>
<block>
</block>
<signatory-record>
<signatory
id="T0001" xml:lang="ja">
<signature-line id="I0001"
xml:lang="en_US">
<text>Mr.
Signatory Jr.</text>
<field>Field for a text.</field>
</signature-line>
</signatory>
<witness>
<signature-line id="I0002" xml:lang="fr">
<text>Ms.
Witness Arcole</text>
<field>Field for a text.</field>
</signature-line>
</witness>
</signatory-record>
</signatory-group>
</party-signature>
</back>
<attachments>
<attachment>
</attachment>
</attachments>
</contract>
* No mixed content anywhere.
Element <text> introduces text-only
fragments everywhere (exception:
<subtitle>. Why?)
* Only one type of hierarchy
with one element (<item>).
* Numbers are attributes,
headings are elements. Why?
* Many structures acts both
as containers of simpler leaves as well as
elements in specific expected places in the
document.
* Signatures are
(pointlessly?) complicated.
* Conditional texts (see
further) require some thoughts.
============================
eContract document structure
============================
19. contract
68. title
59. subtitle
40. metadata
20. contract-front
11. background
12. block
23. date-block
22. date
45. parties
46. party
48. person-record
7. address
41. name
13. body
38. item (outside of a block)
68. title
59. subtitle
12. block
39. item (inside a block)
65. text
32. definition
64. terms
63. term
37. inclusion
61. table
10. back
12. block
23. date-block
22. date
47. party-signature
52. signatory
53. signatory-group
54. signatory-record
55. signature-line
69. witness
9. attachments
8. attachment
==========
Vocabulary
==========
eContract defines 64 elements (listed here as 7.
thru 71.) and seven attributes. The grouping in
AKN-related categories is mine. They do not group
them in any meaningful way.
Entries we can directly map
onto akoma Ntoso are annotated with (-). The rest
have a numbered reference [n] discussed in the
following.
Inlines
=======
We can divide inlines in presentation, semantic,
and structural (i.e., they are only allowed within
specific structures). In addition images and
x-include, which I will not discuss further.
Presentation inlines
--------------------
33. em (-)
49. phrase (-)
56. statutory-em (1)
57. strike (-)
58. sub (-)
60. sup (-)
(1) statutory-em is described as follows: "This is
used to mark up content that must be emphasized as
per a particular statute. Presumably, the
application program will render the contract
emphasizing the text as required by that statute.
The TC recognized this need in [Min0216]." For
statutory-em, my proposal is simply <i
class="statutory">...</i>
Semantic inlines
----------------
42. note (2)
43. note-in-line (2)
41. name (3)
7. address (3)
50. reference (4)
14. citation (4)
36. field (5)
16. conditional (6)
(2) Element note is either <noteref> or
<authorialNote>. Element note-in-line is
simply <noteref/authorialNote
placement="inline">
(3) Elements name and address are used to describe
people inside element person-record. proposal:
<person> and <location> respectively.
(4) Element reference is clearly <ref>.
Element citation is described as "the name by
which a referenced work is cited". No example is
given. I do not know.
(5) element field: "A field is a generic element
that can be used to mark up a unit of information
in the contract that is either captured from the
user, inserted from a database, generated by a
processing application such as a cross reference
tool, or extracted from the contract for other
uses, such as to populate a contract-management
database." Example given:
<definition>
<term>BNML Standard
Schema</term>
<block>
<text>means the XML Schema called
Pay <field source="ida"
name="PaymentAmount"/>.</text>
</block>
</definition>
I woud use <placeholder
refersTo="#PaymentAmount"> or possibly
<fillIn refersTo="#PaymentAmount">.
(6) element conditional is an inline text that
only appears if a condition is met. Use
<span>. For the specification of the
condition, see the discussion in note (16).
Structural inlines
------------------
22. date (7)
46. party (8)
64. terms (9)
63. term (9)
52. signatory (10)
53. signatory-group (10)
54. signatory-record (10)
55. signature-line (10)
(7) Use <date> for date
(8) We should differentiate between individuals
and organizations, and use <person> and
<organization> accordingly.
(9) we have term, we do not have terms which is
simply a grouping algorithm for individual term. I
would skip terms.
(10) Frankly I would not give a big deal of
attention to signatures. We already have them, and
have <fillIn> for signature-line.
Structures
==========
19. contract (11)
68. title (12)
59. subtitle (12)
40. metadata (-)
20. contract-front (-)
11. background (-)
13. body (-)
38. item (-)
12. block (-)
65. text (-)
10. back (-)
9. attachments (-)
8. attachment (-)
23. date-block (13)
45. parties (13)
48. person-record (13)
32. definition (13)
47. party-signature (13)
52. signatory (13)
37. inclusion (14)
69. witness (15)
(11) A contract contains a title and subtitle,
metadata, a front, a body, a back and some
attachments. We shall create a new document type
<akomaNtoso>
<contract>
...
</contract>
</akomaNtoso>
(12) We need to wrap title and subtitle inside a
container (<coverPage>), and move the
position of metadata before them. No big deal.
(13) These are specialized containers. My idea is
to ignore them, they only serve to group together
interesting inlines (date, party, signatures,
terms, etc.). At most use a <container
class="x">.
(14) element inclusion is "a generic container
element for content that is distinct from the
narrative, such as quotations, annotations, notes
and examples. It is also used to provide a title
and number on graphical objects and tables.
Typically, the inclusion element contains content
that is separate from the main contract provisions
for automatic number of layout purposes." We have
a variety of different ways to express these
needs. An hypothesis would be to use <???
status="editorial">, where ??? could be
equivalently an inline, a block, a container or an
hcontainer depending on the context. Alternatively
we could use element <scene> but it is not
available everywhere.
(15) A witness is a special type of signatory, and
therefore I would solve it with <signature
class="witness">.
Metadata
========
24. dc:contributor (-)
25. dc:creator (-)
26. dc:date (-)
27. dc:description (-)
28. dc:publisher (-)
29. dc:rights (-)
30. dc:subject (-)
31. dc:title (-)
18. conditions (16)
17. condition (16)
(16) Element conditions is a metadata element that
contains the list of condition element to activate
on the document. Each condition specifies a
condition identifier. Inside the contect, the
conditional element will refer to one or the other
of the condition identifiers, as follows:
<contract>
<conditions>
<condition name="US">United
States</condition>
<condition
name="AU">Australia</condition>
</conditions>
...
<block condition="US">
<text>A US-specific statement in the
contract.</text>
</block>
<block condition="AU">
<text>An Australian-specific statement in
the contract.</text>
</block>
<block>An unconditional block with
<conditional
condition="US">American</conditional>
<conditional
condition="AU">Australian</conditional>-specific
wordings.
</block>
</contract>
This allows to create multiple different variants
of the text depending on which condition is
active. This is my main concern: is it a shorthand
for different variants (FRBR Expressions) or is it
a single _expression_ that contains text that can
disappear? Could we just use @wId and
@alternativeTo? Would the following be
appropriate?
<akomaNtoso>
<contract contains="multipleVersions">
...
<p wId="p_15" eId="p_15US"
alternativeTo="p_15AU">
A US-specific statement in the
contract.
</p>
<p wId="p_15" eId="p_15AU"
alternativeTo="p_15US">
An Australian-specific statement in the contract.
</p>
<p eId="p_16">An unconditional block with
<span wId="p_16__span_1" eId="p_16__span_1US"
alternativeTo="p_16__span_1AU">American</span>
<span wId="p_16__span_1" eId="p_16__span_1AU"
alternativeTo="p_16__span_1US">Australian</span>-specific
wordings.
</p>
...
</contract>
</akomaNtoso>
Special Structures
==================
X-Include (17)
70. xi:fallback (17)
71. xi:include (17)
(17)
We are not going to use X-Include.
Other
=====
Table
15. colspec (-)
34. entry (-)
51. row (-)
61. table (-)
62. tbody (-)
66. tgroup (-)
67. thead (-)
Images
21. data (-)
44. object (-)
35. fallback (-)
Attributes
==========
@id (-)
@xml:lang (-)
@class (-)
@number (-)
@condition (16)
@orient (18)
@stop-contents (19)
(17) "This attribute specifies whether the element
contents should be rendered as portrait or
landscape". I refuse to even consider this
attribute.
(18) "This stops the generation of
table-of-contents entries for the elements
contained within this element." We have nothing of
the sort. Do we need it? Do we care?
Ciao
Fabio
--
Fabio Vitali
The sage and the fool
Dept. of Informatics
go to their graves
Univ. of Bologna ITALY
alike in this respect:
phone: +39 051 2094872 both
believe the sage to be a fool.
e-mail:
[email protected]
Where,
then, may wisdom be found?
http://vitali.web.cs.unibo.it/
Qi, "Neither Yes nor No", The codeless code
<page12image132452672.png>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]