Re: [legalxml-econtracts] Thinking about information models

[Rolly Chambers <rlchambers@smithcurrie.com>]

I agree.

To reduce the number of models at play and somewhat simplify the challenge,
I would be fine leaving the physical model alone. Issues of pagination,
layout, etc. could be addressed via stylesheets (xsl, css, etc). Dealing
with the other models looks like challenge enough to me.

Rolly Chambers


----- Original Message -----
From: "Dave Marvit" <dave@marvit.org>
To: <legalxml-econtracts@lists.oasis-open.org>
Sent: Tuesday, January 28, 2003 3:23 AM
Subject: [legalxml-econtracts] Thinking about information models


> Folks,
>
> John's insightful comments about the fact that there are several
coexisting
> information models in a given document has gotten me thinking.
>
> It seems to me that the lens used to look at a contract determines which
> information models are most significant. For someone worrying about
printing
> contracts (to meet various hardcopy filing demands) the physical model
might
> be most important. For me (thinking about automated negotiation) a
> parameterized representation consisting of name value pairs becomes the
most
> important.
>
> Perhaps one approach is to use the scenarios to determine not only the
> appropriate constraints (no mean feat), but also to figure out what
> information models are at play.
>
> I suspect that we will end up having to represent a contract as several
> coexisting documents -- each reflecting a different information model.
>
> One early guess is that we may end up with something like this:
>
> 1. A physical model document - describing the contract in terms of
> pagination and layout
> 2. A structural model document - describing the contract in terms of
> paragraphs, clauses etc...
> 3. An obligation model document - describing the contract in terms of
> commitments to which all parties have agreed. (I will look forward to
> learning more about this perspective from Dr. Leff.)
> 4. A parameterized model - describing the contract in terms of the values
of
> each of the contract terms.
> 5. (Others?)
>
> Put them all together (for some value of 'all') and you get a contract.
The
> specific model(s) used depends upon the demands. But to fully represent a
> contract all of these different models must be created.
>
> Thoughts?
>
> Dave Marvit
> Fujitsu
> dave@marvit.org
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>