Link to page: 5 - Semantic Infrastructure Functional Requirements
Comment 24 on Section 5
Section 5: Semantic Infrastructure Functional Requirements November 22 version
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.
Resolution:
Document edited to reflect comment. Charlie Mead
Comment 23 on Section 5
Section 5 > Artifact Management > Types of Artifacts > Static Models November 22 version
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).
Resolution:
Comment 22 on Section 5
Section 5 > Artifact Management > Types of Artifacts > Behavioral Models November 22 version
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).
Resolution:
Document updated to reflect comment. Charlie Mead
Comment 21 on Section 5
Comment on November 22 version
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?
Resolution:
Comment 20 on Section 5
Section 5 > Artifact Management > Types of Artifacts > Content November 22 version
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?
Resolution:
Comment 19 on Section 5
Section 5 > Artifact Management > Types of Artifacts > Artifact Management Functions November 22 version
Does managing the lifecycle, governance and versioning of the models, content and forms also include the Specification Content from the previous paragraph?
Resolution:
Comment 18 on Section 5
Section 5 > Service Discovery and Governance November 22 version
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?
Resolution:
Comment 17 on Section 5
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.
Resolution:
Comment 16 on Section 5
Section 5 > Service Discovery and Governance > Service Discovery Functions November 22 version
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?
Resolution:
Comment 15 on Section 5
Section 5 > Clinical Data Forms Definition and Modeling > Clinical Data Form Functions November 22 version
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).
Resolution:
Comment 14 on Section 5
Section 5 > Decision Support and Reasoning November 22 version
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?
Resolution:
Comment 13 on Section 5
Comment on November 22 version
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.
Resolution:
Comment 12 on Section 5
Comment on November 22 version
In "support for classification", if one mentions description logics and business rules here, one should probably also mention logical rules (e.g., RIF-BLD).
Resolution:
Comment 11 on Section 5
Comment on November 22 version
"the decision support system should be able to applied" should be "the decision support system should be able to be applied"
Resolution: Done
Comment 10 on Section 5
Comment on November 22 version
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).
Resolution:
Comment 09 on Section 5
Comment on November 22 version
Phrases like "choreography layered fashion" are vague and without meaning.
Resolution: No longer in the document
Comment 08 on Section 5
Section 5 > Decision Support and Reasoning > Decision Support Functions November 22 version
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?
Resolution:
Comment 07 on Section 5
Comment on November 22 version
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?
Resolution:
Comment 06 on Section 5
Comment on November 22 version
Use case bullets that drive these requirements are not providing any explanation.
Resolution:
Comment 05 on Section 5
Comment on November 22 version
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.
Resolution:
Comment 04 on Section 5
Section 5 > caGRID 2.0 Platform and Terminology Integration > Service Generation November 22 version
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.
Resolution:
Comment 03 on Section 5
Section 5 > caGRID 2.0 Platform and Terminology Integration > Service Discovery November 22 version
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.
Resolution:
Comment 02 on Section 5
Section 5 > caGRID 2.0 Platform and Terminology Integration November 22 version
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?
Resolution:
Comment 01 on Section 5
Section 5 > caGRID 2.0 Platform and Terminology Integration > Data Exploration and Query November 22 version
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.
Resolution:
