Discussion 5.0 - Semantic Infrastructure Functional Requirements (No topics)

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="fd0a9860-f116-4f7a-9433-08138f9cd082"><ac:plain-text-body><![CDATA[

Section 5: Semantic Infrastructure Functional Requirements

In the paragraph after the bullets it says, "CBIIT has also adopted a formal approach, [ECCF]…" But, let's be clear, SAIF and ECCF are still being actively developed. So, really CBIIT is *collaboratively defining* a formal approach.

]]></ac:plain-text-body></ac:structured-macro>

Section 5 > Artifact Management > Types of Artifacts > Static Models

This section has many problems. HL7 MIF, UML and 11179 are not Information models. They are metamodels. That is, they provide a vocabulary for expressing other models. HL7 RIM, BRIDG, and LS-DAM are not metamodels. Instead, they can (with proper transformation to formal representation) be used as upper ontologies which constrain the semantics of lower-level ontologies. OWL and RDF are knowledge representation languages. They both have multiple serializations (syntactic models).

Section 5

The sentence "In addition, Semantic Infrastructure 2.0 will fully support existing caDSR users, including supporting forms created in caDSR" introduces a whole bunch of new requirements that are not mentioned further in this Functional Requirements section; it deserves more explanation than one sentence, if only to highlight that the requirements in Section 5 implicitly also import the support for caDSR users.

Section 5 > Artifact Management

When the management services allows - should be "service".

Section 5 > Artifact Management > Types of Artifacts > Behavioral Models

One has to be careful here what to call the "behavior of services". As indicated in, e.g., the HL7 Behavioral Framework (by John Koisch), behavior is "A collection of interactions with a set of constraints on when they can occur in a given Working Interoperability/business process context". In other words writing something like "Behavior of services provides an unambiguous definition of the service constraints, capabilities, dependencies, and interactions" is vague and probably not in-line with the SAIF. For example, capabilities of services indicate what the service does, not how it does it (the behavior). Listing "Orchestration and Workflows", as well as "Business Rules" under Dynamic Models is too vague compared to the approach under static models where technologies such as OWL etc are explicitly mentioned. What kind of Business Rules, what kind of orchestration and workflows? What are the technologies?

Section 5 > Artifact Management > Types of Artifacts > Content

Content is a vague term, everything is content. In particular one should not define it as "Content includes all unstructured text and other forms of content...". This is circular. The "Content" paragraph suffers from vagueness. "Content includes: images and other representations of static content". So, content is also static models?

Section 5 > Artifact Management > Types of Artifacts > Artifact Management Functions

Does managing the lifecycle, governance and versioning of the models, content and forms also include the Specification Content from the previous paragraph?

Section 5 > Service Discovery and Governance

It states "Service discovery and governance allows service developers to specify rich metadata about services". This should be the other way around: specify rich metadata about services allows service discovery? It states "Service discovery and governance help to accomplish the following:" where the last bullet is "Enable better discovery". This is circular and similar to the above, it is the expressing of rich metadata that enables better discovery.

Section 5 > Service Discovery and Governance > Service Discovery Functions

The discovery functions are rather implementation-level (involving service endpoints and service interfaces). What about the discovery of services based on a declaratively specified goal or task and the rich metadata of services using semantic reasoning?

Section 5 > Clinical Data Forms Definition and Modeling

Should "planed" be "planned"?

Section 5 > Clinical Data Forms Definition and Modeling > Clinical Data Form Functions

The clinical data form functions mention "manage lifecycle, governance, and version of forms and document schemas". This seems to already have been captured in the Artifact Management Functions: "manage lifecycle, governance and versioning of the models, content and forms". The listed use cases that drive these requirements are not explained further (compared to the previous sections).

Section 5 > Decision Support and Reasoning

The "identify sources of valued information" paragraph is not clear. For example, "the services, models, and annotations provide definitions which can identify candidate sources for integration". Integration of what and what for?
Crucial in the "common representations and transformations" paragraph is the concept of "common representation". This is not reflected in the paragraph itself (where consistency is mentioned). A common representation comes before anything (this or, as rightly mentioned, transformations between representations). Consistency is secondary, in the sense that if an appropriate common representation is chosen (say OWL-DL), then consistency will be verifiable by reasoners.
In "support for classification", if one mentions description logics and business rules here, one should probably also mention logical rules (e.g., RIF-BLD).
"the decision support system should be able to applied" should be "the decision support system should be able to be applied"
The sentence "Because of the complexity of the reasoning requirements, the OWL 2 specification is required in order to support the Semantic Infrastructure 2.0" is highly debatable. First, the reasoning requirements would not lead to the use of OWL 2 per se. The expressiveness needed for representing semantic metadata might call for OWL 2, but reasoning requirements would boil down to reasoning tasks such as subsumption checking, satisfiability checking, consistency checking, query entailment, etc, for which the complete OWL 2 would most likely be impractical. Indeed general reasoning tasks with OWL 2 (the DL variant) are NEXP or higher (nondeterministic exponential, which is worse than exponential). It seems not appropriate to mention here that the OWL 2 standard will be required. More likely, one wants to resort to less expressive variants of full OWL 2 (such as the tractable OWL 2 profiles) to ensure scalability. Tasks like composition prove to be intractable when the language of the background ontologies is too expressive (which includes OWL 2).
Phrases like "choreography layered fashion" are vague and without meaning.

Section 5 > Decision Support and Reasoning > Decision Support Functions

The decision support functions are on a very specific technical level, and, given this granularity, they seem incomplete. For example, why mention "providing scheduling and access information to choreographer", if you do not mention how choreography itself would work -- or for that matter how it is defined?
The function "execute reasoning systems against gathered data providing classification and additional data" is meaningless: what is additional data? Why are functions that would actually enable the service discovery, as described before, not mentioned?
Use case bullets that drive these requirements are not providing any explanation.

Section 5 > Conformance Testing

Sometimes "insures" is used throughout the text, sometimes "ensures".

Section 5 > Conformance Testing

Service registries are mentioned separate from the artifact registry; where is this defined (not before this point it seems?); I had the impression that the artifact registry also serves as a service registry.

Section 5 > caGRID 2.0 Platform and Terminology Integration > Service Generation

Service generation is defined as the ability to generate services from user defined service metadata. I think this is too ambitious, what kind of data should the user provide such that you will generate a service? This seems more something like Service discovery: based on the user defined requirements for a service you present the user with a set of services that satisfy these requirements.

Section 5 > caGRID 2.0 Platform and Terminology Integration > Service Discovery

The terms orchestration, choreography, and composition seem to be used interchangeably. The dynamic composibility of services, including runtime contract discovery, is a hard if not unsolvable task. The paragraph would benefit from a more careful wording, e.g., emphasizing design-time or semi-automatic composition, where specific services are discovered and composed to solve specific tasks. Note that in a composition of services, current state of the art abstracts services as one input/ one output only. Additionally taking into account more complicated choreographies of 2 services interacting is not feasible.

Section 5 > caGRID 2.0 Platform and Terminology Integration > Data Representation and Information Model

How does this fit in with the artifact management, are these information models seen as static models managed as an artifact?

Section 5 > caGRID 2.0 Platform and Terminology Integration > Data Exploration and Query

It says that the query capability must support sophisticated queries such as temporal queries and spatial queries. In that case, decision support earlier should mention support for temporal and spatial reasoning.