Concurrent-temporal model with change-approval

cccv

I've been very positively impressed by Anchor Modeling, and I've found the Anchor Modeler very helpful in exploring the AM approach. Great work!

I'm trying to use AM to model my domain and to historize related business workflows. Thus far, I believe a "concurrent-temporal" anchor model is most appropriate. I'm having trouble understanding how (if possible) to satisfy some of my system's requirement of (what I'll call) change-approval.

Lars Rönnbäck has provided a couple (at least) of "concurrent-temporal" AM examples:

- http://pastebin.com/CkEeTPSc

- http://www.anchormodeling.com/wp-content/uploads/2011/05/Back-to-the-Moment.pdf (see page 33)

For each change, my system needs to track not only posit, positor, and posit-time, but also approval/disapproval, approver/disapprover, and approval-/disapproval-time. In other words: My system needs to track:

- Information that changes over time (for example, the number of chimpanzees in a zoo).

- The unprivileged user who changed the information.

- change-approval: The administrative user who approved or disapproved the change.

Initially, a change (to, for example, a zoo's chimpanzee-count) by an unprivileged user should be visible only to administrative users. The change should become visible to all users only if an administrative user later approves the change. Any change by an administrative user should become visible immediately (that is, it should be automatically approved). The observed value of an attribute (at time "now") should be the value from the latest approved change, not the value from the latest reliably-posited change.

In a sense, I want to replace posit-reliability with posit-approval, and to track information about the users involved.

I'd appreciate any help or thoughts about how I might use/extend AM to achieve/enable these requirements.

Roenbaeck

I haven't given this a great deal of thought yet, but would it work having two positors representing the different classes of users you have, ie privileged and unprivileged. You could furthermore use reliability as it is and with at least three different values, say 0 = deleted, 1 = unapproved, 2 = approved, with only 0 considered unreliable information. The actual user identities can be stored in metadata, giving you something like the following tuples:

Posit:

Posit_ID, Anchor_ID, Value, ChangedAt

#42, #555, '100 chimpanzees', 2008-08-08

#43, #555, '102 chimpanzees', 2009-09-09

Annex:

Posit_ID, PositedAt, Positor, Reliability, Reliable, Metadata

#42, 2008-12-12, 'unprivileged', 1, true, #911

#42, 2008-12-13, 'privileged', 2, true, #912

#42, 2008-12-14, 'privileged', 0, false, #913

Metadata:

#911, 'made by lars'

#912, 'made by cccv'

#913, 'made by VIP'

Using what I in the example call "the mother of all time traveling functions" you can then choose to retrieve information with reliability strictly larger than 0 for privileged users and with reliability strictly larger than 1 for non-privileged users. Does that give you the functionality you are seeking?

cccv

I really appreciate your suggested approach, and I think it might work for my system and provide/enable the desired functionality. I need to consider it further.

cccv

Thanks for your suggestions. I believe they will work for my application and enable the necessary functionality.

For what it's worth, I think I will create a User anchor table and make each Annex's Positor column a foreign key referring to that table. I'm not sure whether I'll need the Metadata columns, so I might omit them. Do you suggest using Metadata columns for information other than user identity?

In general, why don't Posit tables have Metadata columns? Do we assume that each Posit table insertion occurs in a transaction with an Annex table insertion, making a Posit table's Metadata column redundant?

Thanks for your help.

Roenbaeck

Well, first I had a Metadata column on the Posit tables as well, but having worked with it, it always contained redundant information, since every posit must be made by a positor in order to get into the table. Also, the 'primary key' on the assembled view ensures that posits have at least one corresponding annex row. So, yes, I assumed that each Posit table insertion occurs in a transaction with an Annex table insertion.

Would you agree that that is the case? If you can see some reason why it would be good to have metadata in the Posit, I am willing to put it back.

cccv

I'm still very new to AM, but: yes, I agree that each Posit table insertion probably will (or should) occur in a transaction with an Annex table insertion. I don't see why a Posit table would need a Metadata column.