REA ontology

[Hans Weigand]

I am still working on the double-level composition.
In my view, the point that real-world services invoked by web services
must be distinguished from the web services is a solid and relevant one.
But it is not sufficient for a paper. How to proceed?

My idea is to introduce a way of representing the direct and indirect
effects of web service executions by means of the REA ontology in OCL
(based on REA UML class model).
(according to Frederic Gaily, this is at the moment the most developed way
of specifying REA constraints)

So that we can talk about the creation of a commitment, of an economic
event (with effects on resources) etc. And the constraints between them.

For example,

context event :: create(): object
pre
post forAll(r | stockflow (self,r) implies r.effect(self))
/*this is not correct, as r.effect is a method and not a property
/*what I want to say is that the event should have effect on all resources
/*with which the event has a stockflow relationship

context duality
inv forall (e1,e2| duality(e1,e2) and exist(e1) implies exist e2)

context resource :: effect(event e)
post stockflow(e,self).type = take implies self.owner = e.agent
post stockflow(e,self).type = give implies self.owner <> e.agent

context commitment::create(resource r, timeslot t)
pre r.reserved(t) = false
post r.reserved(t) = true

context hotelwebservice::reserve_room(r,t)
pre available (r) /* can be inherited from the resouce property of r
post exist commitment(r,t) /* inherited as well

As you see, I am still struggling, so perhaps someone can help.

Gaily and Poels have described the REA ontology in UML
There is also the OpenEDI standard based on REA in which objects like
transaction are described and the states that they can take (started,
proposed, etc)

If we succeed in developing this language, this is an interesting result
in itself, as it would provide a possibility of describing service effects
in an ontologically well-structured way.

We should add how the effect specification can be used:
- to solve the planning problems such as described by Paolo Traverso in a
generic way
- general specifications can be used as templates in the design. E.g.
hotel reservation as a special type of reservation of a service.
- the specifications of a certain service can be used as constraints on
the implemetation (postconditions and invariants must be respected).
- the specification could be used perhaps in service discovery, although
this runs the risk of receiving the same fate as semantic web service
descriptions (too much for the developer and not enough for the customer)
- ?? more

Questions

- Do you think it makes sense to develop such a language?
- Is the OCL the best candidate, or are there better alternatives?
- If so, how to proceed?

[maria]

Hi Hans,

A very late answer, just on the draft stage, please find enclosed in
the text below

Ok, we discussed various time-concepts in relation to Economic
Resources and Services. We might need to analyse what different types
of time points (descrete, intervals etc.) might be relevant for
Services. Also the property 'time' is not clearly defined in classic
REA (though we think Ruby has written about this). In the example
below time point t might have different interpretations: as a discrete
point in time ('Paul has booked a hair-cut to happen 12.00'), an
interval ('Maria has the right to use a movie-service for three
months, after that it expires'). We also envisaged that the creation
of Comittments (like you described for Resources) might exist in more
or less elaborated variants, where the more complicated ones inherits
its properties from the basic ones. Below we experimented with two
variants of creation of Comittments. Both take Economic Resource Type
as point of departure, related to the Comittment in question. In terms
of time-points for services we then had to go from Economic Resource
Type to Economic Resource for the time-point to make sense. We used
the Gailly, Laurier Poels REA model, here the association between
Economic Resource and Economic Resource Type is termed 'typify', the
vice versa direction of the association we refer to as
'typifyinverse'.

/* Create Comittment I, a variant where no timepoint is taken into
consideration*/

context commitment::create(Integer num)


pre self.reciprocity <> self;

pre self.specify = NULL ;
pre self.specify.stock >= num; /* needs to be discussed, property
stock is not a property of economic resource type in REA */


post self.specify <> NULL;


/* Create commitment II: In case of the economic resource type being a
service, we though that services will (always?) have a time interval
associated, which other resources have not, e.g. we might have a
constraint saying that this service shall be performed during this
interval. Or, maybe more usefule, at a descrete point in time. A
problem here is that we have to adress Economic Rescourse rather than
Economic Resource Types. The time point or interval might be used to
sync services, i.e. if one service (delivery by train) must "happen"
before the commence of another service e.g. (movie-service) i.e. the
two be synchronized*/


context commitment::create(Integer num, time point t) /* inherited
from Comittment I */


pre self.reciprocity <> self;

pre self.specify = NULL ;
pre self.specify.stock >= num; /* needs to be discussed, property
stock is not a property of economic resource type in REA */


post t = self.specify.typifyinverse.time; /* the economic resource
related to an economic resource type related to the commitment to be
created is assumed to have a timepoint or interval property*/


post self.specify <> NULL;

> context hotelwebservice::reserve_room(r,t)
> pre available (r)   /* can be inherited from the resouce property of r
> post exist commitment(r,t) /* inherited as well
>
> As you see, I am still struggling, so perhaps someone can help.
>
> Gaily and Poels have described the REA ontology in UML
> There is also the OpenEDI standard based on REA in which objects like
> transaction are described and the states  that they can take (started,
> proposed, etc)
>
> If we succeed in developing this language, this is an interesting result
> in itself, as it would provide a possibility of describing service effects
> in an ontologically well-structured way.
>
> We should add how the effect specification can be used:
>   - to solve the planning problems such as described by Paolo Traverso in a
> generic way
>   - general specifications can be used as templates in the design. E.g.
> hotel reservation as a special type of reservation of a service.
>   - the specifications of a certain service can be used as constraints on
> the implemetation (postconditions and invariants must be respected).
>   - the specification could be used perhaps in service discovery, although
> this runs the risk of receiving the same fate as semantic web service
> descriptions (too much for the developer and not enough for the customer)
> - ?? more
>
> Questions
>
> - Do you think it makes sense to develop such a language?

Yes, though difficult. The underlying models for the language much be
"rich" enought, REA (if used) needs to be extended.

> - Is the OCL the best candidate, or are there better alternatives?

Definately an attractive candidate assuming UML profiles exists for
whatever underlying model is used. OWL-S and similar might also be
worth looking into.

> - If so, how to proceed?

This seems related to our parallell work of extending the Caise-paper
with Service descriptions and constraints, at least the latter might
be used to create a (UML-) model we can base some test-OCL constraints
on.

/mvh Maria & Paul

[Hans Weigand]

Please find enclosed version 0 of the caise paper.
I am aiming to finish section 3 next week.

Note that I propose to use the hotel reservation case for demonstration,
rather than the Traverso case, as we thought a lot about this case and it
is well-described in the www community. Still, the idea is to show also
how conflicts with the personal agenda could be avoided, as in the Traverso
case.

Greetings

Hans

Dr. Hans Weigand
Infolab, Tilburg University
email: H.We...@uvt.nl phone: +31 13 4662806 fax +31 13 4663069

[Paul Johannesson]

Hi,

Here are some comments on web services and their relationships to
other services as well as some suggestions for the general service
model.

http://docs.google.com/View?id=dm8b2qw_61fwxpv389

Paul and Maria

[Hans Weigand]

To be more precise about coordination service we could say indeed that it
is a service that manipulates commitments; that its goal is an event
affecting a commitment.

A web service is a software module that uses IT resources and transforms
data. In a social context, the web service can realize a coordination
service. In that case, the context rules ensure that the input and output
data count as social facts. So the web service in context is a
coordination service in the sense above, supporting an exchange
process.
(of course, not all web services need to be coordination services)

[maria]

Hi Hans,

Some more comments on (a later version) of the caise paper.

On Using and Consuming Services

In Section 3.2 of Hans's paper draft, there is a discussion on service
use
and service consumption. It says "The effect of service use is a house
being
rescued". Well, this is fine, but it feels a bit too direct. Would not
it
rather be:

Using the (emergency fire brigade) service the right to another
service is
produced, the specific rescue service. When this rescue service is
consumed,
the effect is a house being rescued.

Some services can be used to produce other services, and when these
services
are consumed effects are achieved. Certainly, also other resources may
be
required to produce a service. 

Another issue is whether we can say that by consuming the emergency
service,
"feeling of security" is produced. This would be more direct than the
present analysis.

In summary: 
the emergency service is used to produce a right to a rescue service,
which
is consumed to produce a house being rescued
the emergency service is consumed to produce a feeling of security

--
mvh/Best regards

Paul, Maria & Birger

> email: H.Weig...@uvt.nl  phone: +31 13 4662806   fax +31 13 4663069
>
>  caise10.docm
> 343KVisaHämta

[Hans Weigand]

Please find enclosed the VMBO paper that I want to submit this week.
There are certain things that could be discussed/improved, but I suggest
to do that later. Only major faults should be removed.

The point raised by Maria on a service consumption creating a right: I see
the point, but is also complicates matters a lot (what are the
resources used in the consumption of this right, for instance - they
coincide with the resources used in the service). Whereas the "effect" is
the same. So we have to think about it.

Dr. Hans Weigand
Infolab, Tilburg University

email: H.We...@uvt.nl phone: +31 13 4662806 fax +31 13 4663069

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Stockholm Meeting Aug 2008" group.
> To post to this group, send email to stockholm-mee...@googlegroups.com
> To unsubscribe from this group, send email to stockholm-meeting-a...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/stockholm-meeting-aug-2008?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

[Hans Weigand]

Maria,

it did reach me and I reacted briefly. Let me try to be more elaborate.
Your proposal is to put something between service use and the "rescue
house" event,namely:
create right "rescue service"
?use right "rescue service"
?create "rescue service"
consume "rescue service (right)"
event "rescue house"

The advantage that I see is that "rescue service" is now modeled as a
service, whereas in our present model we can only say there is a rescue
event being part of a fire brigade service. Intuitively, we may call the
rescue service a service, although it is not being paid for as such and
there is no contract governing the service (other than the contract for
the general service).

However, the advantage is also a disadvantage. As I wrote yesterday, it
leads to a certain duplication of resource use, as the resources used for
the fire brigade service (man hours, cars, etc) are now the same resources
as being used in the rescue service (or at least the former include the
latter - there may also be resources used only for the consumption of the
fire brigade service).

More importantly, there is a risk that this approach leads to an
infinite regress. You propose to create a rescue service, but following up
your reasoning, it would mean that the consumption of this service
creates some right on yet another service, etc.
Unless you want to talk about rights only in the case of service use, and
not consumption. Then the recursion could stop when there is a service
that is consumed but not used.

A second point is that although the chain of events becomes longer in your
proposal, the ultimate effect remains the same. So what does it help?

A third point: rights are relevant, but it is not necessary to make them
always explicit. A good exchange also has the effect in change of
ownership. Still, we do not say normally that the exchange event results
in a the creation of a ownership right which is consumed or used in the
creation of a good use.

All this does not mean that you *could* not make the rights explicit. If
there is a reason (derived from the modeling purpose) for doing so, this
can be done. Otherwise you don't. In this way, the problem of infinite
regress is avoided, I would say.

So to finish:
- do you agree that right creation is not a *necessary* property of
service use?
- what would be the reason for making the rights explicit in
the fire brigade case?

[Hans Weigand]

Another question is the effect of fire brigade consumption.
I think you are right that "availability of fire brigade" is not a good
analysis. The availability is captured by resources from the fire brigade
being used (and therefore committed to from the beginning of the
contract). At the customer side, the effect should be described in terms
of resources controlled by the customer. This could be houses, people.
They become more secure (not that an incident could not happen, but the
damage will be limited), which is of value to the government and its
citizens.

[Paul Johannesson]

About using services and producing rights


Services can be used to produce other resources. We suggested that
when used, a service produces a right. This is not necessary, as we
can move more directly to a desired effect (answer to Hans's first
question).

The advantage of viewing service use as right production is that it
makes it possible to relate services in our model. Intuitively, there
is clearly a relationship between the fire brigade service and the
rescue service. It would be nice if our model was able to represent
this relationship, which is not there if we say that the fire brigade
service is used to produce a rescued house directly (the rescue
service becomes invisible). Furthermore, the rescue service can exist
independently of the fire brigade service, we could (at least in
prinicple) buy it from the fire brigade (answer to Hans's second
question).

There should not be any infinite regress. Most service can not be
used, only consumed. Emergency services can be used, though, and maybe
there are some more.

[Hans Weigand]

Paul,

ok, so you say it is not always the case, but that a service can produce a
right for another service. Do you say this is always the case when a
service is used?

I understand that in this way you can see the rescue service here as a
separate service. But still 2 questions
- do you need a right in the chain? Could you not say that the "service
use" produces the other service directly (conversion duality)?
- what is the criterion for positing a service (such as rescue service)
here, rather than an event? In this case, I intuitively agree that we can
call it a service, but I am not sure on what ground.

Kind regards

Hans

[maria]

On 24 Nov, 22:34, Hans Weigand <H.Weig...@uvt.nl> wrote:
> Paul,
>
> ok, so you say it is not always the case, but that a service can produce a
> right for another service. Do you say this is always the case when a
> service is used?

I am not sure, rather there exists services that do indeed produce
(conditional in this case) rights to _other_ services.

> I understand that in this way you can see the rescue service here as a
> separate service. But still 2 questions
> - do you need a right in the chain? Could you not say that the "service
> use" produces the other service directly (conversion duality)?

Yes you probably could, the rights-relationship was one approach to
model the relationship between the two services in this case.

> - what is the criterion for positing a service (such as rescue service)
> here, rather than an event? In this case, I intuitively agree that we can
> call it a service, but I am not sure on what ground.

One such criterion might be that the service (such as a rescue
service) might exist independently from the other service (the fire
brigade service in this case). Don't know if this example is the best
though, one could compare this case to a healht-insurance service and
the various doctor-nurse-services that will be invoked if certain
conditions are met (i.e. I am ill enough). In this case the latters
may be purchased as independent services of an agent that does not
happen to have the general health-insurance service in advance.

/mvh Maria

> Kind regards
>
> Hans

[maria]

Hi Hans,

We went through the Caise-paper and tried to comment each section in
chapter 3, some comments are just general but some has to do with
consolidating the UML class schemas in order to prepare for writing
OCL.

Best regards, Birger, Paul & Maria

CAiSE'10-comments

Section 2.

The intro is a bit 'fast'. The level of detail as compared to section
one is very different. Some very brief presentation of WSDL is also
needed.

Section 3.1

* Figure on page 7. Is the 'Resource set' synomynous with
Capacity?

Or:

* Capacity IsA Resource set;
* Reserved IsA Resource set;
* Availability IsA Resource set.

Availability is Capacity - Reserved; Reserved is Capacity -
Availability.

Then some simple constraints can be formulated. E.g. card
(Availability) =< card(Capacity), card(Availability) => 0, etc.

In REA a contract is a set of Commitments.

* Is the association between Contract and commitments 'Includes'?
* Is the relation between commitments 'reciprocity'?

Section 3.2

* Text on owning and possessing services is vague
* There is a need for a definition of "service"

I (birger) can think of services in several ways and they should not
be confused:

1) an agent has a capability of producing a service. The capability is
a service. (service capability?);

2) a service delivery / service execution is a service. This is close
to Guarino's view. (service execution?).

I think the meaning of the text currently points to 2). The casual
reader might object to what is written and e.g. argue that DHL indeed
owns its delivery service.

The figure in 3.2:

* The top part holds for any resource production, not only for
services; this could be pointed out
* The association labeled "goal" from service to resource use
event is tricky to understand. Should not goals rather be about what
is produced?

* In the introduction of the figure is mentioned that a provider's
and customer's perspective are included. Which is which should be
pointed out.

The section below the figure starts to abruptly, there should be a
softer introduction telling why you need both service consumption and
service use

Section 3.3

The Reservation explanation is still a bit vague. We should explain
what is meant by reservation in intuitive terms before explaining it
in REA terms.

* Coordination objects are also introduced too abruptly; it should
be explained what they are. Appointment pops up in the first paragraph
as a coordination object. It is never explained. Same with Booking in
a sense, but there one can find some info in the Reservation
discussion. But the suspicion is that Reservation and Booking are
synonyms.
* A Reservation is explained as when a resource is set aside in
order for a future fulfilment of a commitment. Is that the same as
saying that some capacity is limited at some space and time?
* A small digression: we have used the terms 'Claim' and
'Obligation' in some of our discussions. Is a Commitment synonymous
with Claim?

* In the figure on p. 9, there is an economic event <create d-
commitment> at the bottom with two stockflows. Is this allowed in REA?
If not, this event should be split into two.
* In the section under the figure on p.9 it is said that "... a
commitment is something between one agent and another". That's a bit
vague. Under figure p.7 commitment is mentioned for the first time but
is never defined, so what the reader is left with is the phrase above.

Comments on OCL

* Some discussions on the OCL for the bookingpattern: the
comittment comes into being via the Economic Event, one alternative is
to let the OCL for the creation of Comittment be in the context of the
Event (sub-classed for the creation of various types of comittments),
for example:

context economic event::create economic event(agent a, resource r,
resource type rt, comitment c, timeslot t)

pre comittment(c)

pre economicResourceTypicfy(r, rt)

pre specifyEconomicResource(c, rt)

pre inverseOfFulfil = NULL

post fulfill(self, c)

post stockflow(self, r)

post participate(self, a)

post time(self, t)

/* create_comittment isa Economic event */

context create_comittment ::create booking(agent provider, agent
receiver, resource type rt, timepoint t)

pre agent(provider)

pre agent(receiver)

pre economic resource type (rt)

post receive(self, receiver)

post provide(sef, provider)

post exists c comittment(c) and specify(c, rt) and time(c, t) and (if
d-comittment(c) then gives(self, c) else take(self, c))

/* the time dimension is not present in any of the patterns (booking/
appointment), however, location is, time should be introduced */

OCL above are using partly patterns of caise-paper (booking) and
canonical REA.We need to decide on what UML-diagrams will be in the
paper, and then start OCL-examples such as hotelbookings etc. Much
like Hans SVBR-example.

[ba]

We've created a PP with some small rework of the models in the paper.
It's in the Files section and a link is here
http://stockholm-meeting-aug-2008.googlegroups.com/web/CAiSE10-Modelp7.ppt?gda=s1UM1EUAAAAfZklXnojltdr2tGtQC3mOjsYKB_YdyANwvkUTGcFKyuAJX_NI6QLG-ttkymFq54ls7Hm76flVp_vYI1lbK8kaGu1iLHeqhw4ZZRj3RjJ_-A&gsc=vNL_cgsAAACTFmIxJtbcBDmrdYw-zrWh

We're still pondering about how to handle Time and Location. Hans has
proposed one way in the paper, and the PP contains some alternatives.

Given the machinery we have now, here is a natural language
formulation of conflict rules:

* A number of services conflict if they concern the same resource
and their time periods overlap.
* Two services conflict if they concern the same resource, have
different locations, and the end time of the first is close to the
start time of the second.

These are vague and need to be adapted to the situation at hand.

Are there, in principle, any other types of conflict rules?

/birger

[Hans Weigand]

Birger,
thanks for the clear diagrams.
I would not put time/location attributes at the resource type, as the
*type* does not have these properties, right?

As far as I can see, time is not handled consistently in REA. Sometimes,
an entity "worked hours" is introduced as a kind of resource.
- To have time as an attribute of events is not contrversial, I assume.
The time reference can be a point or an interval from/to.
- I would say that a resource exists over time (endurant). Resource use
means (at least) use of the resource life time. From this I think it would
be confusing to model time, or resource time, as a separate entity.
- What could be added to a resource is a creation time and deletion time,
but for the rest I don't see the meaning of a time attribute of a
resource.
- A fundamental issue is whether to see the REA database as a historical
database or as a snapshot. If you see it as a historical database, this
impies that you don't record attributes of resources that hold at some
time. At most you can have them as derived attributes. The resource is so
to say not more than an identity over time. All the information - when it
was created, when it was painted black, when it was painted white, when it
was assigned a price, etc - is stored in the form of events. If you ask
for the colour of the resource (at some time), you can derive this. It als
means that data are never deleted, in principle, only extended.
My feeling is that this approach is most in the spirit of REA, as such a
database is most convenient for controllers. It also fits well with the
idea of an agenda (end-users).

If this approach is taken, then resources become quite simple. Time and
location are properties of events. "Current location" could be defined as
a derived atttribute for resources.

I would say that location is a separate entity. Why not call it a
resource? It is used over time, and there may be conflicts over the use. A
problem is perhaps the delimitation (what are location instances), but
this also applies in a certain way to mass entities.

Question
- do you know about REA discussions on time and on the database aspect?
- would you agree with a "historical db" approach? I was wondering where
this has been described before. I know that the KISS method (derived from
MERODE) takes a similar perspective on objects (vs actions/events).

Hans

Dr. Hans Weigand
Infolab, Tilburg University

email: H.We...@uvt.nl phone: +31 13 4662806 fax +31 13 4663069

[ba]

On Dec 2, 12:43 pm, Hans Weigand <H.Weig...@uvt.nl> wrote:
> Birger,
> thanks for the clear diagrams.
> I would not put time/location attributes at the resource type, as the
> *type* does not have these properties, right?

No. That's clearly wrong. The intention behind the alternative was to
be explicit about its wrongness.

>
> As far as I can see, time is not handled consistently in REA. Sometimes,
> an entity "worked hours" is introduced as a kind of resource.

Yes, but I understand this then to be as a basis for a claim.

> - To have time as an attribute of events is not contrversial, I assume.
> The time reference can be a point or an interval from/to.

No, it is not controversial. Quite the contrary. We were toying with
the idea that it could make sense to have those attributes (time and
location) on a resource, e.g. a journey. Or a commitment.

> - I would say that a resource exists over time (endurant). Resource use
> means (at least) use of the resource life time. From this I think it would
> be confusing to model time, or resource time, as a separate entity.

Agreed.

> - What could be added to a resource is a creation time and deletion time,
> but for the rest I don't see the meaning of a time attribute of a
> resource.
> - A fundamental issue is whether to see the REA database as a historical
> database or as a snapshot. If you see it as a historical database, this
> impies that you don't record attributes of resources that hold at some
> time. At most you can have them as derived attributes. The resource is so
> to say not more than an identity over time. All the information - when it
> was created, when it was painted black, when it was painted white, when it
> was assigned a price, etc - is stored in the form of events. If you ask
> for the colour of the resource (at some time), you can derive this. It als
> means that data are never deleted, in principle, only extended.
> My feeling is that this approach is most in the spirit of REA, as such a
> database is most convenient for controllers. It also fits well with the
> idea of an agenda (end-users).
>
> If this approach is taken, then resources become quite simple. Time and
> location are properties of events. "Current location" could be defined as
> a derived atttribute for resources.
>
> I would say that location is a separate entity.

Yes. that's in your first figure (in the paper.) which stands as the
"default correct" one. Included in the PP are some alternatives.

> Why not call it a
> resource? It is used over time, and there may be conflicts over the use. A
> problem is perhaps the delimitation (what are location instances), but
> this also applies in a certain way to mass entities.
>
> Question
> - do you know about REA discussions on time and on the database aspect?

No. It is always treated as an implicit entity just as you describe
above. Time becomes the order of records (chronology) of an account in
a ledger. The ordering reflects how the account evolve over time.

> - would you agree with a "historical db" approach?

Yes, I think so.

> I was wondering where
> this has  been described before. I know that the KISS method (derived from
> MERODE) takes a similar perspective on objects (vs actions/events).

I'll have to look that up.

/birger

[Hans Weigand]

Hello Birger,

thanks for your reply. I think we agree on location and time. What is
still somewhat problematic is whether these are attributes of commitment.
And then I don't mean the time of commitment - this can be derived from
the create-commitment event, but the time attributes of the committed
event.
The problem is, I think, that in principle a commitment provides a modal
context to some proposition, like Obl(a) in deontic logic. The content 'a'
would be an event type for which it makes sense to specify constraints on
the attributes - whether it is time, location, instrument or whatever
(although it is not so clear to me how this is done). However, at this
moment, REA treats the commitment as a monolithic thing, and then all these
attributes must be assigned to commitments themselves.
I don't know whether you agree with this. If so, the question is what to
do. We can mention this as a topic for future research. For the time
being, time is indeed an attribute of commitments, and there is a possible
relation to "location". Unless someone has a better solution?

When I go through your models, then I think that we agree on the
time/location stuff. In the second part, you build up the service
application model in steps. Do you suggest to replace my complete figure
with these steps, or to add them before that figure - if there is space?

In your earlier mail, you also started to formulate rules for detecting
conflicts. I will try to formalize these.

[ba]

Hello Hans

On Dec 3, 9:33 am, Hans Weigand <H.Weig...@uvt.nl> wrote:
> Hello Birger,
>
> thanks for your reply. I think we agree on location and time.

Yes.

> What is
> still somewhat problematic is whether these are attributes of commitment.
> And then I don't mean the time of commitment - this can be derived from
> the create-commitment event, but the time attributes of the committed
> event.
> The problem is, I think, that in principle a commitment provides a modal
> context to some proposition, like Obl(a) in deontic logic. The content 'a'
> would be an event type for which it makes sense to specify constraints on
> the attributes - whether it is time, location, instrument or whatever

Exactly.

> (although it is not so clear to me how this is done).  However, at this
> moment, REA treats the commitment as a monolithic thing, and then all these
> attributes must be assigned to commitments themselves.
> I don't know whether you agree with this.

Agreed.

> If so, the question is what to do. We can mention this as a topic for future research.

I think so. The point should be mentioned.

> For the time
> being, time is indeed an attribute of commitments, and there is a possible
> relation to "location". Unless someone has a better solution?
>
> When I go through your models, then I think that we agree on the
> time/location stuff. In the second part, you build up the service
> application model in steps. Do you suggest to replace my complete figure
> with these steps, or to add them before that figure - if there is space?

I don't think there is space for adding any of those models, or indeed
a need. I think your original model is concise. It is, however, not
easy to read. Decomposing it has some pedagogical effect. I think of
the model as telling a story of how a service is created (top left),
then traded (top right), and finally used (bottom). The current "all-
in-one" figure can perhaps be explained as this for the benefit of
understandability.

I became a bit uncertain about the goal relations between the service
and the two events. The service-production quite all right I think,
but I cannot really understand the service-use.Is the intention behind
this double goal formulation to capture the idea that a service can
have both a goal and an effect?

In that case, is the meaning of this construction to say that the goal
of the service is to use some resource and the effect of the service
is to produce some resource. That is, the goal is on the producers'
side and the effect is on the consumers'. As you can see, I'm a bit
confused about this still.

/birger

[Hans Weigand]

Please find a new version of the caise paper.
Tomorrow I have a lot of time, but we have to use our resources
efficiently.
I will start by formalizing the conflict detection rules.
If you can comment on the models that would be great. Please indicate what
should be corrected or provide an alternative. If you think a previous
model was better, than just say so.
Then in the afternoon I can process these comments.

The process of developing and adapting the models is a bit chaotic, but I
hope it converges now soon...

Bye

[Paul Johannesson]

Maybe I missed something, but will it be sufficient to have time only
on events? Do not we need time also on services? If we are to
formulate conflict rules on services we need to talk about time for
them. Can this really be derived from events? When a commitment for a
service is (to be) created, there are yet no events for it.

/Paul

[Hans Weigand]

Paul,

I discussed with Birger that time should also be an attribute of
commitments. What we would like to see is an event embedded in the
commitment, but this is not possible yet in REA. However, I want to use an
event-like structure within the commitment in section 4 when we talk about
the description language. I made an attempt already, like:
commitment(id,C,Self,pay(F)..)
but it is not yet done consistently.

About the service: my assumption is that indeed the time aspects can be
dealt with by the events associated with the service. In particular, the
exchange event, I would say, as this is general for services and other
resources.

PS I have to attend an unexpected meeting this morning, so I will start
working on the paper after lunch.

Dr. Hans Weigand
Infolab, Tilburg University
email: H.We...@uvt.nl phone: +31 13 4662806 fax +31 13 4663069

> --

>
> You received this message because you are subscribed to the Google Groups "Stockholm Meeting Aug 2008" group.

> To post to this group, send email to stockholm-mee...@googlegroups.com.
> To unsubscribe from this group, send email to stockholm-meeting-a...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/stockholm-meeting-aug-2008?hl=en.
>
>
>

[Hans Weigand]

Hello,

here is the version 5 of the paper. At least two things need to be done:
the references (I will do that befor/on Monday) and the squeezing it to 15
pages. And of course a check on the content.