"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

APAC Grid Geosciences System Specification


Related pages (edit)
Enterprise Viewpoint
Information Viewpoint
Computational Viewpoint
Engineering Viewpoint
Technology Viewpoint
Design Guidelines
Go To
ApacRelatedPages
WebHome

Information Viewpoint

The information viewpoint provides details of the actual or intended information models used across the APAC Grid. It also details the principles used in information modelling on the Grid.

In the context of the Grid, these information models are predominately for use "on the wire" and are neither persisted in this form or used in direct computation. Information is transformed from the "community model" to the "private model" with in a given service.

The use of open standards is promoted to provide greater interoperability between services and to allow experiments to be easily repeated on new computational services as they are developed and become more sophisticated.

Catalog of Information Models

Problem Description - each project scenario poses a particular problem to be solved on the Grid. Usually this problem is described in the terminology of the domain of interest (the conceptual level - see CmnPattern). For the purposes of this specification this is broadly the "Geosciences". The problem description information model specifies this posed problem usually by using elements from the other information models and structuring them in a form suitable to described the problem. Given much of the underlying physics is common across the project scenarios there is expected to be considerable overlap in elements used. The objective will be to develop common patterns for creating problem descriptions and a common information model for the overlapping components.

Job Description - The job description is concerned with practical matters associated with solving a given posed problem. It is separated from the problem description since it is usually directly tied to implementation specifics - how many cpus? for how long? what physical hardware architecture is required?. It is expected this information model will be developed in conjunction with the APAC Grid infrastructure projects and in particular scheduling and resource allocation services.

Geoscience and other domain specific information models - Across the geoscience community a number of information models are used to describe elements of "geoscience data". These elements are usually combined to produce the final message or document used by a given application of service (eg. a problem description may utilise the Rock element to describe material properties). This project promotes the use of (preferably) open community standards for information interchange.

No single standard encompasses all aspects and there is considerable overlap between sub-communities. [Profiles] are used to overcome ambiguity for a given sub-community. Some sub-communities have already established a common methodology (eg. OpenDAP and netCDF for some earth systems modelling work). These often overlap with other sub-communities. This means there will be more than one profile available that performs the same function. This "natural competition" is considered acceptable - so long as the number of overlappiong profiles is relatively small [cross-community transformation] is manageable.

Domain specific information models can be quite narrow are restricted to a specific (conceptual) domain of the sciences eg. the geochemical properties of rocks.

Other information models are more generally applicable because the underlying mathematics or numerical domains are common eg. finite element models. Where possible these broader information models are selected from standards or profiles that occur both within and outside the geosciences. The CmnPattern is a useful pattern for information modelling that supports this principle.

Domain specific information models:

Implementation specific information models - a number of comptuational services have very specific needs that are not directly related to the posed problem but are necessary for the implementation being used - eg. time step size used in numerical solution. In line with the CmnPattern guidelines these implementation specific information models are separated from the core conceptual problem. Implementation details do no "pollute" the actual posed problem and the information can be transferred to alternative implementations easily. Details of the implementation specific information models will be developed during the course of the project.

-- RobertWoodcock - 09 Nov 2004
Topic revision: r3 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).