Terminology Server Exchange Interface - Initial Discussion - 2018-05-02

Attendees:

• Balazs Banfai

• Christopher Morris

• Dion McMurtrie

• Guillermo Reynoso

• Jesse Efron

• Matthew Cordell

• Keith C

• Rory Davidson

• Kai Kewley

Agenda

• Agree purpose and scope of the terminology server exchange interface.

• Brainstorm implementation options including delivery mechanism and format.

Notes (from Rory)

SI Use case
- distributed authoring, sharing of authored content on both sides of the equation

KC
- the ability to have 2-way synchronization of editing content, full suite including refsets, dialects, descriptions, definitions, etc. (optionally 2-way)
- store & forward approach instead of real-time (less brittle)
- the ability to share and consume editing content

JE
- single repo/directory

GR
- being able to subscribe to changes
- definite the payload, instead of the wrapper at the moment
- versioning necessary

DM
- pull requests
- what the commonality that we can identify

BB
- submit patches via issues that would be a common format
- <missed it>
- replication of branches, with the inclusion of cherry picking

CM
- reiterating would others have said, but controlling the requests including versioning, what has been added
- push model for NRCs and early access of new international content
- the ability to maintain refsets more fluidly

Overall
- visibility of changes (pub/sub)
- (from kec) some of what I’m hearing is:
1. Transport layer independent representation of change
2. Granularity of change at the level of an identified component
3. Ability to collect all of these changes in a central repository

What extra info beyond RF2:
a. author
b. path
c. Uuid for every component
d. No requirement that the SCT id be already assigned

transactionTime/timeStamp rather than effectiveTime

Annotations, other metadata can be represented as refsets, and then the change set can represent annotations without creating independent representations for annotations or other metadata.

If we use a zip file to store the change of an enhanced RF2 (uuid, path, transaction time, time stamp), we can put standard things such as release notes inside the zip file.

KC
-Also from/to information for a “delta” zip.

GR
-Our experience with RF2 deltas has not really been that good between development environments.

DM
- yes I think a zip with some metadata added would be needed for RF2 delta, but I’d like to get down the issues that you’ve experienced Guillermo, not that I don’t think they are real…I’m sure they are!

KC
-Just keeping an “open mind” on RF2… :-)
I think we need to work through a number of “policies” about how change sets should deal with conflicts/contradictions...
i.e. not too prescriptive