Re: semantics

From: <Franck.LePetit-at-obspm.fr>
Date: Thu, 18 May 2006 19:22:29 +0200 (CEST)

Hello,

We thought a bit to this problem of definition we had on tuesday afternoon. I put below my notes.
My conclusions are :
- we have to add an entry for the name of the developper or the developping team. during the registration. - The tag physical process will be our main problem. We will have to describe far more our codes that we said on tuesday. Below I give the example of somebody who would looked for a PDR code to compute vibrationnal excitation of H2. It will require to describe codes in all the details.
- On the other hand, as mentionned during the discussion on tuesday and in last Herve's mail, registration of some codes would require to use far too much "physical processes" values. An efficient search in registries need to group them with more common names. Ex: photoionization region code
(cloudy type), PDR code.

Best regards
Franck Le Petit and Fabrice Roy


Note about UCDs for the descrition of codes in registries

First we have to precise if we try to caracterize a code or a result from a simulation.
They should be considered as two different categories in the registries. A metadata should be associated to simulation results to say from which code it comes from. A search on this metadata should be possible. Example : I want all simulation results from Zeus.


UCDs required FOR CODES

A search in the registries has to find a code. Example of searches : 

0) I want the wonderful code developped by the Albert E.
1) I want the Cloudy code.  (search by name)
2) I want the version of 1999 of the Cloudy code (add the version)
3) I want a radiative transfer code (category of code)
4) I want a radiative transfer code using the Ali method (method
specification)
5) I want a radiative transfer code able to deal with X-Rays in optically thick media. (that is a tough one)
6) I want a radiative transfer code for interstellar clouds in the millimetric producing spectra. (add a specification on the output) 8) I want an MHD code using characteristics methods for boundary conditions. (method about boundary conditions - should be covered by algorithm)
10) I want a stationnary (or time dependent) MHD shock model

Note : We could find very difficult queries. Ex: I want a PDR code computing the vibrational excitation of H2. Such queries would require to describe a lot the code in the registries
(excitation of H2).

I think that in a first step we do not have to go to this level but, at a point, it may be necessary. It will require to have many possibilities in the "physical process" tag (far more than in the thesaurus). 

0 --- Team / developper ---------------------------------------

(Example 0)

A search on the name of a team or of a developper name should be possible. It is frequent, we choose a code because we are confident in a team...

Required for registration : yes 

1 --- Name --------------------------------------------------

(Example 1)

A UCD is required to tag the name of the code

Required for registration : yes
Multiple possibilities : no
Choice from a list : no 

2 --- Version -----------------------------------------------

(Ex. 2)

A UCD is required to tag the number version of the code.

Required : yes
Multiple possibilities : no
Choice from a list : should follow common standards for versionning
(Hervé knows that)

3 --- Physical Process (Type of code) -----------------------

(Ex. 3)

A UCD is required to specify the physical processes the code can deal with.
Most of the possibilities can be found in the "thesaurus". We should add some possibilities which are the common name given to codes dealing with many physical processes.
Example : PDR code, Photoionization region code.

Multiple choice possible : yes
Defined list of possibilities : yes(?)
List of choices : Thesaurus (plus a few more to reflect the usual way these codes are called ? )
Note: If we want to find a solution as the request :"search for a PDR code computing the H2 excitation", the thesaurus will no more be sufficient. Other solutions will have to be found. 

Examples : 	- radiative transfer
		- MHD
		- gravitationnal dynamics (not in thesaurus)
		- photoionization (cover many physical processes)
		- PDR (cover many physical processes)

4 --- Subject ---------------------------------------------

(Ex. 6-7)

This UCD would precise the kinds of objects the code can simulate. Example : - Accretion disk

Multiple choice : yes
Defined list of possibilities : yes
List : Thesaurus

Note : Example 5 is a problem. The request requires a code able to deal with optically thick media. Such characterization is not found in the thesaurus.

Note : A search using "Physical process" and "Subject" should succeed most of the time excepted for specific researches 

5 --- Algorithm ----------------------------------------

(Example : 4,8)

This UCD is required to specify an algorithm. Example : N-body, SPH, Ali, ...,
Problem : The same algorithm can have different names. Possible solution : Add as many values as it has of names.

The list should not be limited.
Reason : New algorithms can be found.

Should this field be filled for all codes ? Not sure if such classification is relevant for physico-chemistry codes. There are so many physical processes that nobody care how they are done
(excepted for radiative transfer).

6 --- Time Evolution algorithm ----------------------------

Is it a necessity to separate the time algorithm with the other algorithms ?
The main interest is that this UCD could help to discriminate between stationnary and time dependent codes.

(7 --- Algorithmic parameters) ---------------------------

To be suppressed for the definition of codes in the VO. Only relevant for the definition of results of simulations. 

8 --- Result type -----------------------------------------

(Ex: 6)

A UCD is required for result type as seen in Ex. 6. Multiple possibilities : yes
Defined list of possibilities : yes 

List : 	- snapshot
	- animation
	- table
	- fits

9 --- Result parameters

I do not see the purpose of this UCD. Received on 2006-05-18Z17:23:41