The VERSION class has a commit-audit, in the specs description: Audit trail corresponding to the committal of this version to the VERSIONED_OBJECT. This cannot be void.
The VERSION class has also a contribution: a reference to a contribution in which this version was added. Also this cannot be void.
The CONTRIBUTION class has also a audit, in the specs description: Audit trail corresponding to the committal of this contribution, also may not be void.
I don 't understand this, isn’t is so that the the audit of a version very often is the same as the audit of a contribution? And that it is logically possible to find the version belonging to a contribution, and vice versa?
So, what is a good reason to have audit’s in both contribution and version which cannot be void and probably are the same?
I have another simple question, about contributions.
The purpose of contributions is to have the possibilities to reproduce afterwards which versions are posted simultaneous, so one can see which belong together.
Heath illustrated this by comparing it with a version-control system like f.e. SVN.
I wonder in this case, why isn’t there a datetime in a contribution, like there is in SVN. Easy, for finding out, what was a clinician doing when he created this contribution, and which contributions did he create on the same day, or the day before, or the day after.
The VERSION class has a commit-audit, in the specs description: Audit trail corresponding to the committal of this version to the VERSIONED_OBJECT. This cannot be void.
The VERSION class has also a contribution: a reference to a contribution in which this version was added. Also this cannot be void.
The CONTRIBUTION class has also a audit, in the specs description: Audit trail corresponding to the committal of this contribution, also may not be void.
I don 't understand this, isn’t is so that the the audit of a version very often is the same as the audit of a contribution? And that it is logically possible to find the version belonging to a contribution, and vice versa?
So, what is a good reason to have audit’s in both contribution and version which cannot be void and probably are the same?
I have another simple question, about contributions.
The purpose of contributions is to have the possibilities to reproduce afterwards which versions are posted simultaneous, so one can see which belong together.
Heath illustrated this by comparing it with a version-control system like f.e. SVN.
I wonder in this case, why isn’t there a datetime in a contribution, like there is in SVN. Easy, for finding out, what was a clinician doing when he created this contribution, and which contributions did he create on the same day, or the day before, or the day after.
The date and other information for the Contribution is in its Audit.
The VERSION class has a commit-audit, in the specs description: Audit trail corresponding to the committal of this version to the VERSIONED_OBJECT. This cannot be void.
The VERSION class has also a contribution: a reference to a contribution in which this version was added. Also this cannot be void.
The CONTRIBUTION class has also a audit, in the specs description: Audit trail corresponding to the committal of this contribution, also may not be void.
I don 't understand this, isn’t is so that the the audit of a version very often is the same as the audit of a contribution? And that it is logically possible to find the version belonging to a contribution, and vice versa?
So, what is a good reason to have audit’s in both contribution and version which cannot be void and probably are the same?
Thanks again Thomas for your answer, excuse me for not responding immediately.
What you say is exactly my point, so what is a good reason to have audit’s in both contribution and version when they are the same?
The spec says: whenever a contribution is committed, its audit-attributes (system_id, committer,time_committed) should be copied to the commitaudit of each version included in the contribution.
It is not a very important or urgent question, but, in my opinion, the commit-audit in a version could be NULL, because the information is already in the contribution. It cost some system-performance, because when looking up a specific version, the system has to compare the version-audit with the contribution-audit, to find out that they are eventually the same.
In case the spec would allow the version-audit to be null, this comparison would not need to happen.
The system would not loose any functionality. The spec at this moment is causes the system to be a bit unnecessary inefficient (which can count when doing some specific datamining).
as soon as ORIGINAL_VERSION objects are sent somewhere else in an EHR Extract, they carry their local audit trails, but not the Contribution objects with them. So any ORIGINAL_VERSION is always ready to be copied safely to another location. In the receiver location, only that audit trail is available, the original Contribution and its audit are not visible. It is I think the only instance of information duplication in the whole of openEHR, but it is necessary for correct distribution semantics.
I am not sure why you want to do the comparison you mention…
as soon as ORIGINAL_VERSION objects are sent somewhere else in an EHR
Extract, they carry their local audit trails, but not the Contribution
objects with them. So any ORIGINAL_VERSION is always ready to be
copied safely to another location. In the receiver location, only that
audit trail is available, the original Contribution and its audit are
not visible. It is I think the only instance of information
duplication in the whole of openEHR, but it is necessary for correct
distribution semantics.
I am not sure why you want to do the comparison you mention...
Now I think of it, it is indeed never necessary to do the comparison, it
is indeed redundant information. Thanks for explaining this
Bert
