[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: [legalxml-econtracts] Draft Minutes - August 20, 2003 Meeting]
Even though this is about litigation and contract creation, it touches on the rules, offer-pending-final offer constructs we have discussed. It is very interesting becasue Laurence Leff had done some very progressive work with ebXML. I think this may be worthy input to us thinking about negotiation (if not speaking with Dr. Leff). Thanks. -------- Original Message -------- Subject: [legalxml-econtracts] Draft Minutes - August 20, 2003 Meeting Date: Thu, 04 Sep 2003 07:35:04 +1000 From: Jason Harrop <jharrop@speedlegal.com> To: legalxml-econtracts@lists.oasis-open.org Posting on behalf of Dave. Draft Minutes August 20, 2003 Meeting Folks, Apologies for being so belated with the minutes. I hope that people still have time to review them before the meeting tomorrow. I'll look forward to talking with everyone then. In the meantime corrections, clarifications, and additions are, as always, most welcome. Best, Dave Dave Marvit Special Projects Consultant Fujitsu Labs of America -------------------------------------------------------- OASIS LegalXML eContracts Technical Committee August 20, 2003 Conference Call. Summary: - Dr. Leff Presents on electronic legal document interoperability tests and automated determination of summary judgments. - John Messing briefly brings up MISMO as something for us to be aware of. --------------------- The following were present: Dan Greenwood Jason Harrop Dr. Leff Dave Marvit John McClure John Messing Peter Meyer Zoran Milosevic Dan brings the meeting to order: Review and discussion of today's agenda John McClure moves to accept the minutes. Jason seconds. Discussion on the minutes (none) Minutes pass unanimously. -- Dr. Leff presents: Dr. Leff: A bunch of WIU students worked on an exercise in interoperability of a bunch of OASIS standards. EBXML collaboration protocol agreements, messaging headers, etc. We assumed that people were sending back and forth P.O.s using UBL. Let's assume that these transactions need to go to court. Then we need to use the court documents standard. How do we go from these documents into various court documents? We also tried to use some other documents to simulate litigation. The example was that a seller sent the goods but buyer didn't pay. We connected all of these, using the lingua franca of an electronic standard. We used a standard that was an old standard that was generated at MIT by myself, Dan G., and others. They used at least 7 or 8 standards and demonstrated interoperability. They achieved fairly robust interoperability. Jason: What is the input and what is the output? Dr. Leff. There are 2 sets of rules. The e-commerce rule set is one. It looks at EBXML SOAP message headers, the messages themselves -- P.O. and P.O. acknowledgement -- a collaboration protocol agreement standard and an EBXML business process specification. There are also some affidavits that show up. Then the rules churn and if everything matches. The names need to match up etc. We assume that there is some system out there that will look at a signature and checks to see that the signatures match. On the litigation side, the electronic commerce set generates the contract. Then the litigation rule set looks at the initial complaint, the various motions, and any affidavits. The output is a judgment. (The person does or does not deserve a summary judgment) In e-commerce there are 2 responses that come back. The first is that I received the P.O. and it is valid XML etc. Then there is a response that human has seen the PO and it is OK. There are 2 deadlines and the software is designed to deal with both. Jason: Assuming that the contracts has been generated by the ecommerce rule set, and you want to apply litigation rules, aren't there real world facts that need to be considered? Dr. Leff: Both sides will assert facts in affidavits. If the affidavit is not contradicted then the summary judgment proceeds. It looks for one affidavit being there and one not. If there are contradictory affidavits then it needs to be judged by humans. Jason: You can apply the facts to the contract and the outcome may be a summary judgment. right? Dr. Leff: Yes Jason. The first thing is that you need to provide the contract. That method by which you generate the contract can be separated form the way the judgment is made. Dr. Leff Yes. And that is what we did. Jason: So what is important for THIS group is that you can extract info from the contract to do the analysis. Dr. Leff: Right. John Messing: The facts that are being looked at. they are parsed out of the contract parameters? Dr. Leff: Some, but others come out of the affidavit. There may be others John Messing: But all of the fact that you are considering are related to the contract? That is a tremendous oversimplification of the process of determining a summary judgment Dr. Leff: I acknowledge that this is an exercise and by no means complete. John Messing: The standard for summary judgments is weather or not there is a triable issue of fact. Inferences from the facts requires associative reasoning. That's inductive reasoning that seems to require a context of human knowledge. Dr. Leff: It is based on deductive reasoning as well. And our system can do some of that as well. It would not deal with any case that requires real world reasoning. John McClure: Have you identified the data elements that should be extracted? Dr. Leff: Yes, and I have submitted those to Dan Greenwood. There is a folder on the web (documents section) called snippets. It should be there. We used Jason's template and identified the various things that need to be in a contract. John Messing: Would it be helpful to have the parameters encapsulated in some kind of XFORM? Dr. Leff: We are matching up clauses. I haven't figured out the best way yet. Jason: We are talking about having a contract, then that there is an obligation, and then, thirdly, with reference to the obligation that was represent in this formal language, it was performed or not performed. Dr. Leff: Yes, and I assume that there will be tags that represent these. Jason: So we have tags, non-structural markup, and assertions about non-structural markup. Dr. Leff: Yes, and there would be tags for payment, delivery, and so on. Jason: You have a contract in the traditional sense. We are marking it up in structural and non-structural markup. Dr Leff is adding another level on top. In addition to identifying an obligation we want to make factual statements about whether that obligation was fulfilled or not. We have called that third level the 'state' so that at any time when a contract is being performed you can check to see the state. Goods shipped but not arrived. Goods shipped, payment accepted but receipt not delivered. That state model will be doubtlessly talked about more as we progress. Dr Leff: Yes. Others have looked at this and some of their work is referenced in our resources page. Zoran: You have state and related events that change states. Actions, states and other temporal information tell you weather obligations and commitments have been violated. We have spent a fair amount of time looking at the kinds of events that impact contracts. John McClure: The notion of statements about other statements was introduced as an implementation in RDF. My question is concerned with the value that can be extracted from other markup sets like eBXML to mark up the semantic info in a contract. Dr. Leff: EBXML is not about that. The business process spec may be able to help with that. We will need markup to represent events as well as obligations. In some way a contract should say party A needs to send an eBXML message and party B will do something else. We need to be able to hook in and the question is how to do it. Dan G: We went right into questions. Did you cover what you needed to? Dr. Leff Yes. The questions were on point and helped a great deal. DG: This work is way ahead of the current implementations, definitely quite early. Even so, it is very useful to discuss it and be aware of it. Dr. Leff: If we have ways of marking up obligations and event triggers that should allow us to do a lot. Many of the same issues are in Rolly's presentation as well. I have much of Zoran's work on our resources page. If you have more let me know. The resources page has been posted. The catalog needs some formatting and I'll work that out. DG: Given the time, I'd suggest that we adjourn. Thanks Dr. Leff. We can continue with Dave's automated negotiation scenario net time. I am hoping to get an understanding of what our standard would need to look like if it would work with your system.and to see if that is consonant with the standard as it is taking shape. I'd also like to finish up John McClure's scenario. John McClure: I don't have that much to add. I'd rather not take time away from the discussion on structural markup. Dan G: We should be able to get to the structural mark-up soon. John McClure: I don't think I have much to add beyond what has already been discussed. Dan G: Then, with your approval, can we deem your scenario to be completed? J McClure: Sure. Dan G: Thanks. Then we only have 2 left to discuss. So we will have Dave's scenario, and agenda issues for Sydney, and a few other administrative issues. We'll meet 2 weeks from today, and 2 weeks later a full discussion of structural markup and enterprise scenarios. Jason: I think we could discuss Peter and My scenarios in the next call. They go together (structural markup and our scenario.) Dan G: What don't we plan to do ANS in 20 minutes and then do the enterprise scenarios in the remaining time. We can do structural discussion the following meeting and handle the administrative discussions by email. Dan G: Anything else? John Messing: In a different meeting in SF we had a meeting discussing documents being used by Fannie Mae and Freddie Mac. Their documents have been prepared in XML for real estate closing under the acronym MISMO. I have the URL. Is that something this group should look at? DG: I think it is a god idea. Would you be willing to post the URL to the MISMO docs to the list, and perhaps invite someone from MISMO to come and present to us? It is clearly huge. Would you be willing to make a request to one of our friends.? John Messing: I'd be happy to post that. As for the timing, I'd be happy to invite someone. [Note: John Messing later posted the MISMO URL was later posted to the mailing list. It is: http://www.mismo.org/mismo/emgr_10.cfm ] Dan G: So we can work on that offline. Meeting adjourned. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]