Register in OSSR #10
Comments
|
Tricky part is describing the container as an entity, not the applications in the container. TopCat and Aladin may be written in Java, but AstroPy is written in Python. The container contains all three but is itself not implemented in either Java or Python. One solution might be to create separate OSSR entries for TopCat #2 and Aladin #3, and then describe this as a container that references the other OSSR entries. |
|
On Sun, Apr 17, 2022 at 07:46:23PM -0700, Zarquan wrote:
Tricky part is describing the container as an entity, not the
applications in the container.
TopCat and Aladin may be written in Java, but AstroPy is written in
Python. The container contains all three but is itself not
implemented in either Java or Python.
One solution might be to create separate OSSR entries for TopCat #2
and Aladin #3, and then describe this as a container that
references the other OSSR entries.
My take, as usual, would be that we'll have to go back to the use
cases to decide that: Under which circumstances will people query
against the implementation language? When will they be interested in
the container (and what will be the relevant metadata then)? And
when will they be interested in the containers' ingredients? How
would they then use the information that some ingredient is part of
some container?
|
|
Two different problems:
I've been thinking about (2) for a while but I haven't found the right way to address it yet. My feeling is users won't query on the technical details.
Would this be a good topic to raise with the IVOA semantics group ? We need some vocabularies to describe software in a way that helps researchers find them. This GitHub issue probably isn't the right place for this. Where do you think is the best place to discuss it ? |
|
On Tue, Apr 19, 2022 at 02:59:37AM -0700, Zarquan wrote:
My feeling is users won't query on the technical details.
* _"find me software tools written in Python"_
Well... depends. I suppose a piece of code with exotic (or
proprietary) dependencies might get demerits, whereas something that
would readily integrate with whatever people are already using would
get a plus. Whether humans can quantify such effects and whether
computers could automatically reason about them is a different
question, of course.
Also, when we talk about containers, perhaps all that becomes less of
an issue. At least alleviating the dependency load was their
promise...
is an edge case at best
* _"find me software tools that can handle astronomy images"_
would be much more useful
I suppose when people do software discovery, what really drives them
would be an even more concrete use case like
* "I need to re-reduce these FancyCam images"
* "I have visibilities from MegaArray and now want real-space images"
* "Here's a spectrum: how can I continuum-normalise it? And then
how do I get abundances and physical parameters out of it?" (if it's
a stellar spectrum) "And then how do I get a model for the
Hydrogen concentrations along the line of sight?" (if it's a quasar
spectrum)
* "I have this little physical system here (with mass points, perhaps
gas, perhaps evolution, perhaps custom effects), and now I'd like to
simulate it. What do I start from?"
Actually, for all these cases, I suspect people don't do any software
discovery at all at this point but just use what the observing
facility tells them to use and/or their institute has always used.
But changing this would of course be a good thing.
Really: If we had a few dozen such little stories (both real and
imaginary), I think we'd see a lot more clearly what software we
should register and with what metadata.
Would this be a good topic to raise with the IVOA semantics group ?
We need some vocabularies to describe software in a way that helps
researchers find them.
Well, if vocabularies play a role, Semantics might have some input,
but figuring out what metadata should be available for discovery (and
later inspection) is clearly on the Registry side.
This GitHub issue probably isn't the right place for this. Where do
you think is the best place to discuss it ?
Umm... a place you can lock people in. Software registration has
been a topic in the IVOA Registry WG off and an over the past 20
years, and every time it came up in various disguises, people quickly
ran away again.
Joking aside, I'd try a breakout or "running" meeting within the
Registry WG and see who attends and if they can be charmed into
contributing, for starters, stories as those imagined above. As I
said, we ought to have at least a few dozen of them, and there's
nothing wrong with having more than that.
Given my doubts on sustained interest within the IVOA, I'd then take
these stories and go to the RDA (or some similar cross-disciplinary
forum) and try to work things out with other people thinking about
software registration (and I think there are currently hundreds of
them, scattered over the various disciplines and fora). Given that
quite a few of the stories will be rather similar over a number of
disciplines ("I have an array that's 400 GB -- how do I slice, dice,
and resample it?"), I'd say software registration is one of the
issues that are cross-disciplinary in nature and may just need a dash
of disciplinary seasoning here and there.
|
|
Three different questions:
This GitHub issue is concentrating on solving (1). There is an opportunity in (2) to contribute to the ESCAPE WP3 OSSR project, adding some vocabularies to the metadata they already have, to enable users to search for software in the OSSR using fairly simple terms like 'astronomy' and 'images'. (3) is a totally different project, and I agree, as far as I know no one has asked to do this yet |
Enough of an OSSR entry to enable this to be used as an example in ESAP.
The text was updated successfully, but these errors were encountered: