extending DataLink scope

[Bonnarel]

No description provided.

[olebole]

I am not sure how this PR relates to #10, since it requests the same change here. To make sure that this doesn't get lost, copying my comment from there:

This is true only for DatasetEntity objects in Provenance. However there are also ValueEntity objects (f.e. to configuration parameters, as in the MuseWISE implementation) which cannot be hooked to lists of real datasets retrieval and previews. IMO this should be limited to DatasetEntity instances.

Suggested change

The IVOA Provenance datamodel \citep{pr:provdm} represents metadata tracing the history of data. This information can be retrieved through ProvTAP \citep{iwd:provtap} or ProvSAP \citep{iwd:provsap} DAL services. The Entity instances represent the state of the data items between various steps of the data processing flow. “Entities” can be hooked to lists of real datasets retrieval and previews, or Obscore, SimDM and SSA metadata describing them using the \blinks endpoint.

The IVOA Provenance datamodel \citep{pr:provdm} represents metadata tracing the history of data. This information can be retrieved through ProvTAP \citep{iwd:provtap} or ProvSAP \citep{iwd:provsap} DAL services. The Entity instances represent the state of the data items between various steps of the data processing flow. “DatasetEntities” can be hooked to lists of real datasets retrieval and previews, or Obscore, SimDM and SSA metadata describing them using the \blinks endpoint.

[pdowler]

The best way to avoid conflict with other standards is to not restate things from that spec with too much detail.

However, in this case I cannot tell if this advice is aimed at (i) linking from a dataset to one or more services that provide the provenance metadata or (ii) using datalink in a provenance service response to link to datasets. Sounds more like the latter, in which case either accept Ole's change or simplify the text a little to be less specific.

[pdowler]

I agree that we need to broaden beyond datasets, but "VO items" is odd. Maybe instead of "metadata about discovered VO items to..." we should say "metadata discovered via one service to...".
Plus, the comma after products should be removed.

[pdowler]

The best way to avoid conflict with other standards is to not restate things from that spec with too much detail.

However, in this case I cannot tell if this advice is aimed at (i) linking from a dataset to one or more services that provide the provenance metadata or (ii) using datalink in a provenance service response to link to datasets. Sounds more like the latter, in which case either accept Ole's change or simplify the text a little to be less specific.

[Bonnarel]

Le 12/11/2019 à 17:12, Ole Streicher a écrit :

***@***.**** commented on this pull request. ------------------------------------------------------------------------ In DataLink.tex <#9 (comment)>: > @@ -257,6 +255,13 @@ \subsubsection{Recursive DataLink} DataLink). This service link would be described with both a service type (as in \ref{sec:useStandard}) and content type. +\subsubsection{Datasets linked to an astronomical source} + +There are a lot of catalogs of astronomical sources made available using VO services such as ConeSearch \citep{2008ivoa.specQ0222P} or TAP services. For some catalogs “associated data” are available. These data include images from which sources have been extracted, or imaging the object in case of extended objects, as well as additional observations such as Spectra or Time Series of the source and even spectral cubes and Time Series of images for extended or varying objects. The \blinks response obtained for the source id can allow to easilly retrieve all these associated data in one shot. + +\subsubsection{Metadata and data related to provenance entities} + +The IVOA Provenance datamodel \citep{pr:provdm} represents metadata tracing the history of data. This information can be retrieved through ProvTAP \citep{iwd:provtap} or ProvSAP \citep{iwd:provsap} DAL services. The Entity instances represent the state of the data items between various steps of the data processing flow. “Entities” can be hooked to lists of real datasets retrieval and previews, or Obscore, SimDM and SSA metadata describing them using the \blinks endpoint. I am not sure how this PR relates to #10 <#10>, since it requests the same change here. To make sure that this doesn't get lost, copying my comment from there: This is true only for |DatasetEntity| objects in Provenance. However there are also |ValueEntity| objects (f.e. to configuration parameters, as in the MuseWISE implementation) which cannot be hooked to lists of real datasets retrieval and previews. IMO this should be limited to |DatasetEntity| instances.

I changed the sentence to be less precise as asked by Pat. linkage of value (or whatever) entities to data obtained via a service are also a valid use case.

…

⬇️ Suggested change -The IVOA Provenance datamodel \citep{pr:provdm} represents metadata tracing the history of data. This information can be retrieved through ProvTAP \citep{iwd:provtap} or ProvSAP \citep{iwd:provsap} DAL services. The Entity instances represent the state of the data items between various steps of the data processing flow. “Entities” can be hooked to lists of real datasets retrieval and previews, or Obscore, SimDM and SSA metadata describing them using the \blinks endpoint. +The IVOA Provenance datamodel \citep{pr:provdm} represents metadata tracing the history of data. This information can be retrieved through ProvTAP \citep{iwd:provtap} or ProvSAP \citep{iwd:provsap} DAL services. The Entity instances represent the state of the data items between various steps of the data processing flow. “DatasetEntities” can be hooked to lists of real datasets retrieval and previews, or Obscore, SimDM and SSA metadata describing them using the \blinks endpoint. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AMP5LTHMRLLQD6QA2CG3QRTQTLIWTA5CNFSM4JBM6NBKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCLIILVQ#pullrequestreview-315655638>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMP5LTAQBNHAD5VWCP663QTQTLIWTANCNFSM4JBM6NBA>.

[Bonnarel]

Hi all, Le 17/11/2019 à 02:57, Patrick Dowler a écrit :

***@***.**** requested changes on this pull request. ------------------------------------------------------------------------ In DataLink.tex <#9 (comment)>: > @@ -66,16 +66,18 @@ \section*{Conformance-related definitions} \section{Introduction} This specification defines mechanisms for connecting metadata about -discovered datasets to the data, related data products, and web services -that can act upon the data. +discovered VO items to related data products, and web services I agree that we need to broaden beyond datasets, but "VO items" is odd. Maybe instead of "metadata about discovered VO items to..." we should say "metadata discovered via one service to...". Plus, the comma after products should be removed.

I made some changes along this line. See pull request #35. (the push I made on my branch DataLink-#6+#7 didn't modify the merged pull request #30)

------------------------------------------------------------------------ In DataLink.tex <#9 (comment)>: > @@ -257,6 +255,13 @@ \subsubsection{Recursive DataLink} DataLink). This service link would be described with both a service type (as in \ref{sec:useStandard}) and content type. +\subsubsection{Datasets linked to an astronomical source} + +There are a lot of catalogs of astronomical sources made available using VO services such as ConeSearch \citep{2008ivoa.specQ0222P} or TAP services. For some catalogs “associated data” are available. These data include images from which sources have been extracted, or imaging the object in case of extended objects, as well as additional observations such as Spectra or Time Series of the source and even spectral cubes and Time Series of images for extended or varying objects. The \blinks response obtained for the source id can allow to easilly retrieve all these associated data in one shot. + +\subsubsection{Metadata and data related to provenance entities} + +The IVOA Provenance datamodel \citep{pr:provdm} represents metadata tracing the history of data. This information can be retrieved through ProvTAP \citep{iwd:provtap} or ProvSAP \citep{iwd:provsap} DAL services. The Entity instances represent the state of the data items between various steps of the data processing flow. “Entities” can be hooked to lists of real datasets retrieval and previews, or Obscore, SimDM and SSA metadata describing them using the \blinks endpoint. The best way to avoid conflict with other standards is to not restate things from that spec with too much detail. However, in this case I cannot tell if this advice is aimed at (i) linking from a dataset to one or more services that provide the provenance metadata or (ii) using datalink in a provenance service response to link to datasets. Sounds more like the latter, in which case either accept Ole's change or simplify the text a little to be less specific.

It is true that I was adressing (ii). Actually this can work also for entities which are not datasets, so I choosed to be less specific in the modified sentence

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AMP5LTGHY64JPAXJXZGAXG3QUCQHZA5CNFSM4JBM6NBKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCL2D7CI#pullrequestreview-317996937>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMP5LTHXHTIMLZLZO5GN3VLQUCQHZANCNFSM4JBM6NBA>.