Target Object: Optional?Suggestion: The model must be able to describe simulations for which there is no target object. Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere. I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model. -- RickWagner - 13 Feb 2008 Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*. -- GerardLemson - 14 Feb 2008Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008 Comment: I do agree with this in principle as it does represent the world better. The main problem with this more normalized approach is that the serialisation requires more indirection. This is especially true if we want to register Protocls separately from experiment in individual XML documents so we can not use ID/IDREF. How to deal with this properly is an issue that appears now and then in the IVOA discussions, but has not been resolved in a standardised manner. Suggestions include using the XML trick of xlink, or using the standardised ivo:/... [[][IVO Identifiers]], which have to be interpreted then by the (SNAP) registry that accepts these documents. To avoid these complications, the snap model combined the definition (belonging to SNAPProtocol) and the usage (by snap experiment) in one type contained by SNAPExperiment. We need to get opinions on this from the community and try out solutions and tools (SNAP portals) that assist users in this process. --IVOA.GerardLemson- 14 Feb 2008Target Process: ObjectType?Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process. Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles. Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process. It seems easier to allow processes to have properties, than to add many derived quantities to the representations. Comment: I added TargetProcess recently when realising that the goal of an experiment may be to study a given process iso a given (type of) object. I did not work it out beyond adding a semantic label and some more attributes. I think your proposal of re-using objecttype is reasonable and concise. Another example I can see is studying the effects of different cosmologies on LSS evolution where obvious properties are the cosmological parameters. Proposed resolution: follow Rick's suggestion, have TargetProcess inherit from ObjectType.Data Model SketchHere is a sketch of a data model implementing the two previous suggestions (making TargetProcess an ObjectType and moving Representation and Algorithm to the program or Protocol). I think Characterization should also be an element of the Simulation, but I really couldn't bring myself to make this any messier.![]()
|
| ||||||||
Added: | ||||||||
> > |
| |||||||
Target Object: Optional?Suggestion: The model must be able to describe simulations for which there is no target object. Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere. I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model. -- RickWagner - 13 Feb 2008 Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*. -- GerardLemson - 14 Feb 2008Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008 Comment: I do agree with this in principle as it does represent the world better. The main problem with this more normalized approach is that the serialisation requires more indirection. This is especially true if we want to register Protocls separately from experiment in individual XML documents so we can not use ID/IDREF. How to deal with this properly is an issue that appears now and then in the IVOA discussions, but has not been resolved in a standardised manner. Suggestions include using the XML trick of xlink, or using the standardised ivo:/... [[][IVO Identifiers]], which have to be interpreted then by the (SNAP) registry that accepts these documents. To avoid these complications, the snap model combined the definition (belonging to SNAPProtocol) and the usage (by snap experiment) in one type contained by SNAPExperiment. We need to get opinions on this from the community and try out solutions and tools (SNAP portals) that assist users in this process. --IVOA.GerardLemson- 14 Feb 2008Target Process: ObjectType?Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process. Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles. Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process. It seems easier to allow processes to have properties, than to add many derived quantities to the representations. Comment: I added TargetProcess recently when realising that the goal of an experiment may be to study a given process iso a given (type of) object. I did not work it out beyond adding a semantic label and some more attributes. I think your proposal of re-using objecttype is reasonable and concise. Another example I can see is studying the effects of different cosmologies on LSS evolution where obvious properties are the cosmological parameters. Proposed resolution: follow Rick's suggestion, have TargetProcess inherit from ObjectType.<--
Data Model SketchHere is a sketch of a data model implementing the two previous suggestions (making TargetProcess an ObjectType and moving Representation and Algorithm to the program or Protocol). I think Characterization should also be an element of the Simulation, but I really couldn't bring myself to make this any messier.![]()
|
Target Object: Optional?Suggestion: The model must be able to describe simulations for which there is no target object. Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere. I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model. -- RickWagner - 13 Feb 2008 | ||||||||
Changed: | ||||||||
< < | Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*. | |||||||
> > | Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*. | |||||||
-- GerardLemson - 14 Feb 2008
Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008 | ||||||||
Changed: | ||||||||
< < | Comment: I do agree with this in principle as it does represent the world better. | |||||||
> > | Comment: I do agree with this in principle as it does represent the world better. The main problem with this more | |||||||
Added: | ||||||||
> > | normalized approach is that the serialisation requires more indirection. This is especially true if we want to register Protocls separately from experiment in individual XML documents so we can not use ID/IDREF. How to deal with this properly is an issue that appears now and then in the IVOA discussions, but has not been resolved in a standardised manner. Suggestions include using the XML trick of xlink, or using the standardised ivo:/... [[][IVO Identifiers]], which have to be interpreted then by the (SNAP) registry that accepts these documents. To avoid these complications, the snap model combined the definition (belonging to SNAPProtocol) and the usage (by snap experiment) in one type contained by SNAPExperiment. We need to get opinions on this from the community and try out solutions and tools (SNAP portals) that assist users in this process. --IVOA.GerardLemson- 14 Feb 2008 | |||||||
Target Process: ObjectType?Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process. Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles. Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process. It seems easier to allow processes to have properties, than to add many derived quantities to the representations. Comment: I added TargetProcess recently when realising that the goal of an experiment may be to study a given process iso a given (type of) object. I did not work it out beyond adding a semantic label and some more attributes. I think your proposal of re-using objecttype is reasonable and concise. Another example I can see is studying the effects of different cosmologies on LSS evolution where obvious properties are the cosmological parameters. Proposed resolution: follow Rick's suggestion, have TargetProcess inherit from ObjectType.<--
Data Model SketchHere is a sketch of a data model implementing the two previous suggestions (making TargetProcess an ObjectType and moving Representation and Algorithm to the program or Protocol). I think Characterization should also be an element of the Simulation, but I really couldn't bring myself to make this any messier.![]()
|
Target Object: Optional?Suggestion: The model must be able to describe simulations for which there is no target object. Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere. I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model. | ||||||||
Deleted: | ||||||||
< < | Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*. | |||||||
-- RickWagner - 13 Feb 2008 | ||||||||
Added: | ||||||||
> > | Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*. | |||||||
Added: | ||||||||
> > | -- GerardLemson - 14 Feb 2008 | |||||||
Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008 | ||||||||
Added: | ||||||||
> > | Comment: I do agree with this in principle as it does represent the world better. | |||||||
Target Process: ObjectType?Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process. Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles. Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process. It seems easier to allow processes to have properties, than to add many derived quantities to the representations. | ||||||||
Added: | ||||||||
> > | Comment: I added TargetProcess recently when realising that the goal of an experiment may be to study a given process iso a given (type of) object. I did not work it out beyond adding a semantic label and some more attributes. I think your proposal of re-using objecttype is reasonable and concise. Another example I can see is studying the effects of different cosmologies on LSS evolution where obvious properties are the cosmological parameters. Proposed resolution: follow Rick's suggestion, have TargetProcess inherit from ObjectType. | |||||||
<--
Data Model SketchHere is a sketch of a data model implementing the two previous suggestions (making TargetProcess an ObjectType and moving Representation and Algorithm to the program or Protocol). I think Characterization should also be an element of the Simulation, but I really couldn't bring myself to make this any messier.![]()
|
Target Object: Optional?Suggestion: The model must be able to describe simulations for which there is no target object. Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere. I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model. | ||||||||
Added: | ||||||||
> > | Proposed resolution: give the composition relation between SNAPExperiment and TargetObjectType cardinality 0..*. | |||||||
-- RickWagner - 13 Feb 2008
Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008Target Process: ObjectType?Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process. Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles. Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process. It seems easier to allow processes to have properties, than to add many derived quantities to the representations.<--
Data Model SketchHere is a sketch of a data model implementing the two previous suggestions (making TargetProcess an ObjectType and moving Representation and Algorithm to the program or Protocol). I think Characterization should also be an element of the Simulation, but I really couldn't bring myself to make this any messier.![]()
|
Target Object: Optional?Suggestion: The model must be able to describe simulations for which there is no target object. Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere. I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model. -- RickWagner - 13 Feb 2008Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008Target Process: ObjectType?Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process. Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles. Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process. It seems easier to allow processes to have properties, than to add many derived quantities to the representations.<--
| ||||||||
Added: | ||||||||
> > | Data Model SketchHere is a sketch of a data model implementing the two previous suggestions (making TargetProcess an ObjectType and moving Representation and Algorithm to the program or Protocol). I think Characterization should also be an element of the Simulation, but I really couldn't bring myself to make this any messier.![]()
| |||||||
Target Object: Optional?Suggestion: The model must be able to describe simulations for which there is no target object. Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere. I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model. -- RickWagner - 13 Feb 2008Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008 | ||||||||
Added: | ||||||||
> > | Target Process: ObjectType?Suggestion: Target process should an ObjectType, to enabling characterizing properties of a process. Some interesting values do not map well to the properties of the RepresentationObject or TargetObject. Or, the properties could be applied to either the process, representation, or target. For example, star formation rate is a property of a process (star formation), but either a collection of the targets (stars) or representation (star particles) could have a formation rate property. But this is really a property of the process, not the stars or star particles. Another example is the scaling exponent of the power spectrum in turbulence. The representation (grid cells, particles) will have properties such as velocity and density, but a decaying exponential power spectrum is a fundamental characteristic of a turbulent process. It seems easier to allow processes to have properties, than to add many derived quantities to the representations. | |||||||
<--
|
| ||||||||
Added: | ||||||||
> > | Target Object: Optional? | |||||||
Added: | ||||||||
> > | Suggestion: The model must be able to describe simulations for which there is no target object. | |||||||
Added: | ||||||||
> > | Some physics models have application on a range of scales, like turbulence and Plummer spheres. For turbulence, the target object is really "compressible fluid", which doesn't carrying the same meaning as "cloud". Especially since the simulation results could be applied to molecular clouds or the Jovian atmosphere.
I think the target object is useful for most simulations, since we often are numerically modeling a particular type of object (cloud), or even a particular object (Perseus). But, not all simulations, especially the ones that are more of numerical experiment than a numerical model.
-- RickWagner - 13 Feb 2008
Algorithm and Representation: Part of the Protocol?Question: Aren't the set of Algorithms and Representations determined by the Protocol, and selected by the ParameterSettings? To me, the Protocol (software) has a set of available algorithms and representations, which are chosen based input parameters. It seems redundant to state both separately? Could this be implemented by moving the Algorithm and Representation to the Protocol, and referencing it in the Experiment? -- RickWagner - 13 Feb 2008 | |||||||
<--
|
| ||||||||
Changed: | ||||||||
< < | Some questions: | |||||||
> > | Some questions (in bold) with their motivation and current answer (as of the last edit of the page): | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < | | |||||||
> > |
| |||||||
<--
|
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
<--
|
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > | Some questions:
| |||||||
Added: | ||||||||
> > | TargetObjectType of Level N often requires Level N+1.
| |||||||
<--
|
<--
|