Draft Minutes - August 20, 2003 Meeting

[Jason Harrop <jharrop@speedlegal.com>]

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.