[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
- From: "John McClure" <hypergrove@olympus.net>
- To: "Horizontal Issues and Elements" <HORIZONTAL@LEGALXML.ORG>
- Date: Thu, 29 Mar 2001 15:14:00 -0700
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 >
- From: "John McClure" <hypergrove@olympus.net>
- To: "Horizontal Issues and Elements" <HORIZONTAL@LEGALXML.ORG>
- Date: Thu, 29 Mar 2001 11:41:55 -0700
> 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 >
- From: "John McClure" <hypergrove@olympus.net>
- To: "Horizontal Issues and Elements" <HORIZONTAL@LEGALXML.ORG>
- Date: Tue, 2 Jan 2001 08:54:19 -0700
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]