[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [courtfiling-doc] Marking up narrative text in court documents using the JXDM
Hi Rolly, Thank you for the comments and examples. I agree with you that this is a likely possibility. This was breached to an extent on the last conference call with the discussion about using the structure of: ID-Type/Category-Description \_ Qualifier to mark up the text of documents. This is a concept somewhat found in GJXDM and to an extent is used more in NIEM. I have reservations about using this concept with GJXDM and this was one of the reasons for using the stylesheet for text. In GJXDM, many of the "DescriptionText" elements have specific semantic meanings which are more similar to an unstructured use of codes than on allowing for the use of free form text. For example, in the Arizona subpoena example, "CourtOrderServiceDescriptionText" is defined as a "description of how a court order was delivered" and can be codes or free form text to describe the methods used to serve the document, such as personal service, tack and mail, or other means. Currently, Michael Alexandrou is working on marking up a full Child Support Order using NIEM 0.2.1, similarly to the markup of the Arizona documents. Using NIEM, there is a way to mark up the court order conditions by giving each an id (for machine processing), a type (for categorization), and a text (for human readable consumption) with what looks to be relatively little to no extension needed. There is also a way, with minor extension to give sub qualifiers to the court order condition, such as a time limit for reporting or an amount for payment. Using GJXDM, we had to make extensions that were akin to major surgery on the schemas to fit text that could be reused in both an automated workflow and a human readable version into the xml instance due to the areas that needed extension being located at a semantically deep path in the XML instances. This same task, so far, has been going well with the use of NIEM, due to its more flexible structure, but we are only starting out with its use. As soon as we know more if this method will work or not, we'll post some results and information from the Child Support Order. In summary, I agree with the concept and the ideas. The issues that we have run into using this method have been ones of dealing with issues with extensions. There may be extension methods that we haven't learned that may be able to correct these, but also changing to NIEM seems to alleviate some of the issues due to its structure. Have you run into any issues with extensions or otherwise in marking up the Arizona documents? Thanks, Rex -----Original Message----- From: Rolly Chambers [mailto:rlchambers@smithcurrie.com] Sent: Thursday, March 09, 2006 10:27 AM To: courtfiling-doc@lists.oasis-open.org Subject: [courtfiling-doc] Marking up narrative text in court documents using the JXDM Rex, et al. This is a long message. A while back I experimented with marking up a few simple court documents using the JXDM. I wanted to see if the JXDM XML vocabulary could be used to markup narrative text information typically appearing in printed form court documents as well as the data items that have been its primary focus. I figured if the JXDM provided reasonably adequate markup tags for the narrative text in court documents, then by using an xslt/xslfo style sheet, it would be possible to publish/display an XML court document instance marked up using the JXDM. A single XML court document instance thus could contain both marked up narrative text and marked up data elements and would satisfy both uses -- publication/display for people and data interchange/automated processing for machines. The same XML instance that a machine "reads" would be the same one that a person reads. Court documents are a mixture of both structured data and narrative text. I continue to be concerned that placing narrative text in a style sheet and placing only the structured data elements in a xml instance separates the legally meaningful narrative text information, such as an order or a waiver, from the associated data elements, such as a person's name and identifying info, the date, the case, the court, etc. Such a separation no doubt makes sense from a data-centric perspective, but it is troubling from a document-centric point of view. Assembling the contents of a human readable document from different XML sources and outputting them in a single display document for human consumption is technically viable. However, this approach raises issues in terms of information storage (how and where would all the different XML sources be stored), information integrity (how would the integrity of all the different sources and the output document be secured), and reliance on applications to correctly associate the appropriate narrative text with the appropriate data items (how would the human readable document be generated correctly if applications for associating the narrative text with the data elements become obsolete or unavailable). Placing the data elements and the narrative text into a single XML instance alleviates these concerns. Based on my initial experiment, I believe the JXDM XML vocabulary can be used to markup up narrative text as well as data elements in simple form-type court documents. The JXDM semantics work reasonably well for narrative text components as well as for data items in such court documents. Attached are five "proof of concept" XML instances (two subpoenas, two warrants, and a show cause order) marked up using the JXDM. These examples illustrate one way that JXDM elements can be used to mark up all the information contained in simple paper court documents -- both the data elements and the meaningful, legally significant narrative text. In general, I followed the process for creating JXDM document schema for IEP's. First I created a subset of JXDM elements and attributes that I wanted using the Subset Generation Tool. Then I created an extension schema for the document. As I experimented, I went back to modify the subset from time to time. I did not focus on the data modeling step for creating an IEP because that step is more important for identifying data elements in designing document schema for data interchange than for identifying text elements. The data modeling step is important -- I just didn't need to focus on it for the "proof of concept" experiment. I was more concerned with the narrative text parts of a court document and the JXDM elements available for marking up narrative text. If you are interested, I can provide the document schema I came up with. To make sure I included appropriate narrative text in the example documents, I worked from .pdf versions of paper form documents from Maricopa County, Arizona. John Messing had sent them to me a few months ago and they were simply handy for purposes of the experiment. The Arizona court document forms are substantially similar to those used in North Carolina and probably to the forms used in Georgia and other states as well. The main thing I discovered is that there are JXDM elements that can serve as reasonably adequate containers to describe the narrative text in form-type court documents such as subpoenas, warrants, etc. This means that all the information in form court documents, both data elements and narrative text, can be marked up using the JXDM and combined in a single XML instance. The data elements can be exchanged and processed by machines, and the same contents can be displayed or printed for human consumption. My results are similar in many ways to the sample protective orders that Dr. Leff and his students created a few months ago. The principal difference is that those examples place the narrative text inside XML comments, which can create issues for some XML parsers and for using xslt/xslfo style sheets to display the information, while I have placed it in JXDM elements. One implication is that during the data modeling step in creating an IEP, someone familiar with the narrative text in various form court documents should be involved to make sure that narrative text types and elements from the JXDM are included in the data model along with the appropriate data elements. This assumes, of course, that the goal is to create a document model for XML instances that will be displayed and published for human consumption as well as exchanged and processed by machines. There were some quirks. The JXDM does not permit the sequence or order of elements to be changed. Thus the better approach is to structure the information in the documents such that the narrative text comes first (e.g. "YOU ARE HEREBY SUMMONED to appear before this Court to answer the Direct Complaint at") followed by the appropriate data elements containing the designated date, time, location, etc. A few times I needed to slightly alter the sequence of the information in the printed forms to better match the sequence/order of elements in the JXDM. The variances, however, were not material. If you want more details, let me know. Regards, Rolly Chambers ----------------------------------------- This e-mail and any files transmitted with it are intended solely for the use of the entity or individual(s) to whom they are addressed and not for reliance upon by unintended recipients. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail and any files transmitted are strictly prohibited. If you have received this e-mail in error please delete the entire email and immediately notify us by email to the sender or by telephone to the AOC main office number, (404) 656-5171. Thank you.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]