[Cesg-all] Request for Terminology Expert Group (TEG) Members

Fri May 13 21:32:35 UTC 2022

Dear CESG & WG Chairs,

I know that all of you are busy with your Working Group and Area meetings.  You may not have time to attend to this, but it is on my mind and I would like to engage you in the discussion too.

You are all aware (or ought to be) that we have a requirement in our Publications Guidelines, and in the Registry Management Policy document, to document any new terminology that is required and also to check the SANA Terminology registry (https://sanaregistry.org/r/terms/) for suitable existing terms before defining any new ones.  I assume that these guidelines are being followed in your WGs (they may not be, you tell me).

In recent CESG meetings we have reported on a collaborative effort with our sister organization in ISO, TC20/SC14, to expand the scope of the CCSDS Terms registry to include SC14 terms as well.  We already have some joint standards with SC14, primarily in the Nav WG and now the SAWG, and one aspect of this collaboration is going to be to extend the SANA Terms registry to allow use of it to manage both SC14 and CCSDS terms.  The SANA Operator is in the process of creating this extended registry in the Beta website, and we will be trying it out in the coming months.  This will allow inclusion of SC14 terms, and browsing across the whole set of space domain terms, but also will allow browsing or querying just the SC14 or CCSDS subsets.

One aspect of this new approach is that we may discover some terms that are multiply defined.  We already know that within CCSDS itself we have some terms that are multiply defined in different documents.  A simple example of this is issue is “packet”:

Assigned

packet

An arbitrary integer number of octets.

[ccsds-851.0-M-1]<https://sanaregistry.org/references/147>

1.3.112.4.30.645

Assigned

packet

Delimited octet aligned data unit.

[ccsds-850.0-G-1]<https://sanaregistry.org/references/67>

1.3.112.4.30.646

Assigned

packet

The protocol data unit of the TC Packetization layer which facilitates the end-to-end transport of command application data. The application data are encapsulated within a leading packet header.

[ccsds-200.0-G-6]<https://sanaregistry.org/references/129>

1.3.112.4.30.647

Note the following:

  *   Packet has three different definitions recorded in the existing registry, from two different Areas (the 850 series documents belong to MOIMS, the 200 series to SLS).
  *   The two MOIMS definitions are different from each other.
  *   The SLS definition identifies the packet as a PDU, but then describes its use but not its structure.
  *   Two of the three definitions are from Green Books, all should be from Blue or Magenta Books.
  *   The SLS definition is tied explicitly to the “TC Packetization Layer”, but the use and definition as we understand it is broader than that.

Also be aware that there is no definition of this term in the CCSDS Space Packet Protocol spec, CCSDS 133.0-B-2, which is where this PDU is defined (but not, strangely enough, the term “packet”).  This is a bit bizarre, but it is a fact.  The closest it comes, in my estimation, is this sentence in sec 2.1.1 Architecture:

“The Space Packet Protocol (SPP) is designed as a self-delimited carrier of a data unit (i.e., a Space Packet) that contains an APID used to identify the data contents, data source, and/or data user within a given enterprise.”
I could go on, but I hope you get the point.  We have not, in these recorded “formal” definitions adequately captured something as fundamental as “packet” and we are clearly not using one agreed definition in a consistent way.

Enter the “Terminology Expert Group” or (TEG).   For just our own purposes in CCSDS we need to get these terms sorted out.  Keeping this registry up to date is a task assigned to the CCSDS Chief Technical Editor, but that is more about adding new terms than it is fixing what is there (aside from the effects of newly updated standards).  We need to police this ourselves, but we have not been doing that.  The TEG has been identified, but not (yet) formed.

The inclusion of ISO TC20/SC14 terms in this registry brings in a whole new set of terms and challenges.  It also brings in (yes, there is a sort of Silver Lining here) a team in the Ukraine that has been doing a wonderful job of assessing the SC14 terminology set for consistency.  And they have tools and techniques in hand to do this (or they did…).  They have indicated that they are willing to bring their process to bear on the whole of the integrated Terms registry.  So this gives us some help in managing our problem too.

What is being proposed is to now form the TEG, with members drawn from both CCSDS and SC14.  This does not need to be a big group, I could even argue that smaller is better.  But we do need someone to lead this and 1-2 other CCSDS people to support it.  We are asking the SC14 to do the same.

I’m looking for volunteers.  Please, all of you WG chairs and Area Directors, see if you can’t identify someone who has an interest in this kind of work and is willing to work on this task.  Let me know who you identify.

Thanks, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg-all/attachments/20220513/e20f4ff4/attachment-0001.htm>