[oslc-ArchMgmt] Automation of record creation and record field population in an OSLC system

[Robert W Myers]

One definition of synchreplication of data might be that anytime data is 
placed in one record by virtue of data having been placed in another.
Copying the Subject of one record, creating another record through OSLC 
linking, then pasting that into the Headline of the new record is one 
example.

Two questions arise:
1) If later, the Subject of the initial record changes, should the 
Headline of the second reflect that change?
2) What value is being added by repeating the data?

When two records are linked (as is the case with OSLC) changes in one 
record are immediately visible through UI Preview from the other. 
The data is stored in one place but viewable from two.
The reason for the second record is that some new information or process 
step is being recorded.  Some value is being added to the system by adding 
this record.
For example:
If a PMR record is created to record an interaction between a Client 
Support Engineer and a Customer, and an APAR is created to record the 
thoughts of the Client Support Engineer about how they think the Product 
should work, the value added is the Client Support Engineer's statement of 
the problem which communicates to a Developer what the nature of the 
problem is from a product perspective.  The fact that these two records 
should be related and that all of their data should be seen from either 
record is also important for background reasons and chain of custody of 
the Issue, but there is no clear reason (given UI Preview of a linked 
record's data) that the PMR Subject (for instance) should be stored on the 
APAR Headline.

A developer decides to work on a defect and creates a Defect record 
linking it to the APAR.
The developer creates another record because they add value by  assessing 
the problem stated in the APAR and make a statement about the potential 
solution.  With UI Preview, there is no reason for storing the 
APAR->Headline in the Defect->Abstract.

If however, there are  records that are never deleted with  fields which 
do not change,  for example, the PMR record ID or the time the record was 
created, for example, and if there is a reason to want to know which 
APAR(s) a PMR with certain qualities is associated, then there should be a 
way to query on that info without having to connect to a second database 
instance.  

The first idea is to store that PMR ID on the APAR record.  That value 
will not change and if PMR records are never deleted (at least not for a 
long time) then that could be queried easily 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110923/4323772c/attachment-0003.html>