Suggest the following changes to the Profile Function class suggest the following changes:

• Adding the 'name' attribute (primarily for uniforming all classes).
• Attribute 'description' - no changes.
• Removing 'real world effect'. Using this attribute appears to have little (if any) actual value. As an alternative, it could be made optional.
  

or

To start up the development of the SDCM 3.0, here are the items that I would like to include.

• 1. All definitions should be revised to ensure they are consistent with our current vision and usage of the elements (e.g., the definitions of the Model.)

• 2. Geographical Extent (GeographicalExtent)
  To add class Geographical Extent (GeographicalExtent) as in the final version in [the issue "Model Geographical Extent in SDCM"] (#1 (comment))

• 3. Service Policy
  The Service Policy's structure is inconsistent with the structure of other Profile classes. Either other classes should be viewed as containers (like Service Policy now), or Service Policy should be redesigned to take on the appearance of other classes.

• #8
  Consider subclassing Quality of Service into two classes: Performance Quality and Data Quality. Both may extend Quality of Service, or some attributes may be added to Data Quality, depending on the unique characteristics of DQ.

• 5. Resource
  Resource class (classes) should be added to the Interface element to describe RESTful Web Services.

• 6. Security Mechanism
  Consider renaming to Access Control
  Add Security Mechanism Type (potentially taxonomy)
  Security Mechanism Protocol (e.g., OAuth, SSL)

• 7. Reexamine the current definitions/relationships among Payload, Data Entity, and Data Definition (a document). For example, a schema (a Data Definition document) can relate to all the entities in a payload [@caroluri].

Pretty self-explaining.

Correcting the error: unlike the current version of the SDCM, there is no association between the classes End Point and Interface.

OGC Testbed 13 and Testbed 14 explored ways to extend SWIM service descriptions to describe the information delivered in SWIM services and their quality attributes. For example,

• Information Registry work from OGC Testbed 14 included the introduction of a Data Set class (from DCAT ontology https://www.w3.org/TR/vocab-dcat-2/) with associated topics modeled after SKOS (https://www.w3.org/2004/02/skos/).
• Data Quality Specification work from OGC Testbed included the association of one or more Quality of Data objects with a Data Set, qualified by a scope. By default, the scope is dataset, meaning the Quality of Data is applicable for the entire data set. However, the scope can also be set to a subset of the data.

We should consider incorporating these concepts in SDCM. A notional concept is shown using the diagram below -

This issue continues the discussion about the Resource class that started at one of the off-line Governance meetings.

The most discussed point was whether to have an 'id' attribute similar to most SDCM classes.
But it was also argued that the attribute 'path' could be used because it uniquely identifies a resource.
According to OpenAPI,

Path holds the relative paths to the individual endpoints and their operations. The path is appended to the URL from the Server Object in order to construct the full URL.

It is important to notice that 'path' is represented by a relative URI, which means that multiple resources may have the same paths.

For example:

A resource offered by development and operational services may have the same URI.
Two resources, one is GETed, and another DELETEed may also have the same relative URI/URL, which raises the question of whether absolute URI can/should be used in SDCM.

Note: for the purpose of this discussion, we assume that an absolute URI provides a "physical" address to the resource, while the relative is a part of a URI that doesn't include a protocol (http) and server address.

Note: An absolute URI may also be described as one of the service endpoints and, therefore, can be presented in the Ground package.

According to Swagger's specification:

"For each path, you define operations (HTTP methods) that can be used to access that path. ... A single path can support multiple operations, for example, GET /users to get a list of users and POST /users to add a new user. OpenAPI defines a unique operation as a combination of a path and an HTTP method. This means that two GET or two POST methods for the same path are not allowed – even if they have different parameters (parameters have no effect on uniqueness)."

In SDCM 3.0, the class Resource is not associated with the class Operation. It also includes the non-defining attribute path, which has no relevance to the uniqueness of the Operation.

1. Is SDCM 3.0 can be interpreted in a way that is consistent with Swagger's architecture?
2. If not, should the UML be changed? If yes, then how? E.g., add association class?
3. Or is it best to keep the current SDCM as it is for potential future interpretations or extensions at either logical or physical levels?

Refer this ticket(#6 (comment))

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?

Using the classes described in other GitHub issues, this issue constructs the Profile SDCM package.

• Provider/Consumer
• Function
• Security Mechanism
• Policy
• Quality of Service - no change
• Geographical Extent
• Environmental Constraint - added optional 'name' (a label in essence.)

Note: some of these classes use "utility" classes, such as Organization, Taxonomy, and Document. These classes will be presented in a separate package (name TBD).

A separate issue will describe the package and its containing class Service Description.

To allow generation of a service overview (as shown in the example https://nsrr.faa.gov/printpdf/129/service-overview) from an SDCM-based service description, we need a way to describe service overview related properties in SDCM. This could be accomplished through a number of ways - For example, creating subclasses of Service Description or creating stereotypes/annotations for SDCM elements.

There seems to be a consensus that "Geographical Extent" can be specified either as a thing (e.g. an airport or an FIR) or a shape (e.g. a polygon). For example,

• From the draft SWIM Manual - "Guidance: Geographical coverage may be expressed in terms of ICAO region, FIR, Aerodrome, polygon/geobox, etc."
• Similarly, W3C defines two related concept: Geospatial Thing and Geometry

It seems the first approach ("Geographical Extent" as a Thing) can be accomplished easily by treating it as another Service Category Taxonomy. For example, in JSON,

"service-description": {
   "profile": {
      "service-id": "http://nsrr.faa.gov/services/fps",
      "name": "Flight Plan Service (FPS)",
      "description": "(This fictitious service is for instructional use only and cannot be consumed) A service for filing, updating, or canceling an IFR (Instrument Flight Rules) flight plan.",
      "version": "1.0.0",
      "service-category": [
         {
            "taxonomy": "http://semantics.aero/service-category",
            "code": "http://semantics.aero/service-category#flight"
         }
      ],
"geographical-extent": [
   {
       "taxonomy": "http://semantics.aero/geographical-extent",
       "code": "http://semantics.aero/icao-region/nam"
   },
   {
       "taxonomy": "http://semantics.aero/geographical-extent",
       "code": "http://semantics.aero/icao-region/asia"
   }
],
... ...

For the second approach, the easiest way seems to be referencing the "Geometry" class defined in OGC GML as shown in the UML diagram below-

The proposed vision of SDCM's Model part aims to streamline and increase abstraction levels.

The following is the list of the proposed changes:
Model Package

• Interface:

Adding Category attribute of type Taxonomy.
Note: the SDCM here does not prescribe the specific taxonomy; it can be done in the future in the context of human or formal language documents.

• Operation:

Idempotency is removed as it is of little or no use.
Synchronicity is replaced with Boolean 'synchronous'.
Message Exchange Pattern is replaced with an attribute of type Enumeration (see Note for the Category attribute in the Interface class).
Processing Consideration is removed as it is of little or no use.

• Message:

No changes at all.

• Fault:

The Fault class is an extension of the class Message and therefore inherits all Message attributes, but the value of attribute 'direction' is constant 'out'. (Assigning values to the attributes in the conceptual model may require further considerations.)

• Header:

The current classes Header and Header Fields are combined into one, similar to the approach applied to Profile classes. Every instance of the Header now represents a single header field related by one-to-many to the Message.
Header attributes allow name-value pairs to be described optionally accompanied by brief descriptions.

• Payload:

The Payload Type is rendered as an attribute of type Enumeration, similar to the approach used in the Operation class. See also Note for Interface's Category.

• Data Entity:

Associated Data Definition class is replaced with the attribute 'source' of type Document that points to either the human or machine-processable document that defines the Data Entity (e.g., XML schema, data standard).

REST Package:
The purpose of grouping REST-specific classes in a package is to show that they belong to a different family of classes while also demonstrating that they are parts of the Model (a kind of interface).

• Method:

The Method class is a specialization of the class Operation. It inherits all Operation's attributes with the only distinction that the value of 'name' in the Method must be one of the "HTTP methods" enumeration (not shown but described in the model.)
Note: all classes are derived from "Service Description Conceptual Model (SDCM) Extension for REST-style Web Services"

• Resource:

Attribute 'id' is added. It could be either an absolute or relative URI of the Resource. It also, in some cases, may have the same value as the attribute 'path'.

• Parameter:

The enumeration 'type' is included as a class attribute.

• Representation:

No changes. However, it should be considered whether Representation information is redundant with the information provided by the attribute 'source' in the Data Entity class.

In SDCM 3.0, as it is currently rendered in multiple classes, there are two very similar classes: Taxonomy and Enumeration.
Taxonomy is defined as

A controlled list of well-defined concepts organized into a hierarchical structure.

An Enumeration doesn't have a formal definition in the model but is generally understood as

A listing of possible values for an attribute.

Both concepts serve the same purpose: to limit elements or attribute values to a predefined, finite set. Probably, it can be said that an Enumeration in SDCM is a simple (non-hierarchical) form of Taxonomy. Also, an Enumeration is always defined inline, inside a model or schema, whereas a Taxonomy is defined outside of a model and exists as a stand-alone entity.

The question: should we continue to use two classes and accordingly define them both, or use a single class Taxonomy with the understanding that it may be defined either inside or outside a model/schema and be both hierarchical or non-hierarchical?

The goal of the proposed modification is to streamline the existing Provider and Consumer model.

All elements of the Profile package are presented (or will be presented) by a single class, and for consistency's sake, the Provider and Consumer classes should be presented similarly.

Therefore:

Accordingly, the Organization class can be presented outside the Profile model, along with the classes Document, and Taxonomy, in some TBD package, e.g., Utility.

Note, in this version of the Organization class, the attribute Web Page is replaced with the attribute id. It is safe to assume that every organization has a URI, which is almost always the URL of the organization's web page.

Something to consider: every POC can be uniquely identified (and usually does) by email.

Currently in SDCM 2.0, Quality of Service is a class under Profile, with the fields:
name
description
value
calculation method
unit of measure

With the new development of SLA template our team made, we may want to reflect those information into SDCM.

A proposed solution is to extend the class of "Quality of Service" in Profile, with the information from SLA template, such as availability, capacity, response time, mean time to restore, notification, service maintenance, change control, versioning, documenting, etc.

Advanced services represents service fusion and service filtering.

Service fusion tries to combine the responses from multiple services into a merged/single response. The fusion service could be a new service.

Service filtering can either filtering the recorders from the original response, or filtering out fields/properties from the original response. The filtering service could be a new service.

Both fusion service and filtering service are different with the original services. They are more like derived services. A proposal solution is to create a new class in Profile, for example, service type: original service, fusion service, or filtering service.

At the same time, since Testbed 18 is implementing a POC about service filtering, we may want to implement this change after TB 18 finishes.

In SDCM REST Extension, we had a class structure as shown in the diagram below -

I believe we should have similar relationships between Resource, Representation, Payload and Data Classes -

• Resources are the basic building block of a RESTful service. For example, a flight plan or a feature in Web Feature Service that presents a real world thing such as an airport. A resource is identified by a URI.
• Representation is a machine readable document about that resource that is carried by web services, for example, an XML document of feature data that has the encoding of en/us.
• A Representation is carried in a Payload. However, for a service like Web Feature Service, a response may carry multiple features. Each feature is a representation of some resource. For example, NCR may return aeronautical information and weather information in a single response.
• A Representation can be considered a special case of data. For example, a representation of flight plan may follow the FIXM standard, such can be used to describe any payload data. In that case, we can make Representation a subclass of Data.

Diagram below may be applicable -