Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More complex link "datamodel #44

Open
Bonnarel opened this issue May 8, 2020 · 3 comments
Open

More complex link "datamodel #44

Bonnarel opened this issue May 8, 2020 · 3 comments
Labels

Comments

@Bonnarel
Copy link
Contributor

Bonnarel commented May 8, 2020

On December the 6th 2019 Ada Nebot proposed to refurbish the semantic model of DataLink. My guess is that enhancment is probably for version 2.
Ada :

_As I see it, the things we are discussing concerning Datalink fall into 4 independent levels or categories:
Level 0 - Data-format (fits, VOTable, PDF, png, …)
Level 1 - Data-type (tabular, image, spectrum, cube, text, …)
Level 2 - Data-information (Documentation, Calibration, Log, Preview, …)
Level 3 - Data-relation (Derived from, Progenitor of, Sibling of, ...)

I see these as orthogonal levels since a list of links can be of any type (level 1) with any kind of format (level 0),
any kind of relation (level 3) and could have any type of associated information to describe it (level 2).

Today the list of links returned by datalink is described in the columns content-type and semantics.
These two columns cover the above levels only up to some degree.

  • Content-type: covers level 0 mainly, with some exceptions such as VOTable (which is also level 1).
  • Semantics: covers level 2 mainly (e.g. preview), but also level 3 (e.g. derivation, progenitor).

Datalink at the moment has no field properly covering level 1 and applications (—> users) would benefit from having that well covered.

So, in my opinion, if I had to redo Datalink I would keep these different levels separated instead of putting everything into the semantics field.
But applications might have a different point of view here —> Shouldn't we add Apps to this discussion?

Timeseries would be in level 3, since it is a relation. And I don’t think we would need the use of sibling or progenitor or anything like that for timeseries.
What we need is to be able to say is:

  • This list of links are timeseries of tabular type
  • This list of links are timeseries of spectrum type

But if were to add terms such as sibling and so on, there is already an IVOA relationship vocabulary:
http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html_

@pdowler
Copy link
Collaborator

pdowler commented May 28, 2020

possible solution: allow multiple semantics terms (in a single table cell)

  • datalink 1.0 content is forwward compatible
  • would break clients that expect one term and do string matching

@pdowler
Copy link
Collaborator

pdowler commented Nov 3, 2021

The content_qualifier field using the product-type vocabulary seems to cover level 1 as described above... right now, levels 2 and 3 remain supported by only the semantics column and the dataalink/core vocabulary of "relationships to this". If that's suffiicient for the foreseeable future, we could remove the "2.0" label and close this issue.

Thoughts?

@Bonnarel
Copy link
Contributor Author

Bonnarel commented Nov 3, 2021

The content_qualifier field using the product-type vocabulary seems to cover level 1 as described above... r
Yes
right now, levels 2 and 3 remain supported by only the semantics column and the dataalink/core vocabulary of "relationships to this". If that's suffiicient for the foreseeable future, we could remove the "2.0" label and close this issue.

Thoughts?

Well, distinction between relationship and information may be subtle. Do we have cases where the link can be both ? We should ask Ada who created this issue (by an email which I copy/paste-d a long while ago) what she thinks.
Is that a problem to let this issue dormant ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants