Issue Formulation

Usage Scenario: a process for reaching an agreement.

The following is a description of the discussion method which CRM-SIG follows in order to resolve current people comments and problems arising when they try to apply the CIDOC CRM. The general idea of this method is not only to reach to an agreement, but also to acquire an understanding of problems associated with comprehension and application of the CRM and its associated documentation.   Any time someone encounters a problem of documenting knowledge about a cultural asset, sends an email about that problem to the crm-sig mailing list.

  • People comment on the issues and sometimes it turns out that the wording of an issue is unclear and needs fixing before there is a common understanding of what the issue means.
  • Proposals are put forward. The issue either leads to a proposal for a change in the CRM, or the conclusion is, that the issue is already covered by the CRM as it is. The issue may also be regarded as out of scope of the CRM. In that case, a possible extension to the CRM may be proposed anyhow
  • We discuss the pros and cons of the various proposals relating to a given issue by emails, if we succeed on the mailing list then that's fine, if not, it becomes a meeting subject and it is discussed in physical meetings. In both cases, when an outcome has been reached, the issue in the form of step 1 completed, is uploaded to the CIDOC CRM site.

The following steps describe the process of resolving an issue in physical meetings and it shows how the development of the CIDOC-CRM is succeeded.

Step1: issue formulation and post
Anyone who encounters a problem by applying the CIDOC CRM may send an email to the crm-sig mailing list. The representatives of the special interest group read the problem and investigate if it is a misunderstanding of the model or if it is a case that needs more investigation.  If it is a case that needs investigation, they formulate a new issue. The issues are collected and discussed in physical meetings.

The issue should be described in the following form. When we initiate a new issue it should have been filled the (1), (2) and (9) at least. Sometimes the proposer may designate a proposal to be discussed. In this case the item (4) should be completed.

Title (1) : Write a representative title for the issue.
Background (2) : Describe the problem and report why it cannot be resolved by the current situation of the model. Attach any previous decisions that affects this problem or references to the current official version of CIDOC CRM.

Old Proposal (3) : 

Current Proposal (4) :

Proposal is a solution to the above problem that can be decided with “yes” or “no”.  A proposal may be rejected and stay open for revision. All proposals are listed. Ιn Current Proposal entry write the proposals which are open for a decision along with the date issued this proposal. This entry may contain multiple alternatives. In Old Proposal entry, you may write all the others.
Outcome (5) : Write the decision that has been taken along with date and place of this event. If this entry is completed, this means that the issue has been “closed”.
Status (6) : Write the word  “proposed” if there is no proposal,  write  the word “open» if there is a proposal, write the word “done”  if there is an outcome.
Working Group (7) :

Write 1, if the proposal concerns editorial changes.
Write 2, if the proposal concerns application guidelines.
Write 3, if the proposal concerns changes in the CIDOC CRM model.
Write 4, if proposal concerns additional documentation and didactic material.
Starting Date (8) : Write the date of the first appearance of the issue.
Closing Date (9) : Write the date of the decision taken. An issue cannot be re-open but a new issue should be defined if a formal decision is questioned.

Step 2
We discuss with the representatives of CRM-SIG in a physical place.Usually we use a data display connected with a laptop, a whiteboard and/or flipchart.   The laptop should be connected to the internet also, in order to provide access to the minutes of previous meetings, to current and previous releases of CIDOC-CRM.

Step 3
Analysis is started with source view (graphs/texts). Usually we prefer to use graphs, or plain text to observe the problem. Sometimes someone of the group has prepared a power point presentation about this. When the problem has been presented then we move to the next step to check the current situation in CIDOC CRM.

Step 4
For examining the current situation we present either the text from current version of CIDOC CRM official text or we are examining graphical views of the current CRM model provided by the appropriate software we use to describe the last updated version of CIDOC CRM.

Step 5
We start thinking about the proposed modifications, changes or extensions. Someone who has a proposal about a modification or addition makes a draft sketch in the whiteboard or flipchart, someone else who wants to make another proposition modifies the existing sketch or draws a new one in a new sheet in flipchart. Sketches are being used a lot in the meetings of CIDOC –CRM since sometimes the notions have subtle distinctions between them which cannot be expressed by a language or being understood by all the participants.

Step 6
During the discussion we use different color markers to designate the proposing modifications or additions. We make use of specific symbols to denote the things that we agreed on or disagreed or we not sure about that respectively.  In parallel we keep minutes of all the discussion.

Step 7
Sometimes during the discussion we may observe or notice other existing incompatibilities, or concluding in an outcome, this might cause an action to be taken like to set another issue for something else or to reexamine a previous decision under the light of the current outcome. All these details we keep in the minutes. If there is time we write the decision or action, but in most cases there is no time since the discussion has been moved on another aspect. In this case we add just few words with appropriate tagging to remind us later the discussion or the problem stated in order to express it correctly to the minutes. When we have come to a conclusion, we check the consistency of the solution with other associated entities of the model, by going over the text of them, or we might go over the flipchart or white board when an inconsistency arises. 
 
Step 8
We come to a conclusion when there is no objection to a proposed solution. We write definition drafts, make new graphs. Then we edit the   initial text of CRM issue by adding the outcome in item (5) and adding in the item (6)   the word “DONE” and in the item (9) the current date otherwise we add to the items (3), (4) (current proposals)  if it is an alternative proposal for discussion in following meetings and we add to the item (6) the word “OPEN” .  
 
Step 9
When a meeting is finished, we make new official version of the CIDOC CRM by adding to the current version the outcomes of the issues resolved in this meeting. Then we upload this version to the CIDOC CRM site, the minutes of the discussion,  and we update the issues in the work progress of the site.

 

Text status: 
To be reviewed