What should we call science platforms?

[arfon]

/ cc @jegpeek

[jegpeek]

The folks at LSST (Frossie and Gregory) have an item on this, but github will not let me find their usernames to tag them. :/

[arfon]

/ cc @frossie

[arfon]

...and after some GitHub sleuthing I'm guessing / cc @gpdf

[jegpeek]

basically @gpdf and @frossie are going to come to terms about what they want to call "Notebook Aspect" with the expectation 1) they should pick something generic the rest of the community can get behind 2) It can't be jellybean even though that name is awesome 3) I admit that a jellybean is not valuable so a science center without the other parts of a science platform and thus 4) the IPAC workshop will be called something like 'jellybeans and their supporting systems' or the like.

[arfon]

Some suggestions:

• Hosted Analysis Environment (HAE)
• Interactive Analysis Environment (IAE)
• Computational Environment (this is how JupyterLab refers to itself https://github.com/jupyterlab/jupyterlab)

[gpdf]

You tagged me successfully.

I spoke with @frossie a bit about this after the sessions yesterday, and I've thought about this all quite a bit more, and I'd like to revise what I said yesterday a bit.

The apparent plenary conflict I had with Frossie was in the context of @jegpeek saying "we need a name for this" (meaning the thing LSST calls Jellybean internally, the Notebook Aspect) and Frossie saying "the name is 'Science Platform'" (meaning the important thing to be talking about is the whole, not the part).

From the perspective "what is the new* technology ?" the answer is "an interactive notebook environment" / "Jellybean" / the "Notebook Aspect", it's true. I am very much in agreement with Josh that a commonly accepted term for this is needed, and one that could encompass variants like Apache Zeppelin should the community come to want them.

But from the perspective "what is the new idea?" I think it's very clear that "Science Platform" is a better term. It's a term that caught on very quickly in the last couple of years, to the point where it's hard to trace its origin and pointless to attempt to do so, and if we ask "What is a Science Platform?" in a non-lawyered-up way, I think an answer that would have achieved consensus in the room is "A Jellybean integrated with astronomical data services" (or the equivalents for other fields). The integration doesn't have to be exactly the three-Aspect concept that LSST and Marvin2 and others have independently developed. But it is the integration that makes the Python computing environment useful.

I didn't hear IRSA or MAST or anybody else trying to say "but what we've been doing all along is a Science Platform already", and I think it would behoove all of us not to start sliding in that direction.

We've collectively stumbled on what is clearly an evocative term and one that has already caught on with our communities; let's grab it with both hands as the standard under which we'll move forward. I think the case we're trying to make is something like "our users want a Science Platform (as defined above), so we need the resources (people and hardware) to add the "X" (Jellybean) to what we are already doing, in an integrated way, so that we can deliver Science Platform behavior". Let's keep the focus on the user-facing concept.

With regard to Josh's points: (1) & (2) again, I completely agree, and Frossie and I will give this some thought**, and (3) we all agree. But on (4), especially because we are planning to add more of an explicit science use case focus to the next workshop, I would very much want to keep the "Science Platform" in the workshop name, and then use "X" to name sessions / a technical track in the workshop. Or even "Science Platforms: Astronomical Data Analysis with X"?

Gregory

(*) New to astro data centers, in particular. (**) I'd like to stay away from "Server Side Analytics" as the new name as well, because IRSA and MAST and NEA are all quite properly going to tell us "we already have that", e.g., periodogram services, cutout/mosaic services.

[jegpeek]

All very good thoughts! I am, upon reflection, onboard with sticking with "science platform" in the name of the next gathering; jellybeans are not delicious in isolation, and the integration with existing or new services and data may be what makes coordination both necessary and difficult. One subtlety I will note is that while APIs are a critical feature of a Science Platform, the self-same APIs could be critical for all sorts of non-science-platform things, like engineering databases and various data exchange protocols. So while a jellybean is entirely "in" a science platform (and isn't "in" anything else, per se) APIs are not, generically.

Server Side Analytics has the one advantage that it makes sense to NASA in the context of the Big Data Task Force. As I mentioned to you in person, I think there is some room for something like "Server Side Analysis [noun]" which to an astronomer makes sense quite clearly. And "doing analysis" is not not just one analytic step or function. But I am by no means wedded to that term.

I am happy to outsources naming to @frossie and @gpdf , while retaining communal veto privileges, but that might not be your favorite scenario. I am at your service...

[gpdf]

"Server Side Analysis" does not raise the same alarm for me, particular if it's in a context in which it's clear that this is user-configured, user-directed analysis.

[frossie]

The Science Platform is what allows you to do Server-Side Analysis. To provide a Science Platform you need lego bricks. Maybe you already had some lego bricks from a previous kit, or maybe you're new to this and have to obtain all the bricks. What LSST has nicknamed jellybean is one of those annoying special lego bricks that you just have to have and you can't find in your old lego bucket. But at the end it's just a brick, the Science Platform is the cool lego rocket you build with all that and doing Server-Side Analysis is walking around with your lego rocket making wooshing noises and being happy.

End of analogy, you will be pleased to know.