Policy

[mkaplun]

In the current Profile model, all parts of the Service Profile class presented as single classes. The only exceptions are Service Provider/Consumer and Policies classes. While Provider and Consumer classes will be reviewed in a separate issue, here we suggest the following changes for the Service Policies class.

1) For the reason lost now, it is unclear why the collection of policies (Service Policy) and a single item (Policy) are represented as two classes, unlike most of the other classes in Profile's package. For the sake of consistency and simplicity, we suggest creating a single class Policy with a multiplicity '0..*'.

2) This class which goal is to describe a single Policy associated with the described service, will have the following structure:

Where: id - An identifier by which a policy is uniquely identified. Note: the id may identify policy locally (in the context of a service description) or globally. The preferred format for the id is a URI, which may or may not be dereferenceable. name - A name of the policy. description - A description of the policy. source - A URI (URL) of the document that originates and/or prescribes the policy.

The example of values may look like the following:

id: http://policies//changes/notification name: Service Change Notification description: This policy requires a service provider to notify consumers about planned changes to the service at the beginning of the planning stage or six months prior to the target date on which the new version will become operational, whichever comes first. source: http://faa.gov/swim/governance/policies.pdf

The questions that probably need to be further discussed:

• Should a Policy's id be required?
• Should a Policy's name be required?
• Should at least a Policy's id or name (but not necessarily both) be required?

[wznira]

The questions that probably need to be further discussed:

• Should a Policy's id be required?
• Should a Policy's name be required?
• Should at least a Policy's id or name (but not necessarily both) be required?

I think there are two distinct concepts around "policy" -

• Globally, an organization such as the FAA SWIM Program will define policies that are applicable to a number of services. For example, a standard SWIM versioning policy could have an identifier such as http://swim.faa.gov/policy/versioning
• A service can indicate, in its profile, its compliance with the global versioning policy by having a Policy instance with an identifier such as http://faa.gov/services/fps#versioning_policy

Using RDF, we could express this as -

swim:versioning_policy a swim:Policy;
      swim:published 2022-10-01^xsd:date.

fps:versioning_policy a sdcm:Policy;
      sdcm:name  "versioning policy";
      sdcm:source swim:versioning_policy.

So, to answer @mkaplun's questions-

• I think a policy id should have an ID
• I think a policy name could be useful as well. But it could be optional.

[caroluri]

In my opinion, Policy name should be required, since the SDCM is supposed to "describe all relevant aspects of a service in a manner suitable for both human-readable and machine-processable representations". A human will rely on the name. Globally, there is no guarantee that the ID will incorporate elements of the policy's name, the way "http://swim.faa.gov/policy/versioning_policy" happens to do. (The alternative is to classify policies into descriptive categories, and I'm not sure where you would start.)