msdemlei
commented
3 years ago On Wed, Apr 28, 2021 at 07:39:55AM -0700, Laurent MICHEL wrote:
This issue is related to the @msdemlei proposal. In ts.vot, I'm wondering how a client can get the role of a mapped object (or does it wish to?).
Lets take an easy example line 79:
<INSTANCE ID="ndwibspodost" dmtype="ndcube:Cube"> ... </INSTANCE>The client can read the dmtype and guess that this mapping bock contains a cube. But what happens if the data set contains 2 ndcube:Cube. (contains 2 positions is more realistic I admit)
You have two INSTANCE elements.
- How to distinguish them?
As far as the hypothetical ndcube DM is concerned, they are "equivalent" in the sense that both are just instances of Cube. Other annotation might make them non-equivalent, of course.
But the question leads to another case I'd like to see addressed in essentially all of our models and that's closely related to actually using these models.
Suppose TOPCAT sees several positions in a table, and the user asks for a sky plot. TOPCAT can now, without guessing, use one set of coordinates, but it would probably want to give the user a widget to select a different set of coordinates. That widget could have labels
"Coord in ICRS #1/Coord in ICRS #2/Coord in Galactic #1"
with what we have right now; Mark just doesn't now more about these guys.
However, I'd say it would be much preferable to have labels, say,
"Short-term solution/Long-term solution/Galactic".
What we'd need for that is a string-valued "label" attribute on many of our classes (really, any that a user might need to choose from, and probably any that may profit from having a few words of explanation).
Can I post a meta-issue on this somewhere?
- Are you sure you can always get ride of dmroles on top level instances?
A role is a relationship between a parent and a child within a certain data model. You could say that root elements have "entire document" as an implicit parent, but then you'd have to have an "entire dataset" model that would give you what role names such top-level instances could have. To me, that feels wrong.
I'm quite sure that whereever you need to define relations between the whole document and something else, it's much better to define a dedicated model for that particular function. Within instances of these models' classes (probably singletons, then), you have the roles in attributes as normal.
Let's take another example more confusing to me, line 53
<TEMPLATES> <INSTANCE ID="ndwibspapabt" dmtype="stc2:Coords"> ... </INSTANCE>This object is typed as a stc2:Coords which looks like an abstract class. No way to know which role does this instance play.
(no, Coords is't abstract; why would it?) But that you don't now the role is by design, and it's important, because that lets you un-entangle DMs. This instance could be a target position in a dataset1 instance, also target position in a dataset2 instance, a center of mass in a hypothetical extra DM the data provider defined themselves, an initial center position in a DM giving preferred plot options, and so on.
This is just like in Python and similar languages: It is not the values that have names, there are named references to the values -- and there can be as many of those as necessary to get the job done, and they can come from as many different namespaces as necessary.
If I enter it, I can see 2 un-typed attributes (time and space) but this does not tell me more about what to do with it.
- Do you assume that the client has not to be informed on the role?
- Did I miss some key point?
The time and space attribute names would of course be defined in the DM (this is organised a bit like STC1). The DM docs is where the client writers go at implementation time to figure out how to map incoming data to their data structures.
And yes, the type information is not in the attributes, it is in the values, i.e., the INSTANCEs (again, that's exactly as it is in Python and its ilk).
lmichel
This issue is related to the @msdemlei proposal. In ts.vot, I'm wondering how a client can get the role of a mapped object (or does it wish to?).
Lets take an easy example line 79:
The client can read the dmtype and guess that this mapping bock contains a cube. But what happens if the data set contains 2 ndcube:Cube. (contains 2 positions is more realistic I admit)
Let's take another example more confusing to me, line 53
This object is typed as a stc2:Coords which looks like an abstract class. No way to know which role does this instance play. If I enter it, I can see 2 un-typed attributes (time and space) but this does not tell me more about what to do with it.