[CESG] Very quick follow up re registry updates policy implications

[Shames, Peter M (312B)]

Thanks Erik.  I agree with your assessment and with your statement of the intended purpose.

As an example, what this would mean for the MOIMS Nav WG CDM is this:

Now:

  *   In the CDM they defined a data structure that includes an "ORIGINATOR" data field
  *   The ORIGINATOR is defined like this "Creating agency or owner/operator (value should be registered in SANA). (See 5.2.9 for formatting rules.)"
  *   Examples are provided: JSPOC, ESA, CNES, NASA, SDC
  *   They reference a CATALOG_NAME of SATCAT and an OBJECT_NAME with examples like "SPOT, ENVISAT, IRIDIUM, INTELSAT"
  *   There is an ORIGINATOR registry (http://sanaregistry.org/r/cdm_originator/cdm_originator.html) that just has Keyword (name) and Meaning (like JSPOC) fields,
  *   There is a CATALOG_NAME registry (http://sanaregistry.org/r/cdm_catalog/cdm_catalog.html), it also has just Keyword, like SATCAT and Meaning, like "United States Strategic Command (USSTRATCOM) satellite catalog"
  *   Presumably the OBJECT_NAME are all registered in these catalogs, but this is not clearly stated and the names may only be relevant separately in each catalog
  *   Section 5.2.9, which is referenced for several of these fields, says this
  *

5.2.9 In the value fields for the keywords ORIGINATOR, MESSAGE_ID, OBJECT_DESIGNATOR, CATALOG_NAME and INTERNATIONAL_DESIGNATOR, values shall be given as alphanumeric text. The underscore "_" and dash "-" may also be used.

  *   The SANA Consideratins Section says this:
  *

The CDM XML schema;
A transform from the CDM XML to the CDM KVN version;
Values for the keywords ORIGINATOR and CATALOG_NAME; and
A list of options for the COLLISION_PROBABILITY_METHOD keyword.

  *   There is no clear definition for these registries nor for the fields that they should contain, as stated in the current SANA YB.

Assuming the revised SANA Enterprise registries and "registry re-use / adapt policy":

  *   In the CDM they defined a data structure that includes an "ORIGINATOR" data field
  *   The ORIGINATOR is defined like this "Creating agency or owner/operator (Organziation shall be registered in SANA Organization registry). (See 5.2.9 for formatting rules.)"
  *   Examples are provided: JSPOC, ESA, CNES, NASA, SDC (These will all have to be registered if they are not already)
  *   They reference a CATALOG_NAME of SATCAT and an OBJECT_NAME with examples like "SPOT, ENVISAT, IRIDIUM, INTELSAT"  (There is a list of Catalogs, but they are just catalog names, there should be URLs for them too and references to the Orgs that own them)
  *   There is an ORIGINATOR registry that just has the Keyword (name) and Meaning (like JSPOC) (Each ORIGINATOR org should be registered in the Organization Registry.  Ideally each of these specific orgs would also have the CDM Provider Role set.)
  *   The CDM would ask that the "CDM Provider Role" be created as an Org Role so that it could be assigned to an Org, or sub-org, as needed.
  *   There is a CATALOG_NAME registry, it also has just Keyword, like SATCAT and Meaning, like "United States Strategic Command (USSTRATCOM) satellite catalog" (The Catalog registry really should contain at least a URL and the Org that wons the catalog in the registry.
  *   Presumably the OBJECT_NAME are all registered in these catalogs, but this is not clearly stated and the names may only be relevant separately in each catalog (There should be some clear statement to the effect that each OBJECT_NAME and also OBJECT_DESIGNATOR is only defined in the context of the referenced CATALOG)
  *   Section 5.2.9, which is referenced for several of these fields, says this
  *

5.2.9 In the value fields for the keywords ORIGINATOR, MESSAGE_ID, OBJECT_DESIGNATOR, CATALOG_NAME and INTERNATIONAL_DESIGNATOR, values shall be given as alphanumeric text. The underscore "_" and dash "-" may also be used.

  *   5.2.10 The value fields for ORIGINATOR are found in the CCSDS Organization registry (SANA reference), the CATALOG_NAME is in the CDN Catalog registry (SANA reference), the OBJECT_Designator will be found in the related Catalog
  *   The SANA Consideratins Section says this:
  *   The CDM XML schema;
A transform from the CDM XML to the CDM KVN version;

Values for the keyword ORIGINATOR must be a valid CCSDS Organization name
Every CDM ORIGINATOR shall be registered in the CCSDS Organization Registry with the Org Role of CDM Provider
The CATALOG_NAME shall be registered in a CDM Catalog Name registry, which contains Catalog Identifier (current Keyword), Catalog Name (current Meaning), Organization Reference (to registered Org), and URL.  Field sizes and types should be defined (they are not now).
A list of options for the COLLISION_PROBABILITY_METHOD keyword.

So yes, there are a few lines of changes to the doc and to the registries.  This was discussed, in broad strokes, with the Nav WG chair, David Berry, and he agreed, at least conceptually, that being able to reference an esixting org structure would have been useful to them.  The full impact of each of these proposed changes would need to be discussed with the Nav WG.

What they do is to not change any of the data structures, but to add some specificity and to remove ambiguity.  Surely that cannot be a problem when what one is trying to do is to avoid two spacecraft colliding.

Best regards, Peter




From: <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>> on behalf of Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Date: Monday, July 13, 2015 at 10:13 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: [CESG] Very quick follow up re registry updates policy implications

CESG Colleagues,

As we ran out of time, an example of new registry policy relative to CDM (Conjunction data message):

Currently:  recommendation creates a registry of conjunction data message providers.

Future: recommendation will leverage agency registry to provide an enumeration value for a service provider attribute to identify conjunction data message providers.

The main implication is that future recommendation book bosses will need to be more aware of the information model in SANA.  The main goal is to ensure we are not creating overlapping (and potentially conflicting and/or incoherent) sets of registries.

Best regards,

-Erik


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150713/ecac55b8/attachment.html>