SDCM 3.0 Wish List

[mkaplun]

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"] (https://github.com/faa-swim/sdcm/issues/1#issue-1055207542)

• [ ] 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.

• [x] #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].

[wznira]

I agree with @mkaplun's proposed SDCM 3.0 changes.

[caroluri]

I agree with the wish list. In addition, suggest that current definitions/relationships among Payload, Data Entity, and Data Definition (a document) be reexamined. For example, a schema (which is a Data Definition document) can relate to all the entities in a payload. NSRR does not relate individual Payload entities to their source schemas.

[wznira]

@swang-nira suggested -

One suggestion about quality of service, besides performance quality and data quality, how about adding the related SLA content? It contains more information than performance quality.

To model SLA, we could leverage research on machine-readable SLAs and SLA ontologies such as

• Towards Automated SLA Management for Web Services
• Automatic Extraction of Metrics from SLAs for Cloud Service Management
• A WS-Agreement Based SLA Ontology for IoT Services

[mkaplun]

RE: comment item 5 by @mkaplun This document describes the "greatest and latest" on adding Resource-related classes to the SDCM. The question is whether and how the changes suggested by @caroluri will affect this model.

Source: SDCM REST Extension 1.0 2020-05-20b.docx

[caroluri]

Re: Data Definition document (DDD): since the purpose of the DDD is to explain the meaning of the business data or Payload so that it can be interpreted correctly, I would say the DDD should relate directly to Payload. If it happens that a Payload has entities (e.g. flight info and weather info) that are described in different DDDs, maybe the relationship between Entity and DDD should also be preserved in SDCM, but in any case the individual DDDs are only meaningful in the context of the whole payload (e.g., weather forecast at flight destination/ETA). I don't think changing the relationship would affect the REST extension, since the DDD helps describe the Payload that the Representation carries.

[mkaplun]

RE: https://github.com/faa-swim/sdcm/issues/6#issue-1363054544 After reviewing the SDCM, I realized that it is actually not one but two coupled models: one is a service description model, and the other is a service model. The former consists of four elements Service Description, Profile, Model, and Grounding. The latter consists of all other SDCM elements representing a service's characteristics or parts, e.g., QoS, Interface, Binding, etc. In other words, the service description model is essentially a hierarchy of containers (packages) that contain service components.

This line of thinking will affect the existing SDCM layout and some definitions. For example, the Profile package can be described as "The part of service description that describes the parties responsible for providing the service, what is accomplished by the service, and limitations on service applicability." Or "the package that contains information about the non-functional characteristics of the service, such as parties responsible for providing..."

The structure of the new version of the SDCM make look like the following (for the sake of brevity, only top level service classes are shown):

[swang-nira]

RE: the comment posted by @mkaplun

That's a very interesting idea, Mark. At the same time, could you confirm if I understand correctly? Basically to say, you want to move some information (for example, service name, service id, service description, service version and service category) from current Profile class to a new class -- Service class. If that's the case, not quite sure if we want to or need to create this new Service class (unless you have more thoughts about it), since the combination of Profile, Model and Grounding will be a Service. In another word, they are describing the service from different viewpoints.

Just my two cents, Sam

[mkaplun]

RE: https://github.com/faa-swim/sdcm/issues/6#issuecomment-1241949567 posted by @swang-nira The Service class already exists in SDCM.

[swang-nira]

RE: https://github.com/faa-swim/sdcm/issues/6#issuecomment-1241953814 posted by @mkaplun

That's right, the Service class exists in SDCM document, but not shown up in the class diagram. Is there any particular reason for that?

[caroluri]

In my opinion, the SDCM should be what its name implies: a model of everything that describes a service. The service description can be compared to a resource like a book. And like a book, it has bibliographical identifying attributes including a title (= service name), version, unique identifier, brief description, subject category (= service category), publisher (= FAA NSRR), etc.; and it has contents. The contents are arranged in chapters or sections (= profile, model, grounding). So yes, maybe the identifying attributes of the service description shouldn't be included in "Chapter 1 - Profile" the way they are in the current SDCM.

I believe that the class "Service" is defined in the current SDCM as an abstract concept because it is the thing being described by the Service Description. It is not in the current SDCM Service Description diagram because its attributes were put into the Profile. If it's decided to separate the identifying attributes (service name, ID, version, etc.) from the Profile, should this new class be called "Service"? Not sure about that but it's OK with me.

[swang-nira]

RE: https://github.com/faa-swim/sdcm/issues/6#issuecomment-1242273957 posted by @caroluri

Thanks for the comments, Carol. I will create a new SDCM class diagram based on Mark's suggestion, so that we can discuss about it next Monday.

[swang-nira]

Below please check the changes for Service and Profile.

[mkaplun]

RE: the comment by @caroluri

If we continue to build on this analogy:

• A Service Description is a Book.
• A Book has a Cover with identifying information (Author, Title, Year of publication, ISBN on the back).
• Inside, the Book has Chapters (or Parts that may contain Chapters).
• Information on the cover is not a part of any Chapter; we can think of a Cover as a container. Although if the title says "Harry Potter and the Philosopher's Stone," the content of the Book must be about Harry Potter, just like if the Service Description has an attribute "service name=FPS," then the document must be about Flight Plan Service.

So if we go back to the proposed model, it may look like this: Can we say that we may have two models: Book Model and Fictional Character Model?

[wznira]

Can we say that we may have two models: Book Model and Fictional Character Model?

I think @mkaplun is right - we do have two models. One is about the book itself, another is about the content of the book, sort of like this -

The Book model has concepts like Chapter and Publisher, while the Story mode has concept like Character and Author. Interestingly, we could have a movie about the same Harry Potter story. So we can have a Movie model has concepts such as Movie and Studio, like this -

I think we have similar distinctions in SDCM -

• We have a Service that is in many ways similar to a Book. It is a way to deliver the content - Data. Just like books can have paperback or hardcover that sell at different prices, we can have different services delivering the same data with different QoS.
• Data is in many ways similar to the Story. The consumer gets data through a Service.
• Resources and APIs can be considered similar to a Movie. They are ways to deliver the same Data.

[caroluri]

I thought about it over the weekend too and believe that my view was somewhat wrong to equate bibliographical attributes of the service description resource (e.g. title, version) to the name and version of the service itself. They are separate things. An instance of a service description document, such as (but not limited to) a WSDD, JMSDD, WSDL file, Service Overview, or NSRR HTML view is a resource. Each one has a title or filename plus other info dictated by the standard or specification it adheres to -- for instance, a WSDD's cover page has an FAA signature, title consisting of Web Service Description Document followed by service's name, service version, WSDD generation date, optional WSDD revision number, etc. The content of the service description document is a representation of the service. In the FAA, the WSDD, JMSDD, and NSRR views are all consistent with SDCM, which was itself influenced by other standards. For instance, our first edition of FAA-STD-065 section 4.2 Structure said the following:

• The “front matter” portion of the WSDD – i.e., cover page, table of contents, definitions, etc. – is consistent with conventions and regulations established for FAA documents. This portion is described below in the Detailed Requirements sections 5.1 through 5.7.
• The “core” portion of the WSDD is described in section 5.8, Web Service Properties and Capabilities. It closely follows the structure of the Service Definition Framework set forth by MITRE [25], which in turn uses the concepts and relationships defined in the OWL-S document [23] acknowledged as a Member Submission by the World Wide Web Consortium (W3C). It is composed of three logical parts: Service Profile, Service Interfaces and Service Implementation. Each of these represents an essential part of knowledge about the web service and may serve different needs for the users of a WSDD.

The current SDCM is closely related to the "core" portion. The fact that it is divided into 3 sections (profile, model/interfaces, and grounding/implementation) is because of earlier recommendations and industry standards. The Service Name and ID are placed in the profile section because that is what a profile is: a set of characteristics developed for use in identifying persons or things as being likely to belong to a certain group (Websters). Carol

On Sun, Sep 11, 2022 at 4:14 PM Wen Zhu @.***> wrote:

Can we say that we may have two models: Book Model and Fictional Character Model?

I think @mkaplun https://github.com/mkaplun is right - we do have two models. One is about the book itself, another is about the content of the book, sort of like this - [image: image] https://user-images.githubusercontent.com/28628680/189546730-17dccd64-bfa9-4657-bcf1-5b01a5e102eb.png

The Book model has concepts like Chapter and Publisher, while the Story mode has concept like Character and Author. Interestingly, we could have a movie about the same Harry Potter story. So we can have a Movie model has concepts such as Movie and Studio, like this - [image: image] https://user-images.githubusercontent.com/28628680/189546932-a4256ab6-47ad-4b54-ae37-8f7b25753840.png

I think we have similar distinctions in SDCM -

• We have a Service that is in many ways similar to a Book. It is a way to deliver the content - Data. Just like books can have paperback or hardcover that sell at different prices, we can have different services delivering the same data with different QoS.
• Data is in many ways similar to the Story. The consumer gets data through a Service.
• Resources and APIs can be considered similar to a Movie. They are ways to deliver the same Data.

— Reply to this email directly, view it on GitHub https://github.com/faa-swim/sdcm/issues/6#issuecomment-1243034944, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWKW6CH5WSVRSDVHZD34EMTV5Y4T7ANCNFSM6AAAAAAQFVXC5U . You are receiving this because you were mentioned.Message ID: @.***>

[mkaplun]

I think what we have in the comments by @wznira and @caroluri somehow confirms the vision presented in this comment. Following Carol's thoughts, I revisit the original version of STD-065. That document shows that we actually try to "couple" two models: standard (FAA-STD-068, FAA Standard for Preparation Standards), and various indistry models (OWL-S, WSDL, long-forgotten MITRE work, and even UDDI). Here are couple of pictures from the original 065 period. They clearly show the STD-068 model coupled with the OWLS-like model.

Figure 1 Standard Model with little awkwardly attached Service Model

Figure 2 Service Model coupled with Standard. Note: these diagrams are from pre-SDCM time.

Circling back to the Container notion, we can say that all those WSDD, WSDL, OWL-S, and NSRR are different representations of the same content, just like "Hamlet" can be a book, a play in a theater, a movie, and even a comics. So, I don't see much disagreement in the comments. It appears that the major difference is whether Profile is a container like Model and Grounding (note, both are empty) or a class. And whether Service (and not a Service Description) is a root element that holds identifying information (like a book cover).

[caroluri]

For the record, I believe that a "Service" is a class, like "Person" or "Hurricane". Each instance of Service has a unique ID and a name and other attributes, and it can have any number of books written about it or associated with it. I also believe that SDCM is a model for an artifact that describes and presents the attributes of a service in a complete and comprehensive way so that a human user can understand and use the service. Profile, Model, Grounding are arbitrary (and hopefully logical) ways of presenting the attributes for easier understanding. To learn about a service registered on NSRR, we would be directed to its profile. For instance, the unique ID of FPS is http://nsrr.faa.gov/services/fps http://nsrr.faa.gov/services/fps but the URL of FPS on NSRR -- its NSRR description -- is https://nsrr.faa.gov/services/fps/profile https://nsrr.faa.gov/services/fps/profile and that is where we are redirected. However, if we were to describe a service in machine language, we would not need to include the notions of Profile or Model or Grounding. So a Service Conceptual Model (SCM) would not need these containers. In an SCM, the service ID would be an attribute of Service. For SDCM, the service ID should be part of the Profile. That's my opinion, anyway. But putting service ID on the cover of the book, so to speak, is also a choice.

On Mon, Sep 12, 2022 at 8:53 AM mkaplun @.***> wrote:

I think what we have in the comments by @wznira https://github.com/wznira and @caroluri https://github.com/caroluri somehow confirms the vision presented in this comment https://github.com/faa-swim/sdcm/issues/6#issuecomment-1241830312. Following Carol's thoughts https://github.com/faa-swim/sdcm/issues/6#issuecomment-1243055750, I revisit the original version of STD-065. That document shows that we actually try to "couple" two models: standard (FAA-STD-068, FAA Standard for Preparation Standards), and various indistry models (OWL-S, WSDL, long-forgotten MITRE work, and even UDDI). Here are couple of pictures from the original 065 period. They clearly show the STD-068 model coupled with the OWLS-like model.

[image: Structure of FAA Standard] https://user-images.githubusercontent.com/91625618/189656343-04ba9496-86b3-4116-80cd-5a1347c2b303.png Figure 1 Standard Model with little awkwardly attached Service Model

[image: Service model] https://user-images.githubusercontent.com/91625618/189656477-c0a91f22-12ba-4301-a5fe-2ec927b8afd0.png Figure 2 Service Model coupled with Standard.

Circling back to the Container notion, we can say that all those WSDD, WSDL, OWL-S, and NSRR are different representations of the same content, just like "Hamlet" can be a book, a play in a theater, a movie, and even a comics https://www.pinterest.com/pin/395683517258275004/. So, I don't see much disagreement in the comments. It appears that the major difference is whether Profile is a container like Model and Grounding (note, both are empty) or a class. And whether Service (and not a Service Description) is a root element that holds identifying information (like a book cover).

— Reply to this email directly, view it on GitHub https://github.com/faa-swim/sdcm/issues/6#issuecomment-1243698306, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWKW6CH5XIBEGEXDYANHHSTV54RWBANCNFSM6AAAAAAQFVXC5U . You are receiving this because you were mentioned.Message ID: @.***>

[mkaplun]

I'm afraid I have to disagree with some of the points in @caroluri comment, but the good news is that there are not many of them.

For the record, I believe that a "Service" is a class, like "Person" or "Hurricane". Each instance of Service has a unique ID and a name and other attributes, and it can have any number of books written about it or associated with it. I also believe that SDCM is a model for an artifact that describes and presents the attributes of a service in a complete and comprehensive way so that a human user can understand and use the service. Profile, Model, Grounding are arbitrary (and hopefully logical) ways of presenting the attributes for easier understanding.

Agree with every word. To learn about a service registered on NSRR, we would be directed to its profile. For instance, the unique ID of FPS is http://nsrr.faa.gov/services/fps http://nsrr.faa.gov/services/fps but the URL of FPS on NSRR -- its NSRR description -- is https://nsrr.faa.gov/services/fps/profile https://nsrr.faa.gov/services/fps/profile and that is where we are redirected.

This is because the NSRR has been designed this way, which is not necessarily the correct way. More logically would be, when a user chooses to go to FPS, she should be redirected to FPS's "Home Page," which would have links to the service Profile, Model, and Grounding pages. And this Service page may also contain some identifying information (id, name, version, etc.).

However, if we were to describe a service in machine language, we would not need to include the notions of Profile or Model or Grounding. So a Service Conceptual Model (SCM) would not need these containers.

As a matter of fact, the concepts of Service, Profile, Model, and Grounding are taken from the OWL-S ontology developed in OWL. And the Model and Grounding sections were inspired by another machine-processable model, WSDL, which also has several "containers." And there are more popular machine-processable models that present information in logical groups (e.g., WADL, OpenAPI). So, it seems that logical grouping is used in all realizations of a service description (except "Service Overview").

As far as I can tell, the only questions where we have not reached an agreement are:

1. The SDCM's UML should include the Service class,
2. Whether SD, Profile, Model, and Grounding should be visualized as packages (containers),
3. What information/attributes (if any) should be included in the Service class?

My vote remains: "yes," "yes," and "service id, service name, version, textual description."

[caroluri]

I just have a couple more questions. The first is, assuming the Profile is a container, should the Profile contain the Service class, the way it contains the Provider class? I would think yes; the Profile itself would have no attributes, the way Model and Grounding have no attributes. The second is, should the Taxonomy (e.g. SWIM Service Category, Interface type, Availability Status) be associated with the Service class? I would think yes.

On Tue, Sep 13, 2022 at 7:10 AM mkaplun @.***> wrote:

I'm afraid I have to disagree with some of the points in @caroluri https://github.com/caroluri comment, but the good news is that there are not many of them.

For the record, I believe that a "Service" is a class, like "Person" or "Hurricane". Each instance of Service has a unique ID and a name and other attributes, and it can have any number of books written about it or associated with it. I also believe that SDCM is a model for an artifact that describes and presents the attributes of a service in a complete and comprehensive way so that a human user can understand and use the service. Profile, Model, Grounding are arbitrary (and hopefully logical) ways of presenting the attributes for easier understanding.

Agree with every word.

To learn about a service registered on NSRR, we would be directed to its profile. For instance, the unique ID of FPS is http://nsrr.faa.gov/services/fps http://nsrr.faa.gov/services/fps http://nsrr.faa.gov/services/fps http://nsrr.faa.gov/services/fps but the URL of FPS on NSRR -- its NSRR description -- is https://nsrr.faa.gov/services/fps/profile https://nsrr.faa.gov/services/fps/profile and that is where we are redirected.

This is because the NSRR has been designed this way, which is not necessarily the correct way. More logically would be, when a user chooses to go to FPS, she should be redirected to FPS's "Home Page," which would have links to the service Profile, Model, and Grounding pages. And this Service page may also contain some identifying information (id, name, version, etc.).

However, if we were to describe a service in machine language, we would not need to include the notions of Profile or Model or Grounding. So a Service Conceptual Model (SCM) would not need these containers.

As a matter of fact, the concepts of Service, Profile, Model, and Grounding are taken from the OWL-S ontology developed in OWL http://www.w3.org/Submission/2004/SUBM-OWL-S-20041122/Service.owl. And the Model and Grounding sections were inspired by another machine-processable model, WSDL https://www.w3.org/TR/2007/REC-wsdl20-20070626/#Syntax-Summary, which also has several "containers." And there are more popular machine-processable models that present information in logical groups (e.g., WADL, OpenAPI). So, it seems that logical grouping is used in all realizations of a service description (except "Service Overview").

As far as I can tell, the only questions where we have not reached an agreement are:

1. The SDCM's UML should include the Service class,
2. Whether SD, Profile, Model, and Grounding should be visualized as packages (containers) https://github.com/faa-swim/sdcm/issues/6#issuecomment-1241830312,
3. What information/attributes (if any) should be included in the Service class?

My vote remains: "yes," "yes," and "service id, service name, version, textual description."

— Reply to this email directly, view it on GitHub https://github.com/faa-swim/sdcm/issues/6#issuecomment-1245256896, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWKW6CBD4DZ3DOLUEIX7IFTV6BOKBANCNFSM6AAAAAAQFVXC5U . You are receiving this because you were mentioned.Message ID: @.***>

[wznira]

If we have a Service class, then what will be left in the Service Description class other than a Global Registry ID (GRID)? Within Profile, Provider, Consumer, Policy, QoS, etc all describe a Service not a Service Description. A Model describes how a client interact with a Service not a Service Description. So it seems having both Service and Service Description classes will be redundant.

[mkaplun]

To begin with, I believe that we need to ensure that we understand the notion of a UML package in the same way.

A package is a grouping of related UML elements, such as documents, classes, or even other packages.

Based on the diagram in the comment that started this entire discussion, Service Description (SD) is an all-encompassing (top-level) package. In accordance with the definition above, it can contain classes and other packages, which in turn may contain other classes (or other packages).

(In our earlier comments we also thought of the SD as a book composed of parts or chapters whose purpose is to organize book content into logical groups to make it easier for a reader to understand and follow the book. According to this analogy, we viewed the Service class as a book cover that traditionally contains the name of the author, the year of publication, and other book-identified information.)

Therefore, we can render Service Description as a package that includes the class Service (and possibly associated Service Category class), and the packages Profile, Model and Grounding. Each "low-level" package will include classes related to a respective topic.

To answer the comments:

@caroluri wrote:

The first is, assuming the Profile is a container, should the Profile contain the Service class, the way it contains the Provider class? I would think yes; the Profile itself would have no attributes, the way Model and Grounding have no attributes.

The Service Container is a package and it should contain the Service class. (A book cover is a part of the book, and not a part of a book's chapter.)

The second is, should the Taxonomy (e.g. SWIM Service Category, Interface type, Availability Status) be associated with the Service class? I would think yes.

Yes, it should. The diagram shows this association, although it may require more considerations.

@wznira wrote

If we have a Service class, then what will be left in the Service Description class other than a Global Registry ID (GRID)? Within Profile, Provider, Consumer, Policy, QoS, etc all describe a Service not a Service Description. A Model describes how a client interact with a Service not a Service Description. So it seems having both Service and Service Description classes will be redundant.

The Service Description is a package that contains class Service. It can be visualized as RDF triple: 'Service Description' describes Service. The diagram shows this in UML. There is no redundancy.

[caroluri]

Thank you for the latest diagram; that answers my questions. I think we can still say that NSRR complies with SDCM; the fact that NSRR puts the service class attributes (the book cover) in the profile is just for readability; the "Profile" page is really the "Service" page.

On Wed, Sep 14, 2022 at 1:59 PM mkaplun @.***> wrote:

To begin with, I believe that we need to ensure that we understand the notion of a UML package in the same way.

A package is a grouping of related UML elements, such as documents, classes, or even other packages.

Based on the diagram in the comment that started this entire discussion, Service Description (SD) is an all-encompassing (top-level) package. In accordance with the definition above, it can contain classes and other packages, which in turn may contain other classes (or other packages).

(In our earlier comments we also thought of the SD as a book composed of parts or chapters whose purpose is to organize book content into logical groups to make it easier for a reader to understand and follow the book. According to this analogy, we viewed the Service class as a book cover that traditionally contains the name of the author, the year of publication, and other book-identified information.)

Therefore, we can render Service Description as a package that includes the class Service (and possibly associated Service Category class), and the packages Profile, Model and Grounding. Each "low-level" package will include classes related to a respective topic. [image: SDCM Packages v 2] https://user-images.githubusercontent.com/91625618/190227239-b86ce57b-e3df-4c38-872c-6652c9c1ac20.png

To answer the comments:

@caroluri https://github.com/caroluri wrote:

The first is, assuming the Profile is a container, should the Profile contain the Service class, the way it contains the Provider class? I would think yes; the Profile itself would have no attributes, the way Model and Grounding have no attributes.

The Service Container is a package and it should contain the Service class. (A book cover is a part of the book, and not a part of a book's chapter.)

The second is, should the Taxonomy (e.g. SWIM Service Category, Interface type, Availability Status) be associated with the Service class? I would think yes.

Yes, it should. The diagram shows this association, although it may require more considerations.

@wznira https://github.com/wznira wrote

If we have a Service class, then what will be left in the Service Description class other than a Global Registry ID (GRID)? Within Profile, Provider, Consumer, Policy, QoS, etc all describe a Service not a Service Description. A Model describes how a client interact with a Service not a Service Description. So it seems having both Service and Service Description classes will be redundant.

The Service Description is a package that contains class Service. It can be visualized as RDF triple: 'Service Description' describes Service. The diagram shows this in UML. There is no redundancy.

— Reply to this email directly, view it on GitHub https://github.com/faa-swim/sdcm/issues/6#issuecomment-1247120270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWKW6CHIPZMLKYG45ABBHN3V6IHA3ANCNFSM6AAAAAAQFVXC5U . You are receiving this because you were mentioned.Message ID: @.***>

[mkaplun]

RE: comment by @caroluri

NSRR's interface can be modified; it's been done before. Of course, this change alone does not justify such an effort, but it could be one of many that will do.