OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Clause Model Submissions


Hi ,

Three solid documents from Jason and Peter-- thanks to you both for sharing this
work with us. Speaking for myself, I am very encouraged! that you Jason are
drawn to the term "topic" from the IBM schema, and that you Peter use the same
term in your submission. Looks like a consensus could emerge that that's a good,
neutral, term we could adopt. The only thing to wrangle about is whether the
element name is to be capitalized or not. Peter you also propose a "block"
element in your submission, so as to override default inline formatting for
subsequent <item> elements. That's great to me too! holding aside whether the
element name is to be capitalized or not.

I also appreciate alot! Jason's DTD survey. Although I must admit sadness that
the Data Consortium's DTD was not included in the survey. This is a DTD that was
released in Jan 2001. It is a DTD that defines two elements -- Block and
Topic -- among others. It is the DTD that I championed as a recursive solution
for the Paragraph Model, that was discussed extensively on the old LegalXML
Horizontal list from Jan 2001 through March 2001, and that we were in the
process of achieving consensus. The last note I can find on the subject is
attached and I've atttached one that talks about the difference between the two
elements, and a note about element naming conventions. For more information
about the DCN's Topic and Block elements, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf.

Meanwhile, I intend to complete the DC submission, incorporating the lessons of
the last two years.

Regards,
John







Ok, that's great -- it appears you see the <Block> and <Topic> tags as viable
candidate elements...

So would it be a fair statement that you could support the <Block> and <Topic>
elements as the basic building blocks for representing a document's structure
and semantic information? Perhaps consensus exists on these two basic elements,
including from the Australian side? Let's get this thing decided once and for
all, please!

<LegalDocument name='z'>
   <title> optionally put title of document here </title>
   <identifier> optionally put document id here </identifier>
   <blocks name='childBlocks'>
	<DocumentBlock name='Chapter'>
	   <title> optionally put title of block here </title>
	   <identifier> optionally put block identifier here </identifier>
	   <content> optionally put text and nontext here </content>
	   <rdf:Description/>
	   <topics name='childTopics'>
		<Topic name='x'>
		   <title> optionally put title of topic here </title>
		   <identifier> optionally put identifier here </identifier>
		   <content> optionally put text and nontext here </content>
		   <rdf:Description/>
		</Topic>
	   </topics>
	</DocumentBlock>
   </blocks>
</LegalDocument>

Regards,
John
Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)

For a discussion group about the Data Consortium Namespace, please
http://groups.yahoo.com/group/DCNArchitecture/join

For the latest Data Consortium Namespace Specification, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf or
http://www.dataconsortium.org/namespace/DCN150.DTD.doc or
http://www.dataconsortium.org/namespace/DCN150.DTD.htm

For the latest Data Consortium Dictionary, please see
http://www.dataconsortium.org/namespace/DCD100.pdf or
http://www.dataconsortium.org/namespace/DCD100.xml (IE5)



> -----Original Message-----
> From: Horizontal Issues and Elements [mailto:HORIZONTAL@LEGALXML.ORG]On
> Behalf Of Gabe Wachob
> Sent: Thursday, March 29, 2001 12:13 PM
> To: HORIZONTAL@LEGALXML.ORG
> Subject: Re: Paragraph Model (a solution!?!)
>
>
> A very short response to your comments.
>
> I think what you are proposing is actually not far off in theory from what
> I'm talking about. You are talking about embedding the "Structure"
> information along with the content information (using RDF), I was merely
> talking about markup in a separate section of a document.
>
> The part about annotation is well taken - that was not my main thrust.
>
> I still think that the ability to sign parts of a document separately,
> including content v. "semantic markup" (what is this thing from a legally
> semantic meaning) is important. A court may publish an opinion, for
> example, in a relatively unmarked up way (without semantic markup as to
> "holding", "facts", etc), but a third party publisher (like West), may in
> fact want to do so. Having the court's signature apply only to the text
> without the "semantic markup" would be a very good thing.
>
> I think the choice of "inline" RDF or "end-of-document" or even
> "out-of-document" markup is of less importance, but what is important is
> to use separate elements (separate content) to notate semantic structure
> and meaning (ie "this block of text is a "clause" in legislative terms),
> etc. The only drawback with the inline RDF is that signing that separately
> from the main textual content is made more difficult.
>
>         -Gabe
>



> John-
> 	You responded to the XSLT comment (which was really an aside).
> What is the thought on the main comment (primarily since it came from
> comments I believe you made probably 2 years ago)?

Gabe, thanks for reenergizing the discussion, and sorry for not being more on
point in my previous reply. I'll try again now...
Regards,
John

<snip/>
> The legalxml world is different, however, because a single document can
> legitimately have *several* logical structures. Furthermore, the
> specification of a logical structure on a document can have serious
> semantic effects (are two paragraphs a "clause" for legal
> purposes, or "two
> clauses"?) Even worse, much legal material (whether we like it or not)
> requires that some presentation information be kept just because the
> semantic (ie with "legal meaning") structure may be a point of
> argument. As
> a result, and the most troubling point of all, I think, is this
> variability
> in structure makes (in many cases), the unilateral imposition of semantic
> structure on a document fruitless, as that may be functionally equivalent
> to changing the meaning of the document itself (e.g. changing the words).
>

I agree with alot of this, Gabe. (In my stilted way) I would say that exchanging
presentation information is a requirement on par with exchanging semantic
information, because presentation is as directly relevant to the business
processes supported by the documents as is the information within the documents.

>
> If every text fragment is given an id (ID/IDREF sense)(we can even impose
> some structure like described by Jason - there is no need to throw away
> obvious structure), then we can include a separate part of the document
> which gives semantic meaning and structure to the document based on the
> IDs.

Ugh - I'm not enthusiastic about identifying text fragments in this way, ie
within the "semantic markup". While intellectually attractive, I think it's hard
to program, and would not be picked up outside of LegalXML developers. I think a
forms-based approach is more effective, e.g.,

<Block name='xxx'>
  <content>
	here is content in a block of a document/publication. This
	same structure of child elements is applicable to Topic
	elements (see discussion below).
  </content>
  <rdf:Description>
	<!-- this is an OPTIONAL element, i.e., NOT REQUIRED -->
	<!-- put elements here to *describe* the text content above -->
	<!-- these elements are, in effect, the fields of a form -->
	<!-- the form-type is that identified by the Block's 'name' -->
  </rdf:Description>
</Block>

Last summer, I had a personal discussion with Rolly about CONTRACTS requirements
that you might find as compelling as I do. Rolly painted for me a business
process by which he would

(1) indicate that a certain clause was to be placed into the contract he is
working on
(2) select a type of clause from a pulldown menu
(3) fill out a form that is specifically relevant to that clause-type
(4) see clause text generated (see Spot run!)
(5) modify clause text to suit his client's needs
(6) maybe modify the data on the form, maybe changing the generated text
(7) maybe modify the default/pre-populated values for the form
(8) maybe add new fields to the form
(9) maybe modify how the text is to be generated from the form
(10) maybe define a new form not packaged with the authoring system
(11) maybe share the form with others

Clearly, this would be a real nice thing. And that is what the DCN accommodates.
The information from the form -- documented to all as being LEGALLY
IRRELEVANT -- is stored in the rdf:Description element, ready to be extracted,
analyzed, pre-populated, sorted, whatever. It is separate from the LEGALLY
RELEVANT information. It can be added AFTER the text, or it can be created
BEFORE the text. It can be in a SEPARATE document, or in the same document as
the text.

Nick once noted that HORIZONTAL's threads discussed odd constructs that didnt
track to what he and every school-age child knows: a paragraph is about some
"topic" yet is constructed with grammatical entities like sentences and
clauses -- where was this stuff in our designs? This is what the DCN now
accommodates: a document is composed of Blocks and Topics, where Blocks are used
to represent a document's structure and Topics represent the semantic
information. Blocks can be inside of Topics, and Topics are of course found
inside of Blocks. Jason in his examples pointed to evidence that both
containments are needed.

Usually, it's not hard to discern what is a Block and what is a Topic. A
reference-able "Clause", as we've discussed it, is clearly a type of Block. A
"Disclaimer of Liability" is clearly a topic. And obviously these kinds of
blocks and topics should be recorded in a dictionary (one encoded in XML) that
is referenced by XML elements -- surely there is consensus that we don't need to
define an element for every topic mentioned in every kind of contract executed
in the world today. And I think it's (almost painfully) clear that a sanctioned,
standardized list of these names of types of topics and blocks would be a hugely
important contribution from LegalXML to the work being done to create an
e-commerce environment that reduces costs for all, one that increases quality of
legal services for all.

oops, sorry for the jag! And unfortumately, I didnt talk about a <Publication>
element, but you can find out about one way of exchanging presentation
information for a logical <Document> at
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf.

>
> Because the semantic structure is content itself, we can do
> several things:
>
> 1) Provide several different semantic structures in the document (for
> different purposes or created by different entities)

Could you describe the business process you'd like to see supported here? Sounds
intellectually interesting, but I'm having difficulty grokking this. (With
regard to "created by different entities" please see below that annotations
would likely be placed into a separate document that contains pointers to the
thing being annotated, those pointers likely being RDF-compliant).

> 2) We can have authors sign the "content" and the "structure" separately,
> allowing for authors to agree to the words, but not neccesarily the
> structure

Yeh, I suppose so, but I don't see evidence that that is done today, nor that is
required by a majority of LegalXML stakeholders in the near future.

> 3) We can provide annotations to text in the same manner as we provide
> structure.

Hmm, I'd put the annotations in a separate document, not entwined in the text.
Annotations that are made by the author herself can be placed into the
<rdf:Description> element, like anything else.

>
> Here's a trivial example (there are probably better ways to represent
> structure than I do here, but it gives you an idea):
>
> <contract>
>    <text id="text1">
>       <block id="1">I promise to give you $50</block>
>       <block id="2">You promise to clean my house</block>
>       <block id="3">I will pay you $20 before you clean, and $30 upon
> satisfactory cleaning</block>
>    </text>
>    <structure id="structure1" use="contract">
>       <consideration ref="1" party="a"/>
>       <consideration ref="2" party="b"/>
>       <conditions ref="3"/>
>    </structure>
>    <annotation id="annotation1">
>       Thats a lot for painting a house
>    </annotation>
>    <signature target="text1">....</signature>
>    <signature target="structure1">...</signature>
>    <signature target="annotation1">...</signature>
> </contract>
>
>
> The other nice side effect of this that you have *lots* of flexibility in
> how you represent the text -- you can even use MS Word's "Save as
> HTML" and
> then do a little postprocessing to get a document which is ready for this
> markup.
>
> I think you can still do everything you'd want to do in XSLT with a
> document marked up with the structure this way...
>
>    -Gabe
>
> On Sat, 6 Jan 2001 12:41:37 -0500, Daniel Greenwood
> <dan@CIVICS.COM> wrote:
>
> >John (et al),
> >This is an interesting idea.  It seems to me that if the idea
> were pursued
> >within any given workgroup (e.g. contracts, legislation, etc.), then
> >eventually we would be back at an original dilemma: "what is the block
> >called" and "what is the topic called" and then someone would seek to
> >develop a standard for that.  One thing that I really like about
> your idea
> >in the context of a "Horizontal" discussion is that it does not enforce a
> >"one size fits all" set of semantic names for each of the individual work
> >groups.  Obviously, different workgroups are servicing different problem
> >domains and should use names and semantics that are appropriate for each
> >domain.
> >Best,
> > - Daniel
> >
> >=====================
> >Daniel J. Greenwood
> >www.civics.com
> >dan@civics.com
> >=====================
> >
> >-----Original Message-----
> >From: Horizontal Issues and Elements [mailto:HORIZONTAL@LEGALXML.ORG]On
> >Behalf Of John McClure
> >Sent: Saturday, January 06, 2001 2:38 AM
> >To: HORIZONTAL@LEGALXML.ORG
> >Subject: Re: Evolution of a Paragraph Model (long)
> >
> >Hello Jason,
> >I have been reviewing some of the many posts on our friend the paragraph,
> >and am coming to the conclusion that it's important to cleanly
> separate the
> >structure from the topical content. I've demonstrated this
> approach below,
> >so you can judge whether it works for you. The names of the
> elements that I
> >am using are "Block", to represent an item of structure in a document and
> >"Topic" to represent the information in the block. As you can imagine, I
> >think it's important to allow end-users to name their blocks in a manner
> >appropriate to the context in which the block exists, for some, it is
> >"Clause", for others, it is "Paragraph", and still for others, it is
> >"Regulation". The point is that it doesnt matter too much.
> >
> >It also doesn't matter much to me if the content is indicated as
> part of a
> >block, or part of a topic that is contained within the block. It's easy
> >enough to write the stylesheets for such alternative styles of coding.
> >
> >Anyway, topics are placed inside of blocks, and blocks are allowed inside
> >of topics.
> >John
> >
> ><snip/>
> >============================================================
> >|- A clause with a title and a body
> >|
> >|        <Clause>
> >|                <Number/>
> >|                <ClauseTitle>Publicity</ClauseTitle>
> >|                <ClauseBody>A party must not make any public statement
> >|...</ClauseBody>
> >|        </Clause>
> >
> >This can be encoded in two ways. Recommended:
> >
> ><Block name='Clause'>
> >   <topics>
> >        <LegalTopic name='X'>
> >           <title>Publicity</title>
> >           <content>
> >                A party must not make any public statement
> >           </content>
> >        </LegalTopic>
> >   </topics>
> ></Block>
> >
> >OR, not recommended, but OK:
> >
> ><Block name='Clause'>
> >   <title>Publicity</title>
> >   <content>A party must not make any public statement</content>
> ></Block>
> >
> >============================================================
> >|
> >|- A clause which doesn't have a title
> >|
> >|         <Clause>
> >|                <Number/>
> >|                <ClauseBody>The Customer must pay the Service Provider
> >|  ...</ClauseBody>
> >|        </Clause>
> >
> ><Block name='Clause'>
> >   <identifier keyword='ClauseID'>1.</identifier>
> >   <topics>
> >        <LegalTopic name='X'>
> >           <content>
> >                The Customer must pay the Service Provider
> >           </content>
> >        </LegalTopic>
> >   </topics>
> ></Block>
> >
> >============================================================
> >|
> ><snip/>
> >|
> >|- A clause with a title, each subclause has its own title and body
> >|
> >|        21.     General
> >|        21.1    Agreement Subject to Applicable Laws
> >|                The provisions of this agreement (including all
> >|                rights, obligations, exclusions and limitations)
> >|                apply only to the extent permitted under
> >|                applicable laws.
> >|        21.2    Amendment
> >|                Any amendment to this agreement must be in
> >|                writing and signed by both parties.
> >|
> >
> ><Block name='Clause'>
> >   <identifier keyword='ClauseID'>21.</identifier>
> >   <title>General</title>
> >   <topics>
> >        <LegalTopic name='X'>
> >           <identifier keyword='ClauseID'>21.1</identifier>
> >           <title>Agreement Subject to Applicable Laws</title>
> >           <content>
> >                The provisions of this agreement (including all
> >                rights, obligations, exclusions and limitations)
> >                apply only to the extent permitted under
> >                applicable laws.
> >           </content>
> >        </LegalTopic>
> >        <LegalTopic name='Y'>
> >           <identifier keyword='ClauseID'>21.2</identifier>
> >           <title>Amendment</title>
> >           <content>
> >                Any amendment to this agreement must be in
> >                writing and signed by both parties.
> >           </content>
> >        </LegalTopic>
> >   </topics>
> ></Block>
> >
> >============================================================
> >|
> >|
> >|But it doesn't capture a clause like the following:
> >|
> >|        2.2     When providing Services, the Service Provider must:
> >|                (a)     comply at all times with all applicable
> >|                        laws, regulations and industry codes; and
> >|                (b)     comply with any reasonable directions
> >|                        given by the Customer that relate to the
> >|                        provision of the Services,
> >|                unless the Customer is in breach of this Agreement.
> >|
> >
> ><Block name='Clause'>
> >   <topics>
> >        <LegalTopic name='X'>
> >           <identifier keyword='ClauseID' value='2.2'>2.2</identifier>
> >           <content>
> >                When providing Services, the Service Provider must:
> >           </content>
> >           <topics name='childTopics'>
> >                <LegalTopic name='Y'>
> >                   <identifier keyword='ClauseID'
> >value='2.2(a)'>(a)</identifier>
> >                   <content>
> >                        comply at all times with all applicable
> >                        laws, regulations and industry codes; and
> >                   </content>
> >                </LegalTopic>
> >                <LegalTopic name='Z'>
> >                   <identifier keyword='ClauseID'
> >value='2.2(b)'>(b)</identifier>
> >                   <content>
> >                        comply with any reasonable directions
> >                        given by the Customer that relate to the
> >                        provision of the Services,
> >                   </content>
> >                </LegalTopic>
> >           </topics>
> >           <content>
> >                unless the Customer is in breach of this Agreement.
> >           </content>
> >        </LegalTopic>
> >   </topics>
> ></Block>
> >
> >============================================================
> >| Sometimes the text inside a ClauseBody is so long, that it is split up
> >| into two separate paragraphs for readibility.
> >
> ><Block name='Clause'>
> >   <identifier keyword='ClauseID'>2.2</identifier>
> >   <topics>
> >        <LegalTopic name='X'>
> >           <content>
> >                Failure to fulfill agreements implies dire consequences.
> >           </content>
> >           <blocks name='childBlocks'>
> >                <Block name='Paragraph'>
> >                   <content>
> >                        One company created a major problem for
> themselves.
> >                        They didn't contact the customer. The customer
> >called ...
> >                   </content>
> >                </Block>
> >                <Block name='Paragraph'>
> >                   <content>
> >                        Another customer-oriented company was
> anything but.
> >In
> >                        fact, this company created headlines in the local
> >paper!
> >                   </content>
> >                </Block>
> >           </blocks>
> >        </LegalTopic>
> >   </topics>
> ></Block>
> >
> >============================================================
> >
> >|Stage 5:  Tables, Quotations, etc
> >|=================================
> >|
> >|Lemme know if you want me to continue with this!
> >|
> >
> >yes, please do!
> >
> >Regards,
> >John
>



I'd like to suggest that whatever name is selected, it be a lower-case name. Why
lower-case? Primarily because I'd like to see LegalXML's naming conventions
aligned with ebXML's naming conventions which states that XML elements for
"entities" are to be named with a leading capitalized letter, and XML elements
for their "properties" are to be named with a leading lower-case letter. This
would yield:

<ElementX>
    <content>here is the text, with in-line elements</content>
</ElementX>

As for "ElementX", I tend to support the notion of aligning it with 'topic'. In
this context, here is the latest from XML.com on topics...

Getting Topical
By Simon St. Laurent
At the recent XML 2000 conference the XML Topic Maps (XTM)
specification made an impressive debut. Simon St.Laurent reviews
the development and prospects of XTM.

http://www.xml.com/pub/a/2000/12/20/topicmaps.html

Regards,
John

|-----Original Message-----
|From: Horizontal Issues and Elements [mailto:HORIZONTAL@LEGALXML.ORG]On
|Behalf Of Davin Fifield
|Sent: Friday, December 22, 2000 4:15 PM
|To: HORIZONTAL@LEGALXML.ORG
|Subject: Re: Element Name - Paragraph
|
|
|Rather than <Tag>, which seems overly generic to me, I prefer <Text>,
|<Content>, or <LegalText>.
|
|I agree genericness(?) is what we need to aim for, but given that we are
|dealing with a holder of content of some sort, I think we need some
|relationship back to that.
|
|Thoughts?
|
|> -----Original Message-----
|> From: Richard Himes [mailto:rhimes@ATCOURT.COM]
|> Sent: Friday, December 22, 2000 3:09 PM
|> To: HORIZONTAL@LEGALXML.ORG
|> Subject: Re: Element Name - Paragraph
|>
|>
|> > -----Original Message-----
|> > From: Horizontal Issues and Elements
|> > [mailto:HORIZONTAL@LEGALXML.ORG]On
|> > Behalf Of Steven D. Jamar
|> > Sent: Thursday, December 21, 2000 9:26 AM
|> > To: HORIZONTAL@LEGALXML.ORG
|> > Subject: Re: Element Name - Paragraph
|>
|> > I like <Paragraph> as the name for the basic, nestable
|> > container which can be contained within or which can contain
|> > other things like lists, sections, clauses, etc.
|>
|> After seeing the zoo of structural tags in this discussion, I
|> believe we
|> should consider something generic (and not loaded with meaning that
|> leads to bickering about semantics.)  For example, <Tag> could be used
|> as both a point tag and a nested structural tag:
|>
|> Point tag:
|> <Tag type="Page" id="thisPoint"/>
|>
|> Avoiding structural clashes (tag overlap) and allowing vendor-specific
|> divisions:
|> <Tag type="Page" mode="[vendor format name]"
|>      id="thisPoint" endId="endPoint"/>
|>
|> Arbitrarily nested structures:
|> <Tag type="Section" id="sectionId" name="Section I">
|>    <Tag type="Paragraph>
|>       <Tag type="subParagraph">
|>          <Tag type="line" number="1"/>
|>          ...
|>       </Tag>
|>    </Tag>
|> </Tag>
|>
|> In general, I'd recommend that subParagraph also be named "Paragraph".
|> We can tell that it is a sub-paragraph by its nested context.
|>
|> The type attribute gives the flexibility to meet the structural (and
|> semantic) needs of the author or the legal context. A generic Tag is
|> easier to structure (recursively) within the DTD.  At the
|> text level, it
|> would be a mixed content model.
|>
|> Thanks,
|> Rich
|>
|

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]