Difference: PubDataLink (1 vs. 8)

Revision 82012-06-26 - root

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.


The dataset identifier is an existing IVOA and ADS standard. It is already in use in the VO registry and in existing DAL standards such as SSA. Hence, there really should be no confusion over the purpose and use of the field. Its main purpose is to identify a specific dataset and allow for later retrieval or access. The current ObsTAP spec is incorrect in specifying that the publisher DID (or creator DID etc.) cannot be used in a WHERE clause to search for datasets; this is the whole purpose of the attribute (unfortunately this was not caught until the current draft was released so we are taking up the discussion here instead).

In addition to the IVOA documents, here is a reference to the original ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/ This should help to clarify their intended purpose and usage.

-- DougTody 2 March 2011

While in principle it does not make sense to have obs_publisher_did as retrieval only (i.e., non-searchable field), within the confines of ObsTAP use cases it makes sense: the same query cannot be sent to several ObsTAP services, as they will probably have a different publisher_id that is the root of obs_publisher_did, so if you were interested in that query, you should find ObsTAP services in the registry with the corresponding publisher_id.

By the way, this brings the additional consideration that publisher_id should be indeed the root of obs_publisher_did.


Igor Chilingarian in a mail dated 8 Mar 2011 20:19:28 at some points wanted the document to stress that obs_publisher_did could serve as a primary key. While I don't believe this is much of an issue in the standard, I'd like to register my dissent here. Unless I'm severely mistaken about publisher DIDs, they are to identifiy datasets, not concrete files. If I provide a data set in various formats, I may very well have several rows with the same pub DID, no?

-- MarkusDemleitner - 09 Mar 2011

Well I follow Doug there. It could be very usefull to get the whole standard description by querying on obs_publisher_did.

-- FrancoisBonnarel - 15 Mar 2011

Revision 72011-03-16 - FrancoisBonnarel

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.


The dataset identifier is an existing IVOA and ADS standard. It is already in use in the VO registry and in existing DAL standards such as SSA. Hence, there really should be no confusion over the purpose and use of the field. Its main purpose is to identify a specific dataset and allow for later retrieval or access. The current ObsTAP spec is incorrect in specifying that the publisher DID (or creator DID etc.) cannot be used in a WHERE clause to search for datasets; this is the whole purpose of the attribute (unfortunately this was not caught until the current draft was released so we are taking up the discussion here instead).

In addition to the IVOA documents, here is a reference to the original ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/ This should help to clarify their intended purpose and usage.

-- DougTody 2 March 2011

While in principle it does not make sense to have obs_publisher_did as retrieval only (i.e., non-searchable field), within the confines of ObsTAP use cases it makes sense: the same query cannot be sent to several ObsTAP services, as they will probably have a different publisher_id that is the root of obs_publisher_did, so if you were interested in that query, you should find ObsTAP services in the registry with the corresponding publisher_id.

By the way, this brings the additional consideration that publisher_id should be indeed the root of obs_publisher_did.


Igor Chilingarian in a mail dated 8 Mar 2011 20:19:28 at some points wanted the document to stress that obs_publisher_did could serve as a primary key. While I don't believe this is much of an issue in the standard, I'd like to register my dissent here. Unless I'm severely mistaken about publisher DIDs, they are to identifiy datasets, not concrete files. If I provide a data set in various formats, I may very well have several rows with the same pub DID, no?

-- MarkusDemleitner - 09 Mar 2011

Well I follow Doug there. It could be very usefull to get the whole

Changed:
<
<
satabdard description by querying on obs_publisher_did.
>
>
standard description by querying on obs_publisher_did.
  -- FrancoisBonnarel - 15 Mar 2011
<--  
-->

Revision 62011-03-15 - FrancoisBonnarel

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.


The dataset identifier is an existing IVOA and ADS standard. It is already in use in the VO registry and in existing DAL standards such as SSA. Hence, there really should be no confusion over the purpose and use of the field. Its main purpose is to identify a specific dataset and allow for later retrieval or access. The current ObsTAP spec is incorrect in specifying that the publisher DID (or creator DID etc.) cannot be used in a WHERE clause to search for datasets; this is the whole purpose of the attribute (unfortunately this was not caught until the current draft was released so we are taking up the discussion here instead).

In addition to the IVOA documents, here is a reference to the original ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/ This should help to clarify their intended purpose and usage.

-- DougTody 2 March 2011

While in principle it does not make sense to have obs_publisher_did as retrieval only (i.e., non-searchable field), within the confines of ObsTAP use cases it makes sense: the same query cannot be sent to several ObsTAP services, as they will probably have a different publisher_id that is the root of obs_publisher_did, so if you were interested in that query, you should find ObsTAP services in the registry with the corresponding publisher_id.

By the way, this brings the additional consideration that publisher_id should be indeed the root of obs_publisher_did.


Igor Chilingarian in a mail dated 8 Mar 2011 20:19:28 at some points wanted the document to stress that obs_publisher_did could serve as a primary key. While I don't believe this is much of an issue in the standard, I'd like to register my dissent here. Unless I'm severely mistaken about publisher DIDs, they are to identifiy datasets, not concrete files. If I provide a data set in various formats, I may very well have several rows with the same pub DID, no?

-- MarkusDemleitner - 09 Mar 2011

Added:
>
>
Well I follow Doug there. It could be very usefull to get the whole satabdard description by querying on obs_publisher_did.

-- FrancoisBonnarel - 15 Mar 2011

 
<--  
-->

Revision 52011-03-09 - MarkusDemleitner

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.


The dataset identifier is an existing IVOA and ADS standard. It is already in use in the VO registry and in existing DAL standards such as SSA. Hence, there really should be no confusion over the purpose and use of the field. Its main purpose is to identify a specific dataset and allow for later retrieval or access. The current ObsTAP spec is incorrect in specifying that the publisher DID (or creator DID etc.) cannot be used in a WHERE clause to search for datasets; this is the whole purpose of the attribute (unfortunately this was not caught until the current draft was released so we are taking up the discussion here instead).

In addition to the IVOA documents, here is a reference to the original ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/ This should help to clarify their intended purpose and usage.

-- DougTody 2 March 2011

While in principle it does not make sense to have obs_publisher_did as retrieval only (i.e., non-searchable field), within the confines of ObsTAP use cases it makes sense: the same query cannot be sent to several ObsTAP services, as they will probably have a different publisher_id that is the root of obs_publisher_did, so if you were interested in that query, you should find ObsTAP services in the registry with the corresponding publisher_id.

By the way, this brings the additional consideration that publisher_id should be indeed the root of obs_publisher_did.

Added:
>
>

Igor Chilingarian in a mail dated 8 Mar 2011 20:19:28 at some points wanted the document to stress that obs_publisher_did could serve as a primary key. While I don't believe this is much of an issue in the standard, I'd like to register my dissent here. Unless I'm severely mistaken about publisher DIDs, they are to identifiy datasets, not concrete files. If I provide a data set in various formats, I may very well have several rows with the same pub DID, no?

-- MarkusDemleitner - 09 Mar 2011

 
<--  
-->

Revision 42011-03-07 - JuanDeDiosSantanderVela

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.


The dataset identifier is an existing IVOA and ADS standard. It is already in use in the VO registry and in existing DAL standards such as SSA. Hence, there really should be no confusion over the purpose and use of the field. Its main purpose is to identify a specific dataset and allow for later retrieval or access. The current ObsTAP spec is incorrect in specifying that the publisher DID (or creator DID etc.) cannot be used in a WHERE clause to search for datasets; this is the whole purpose of the attribute (unfortunately this was not caught until the current draft was released so we are taking up the discussion here instead).

In addition to the IVOA documents, here is a reference to the original ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/ This should help to clarify their intended purpose and usage.

-- DougTody 2 March 2011

Added:
>
>
While in principle it does not make sense to have obs_publisher_did as retrieval only (i.e., non-searchable field), within the confines of ObsTAP use cases it makes sense: the same query cannot be sent to several ObsTAP services, as they will probably have a different publisher_id that is the root of obs_publisher_did, so if you were interested in that query, you should find ObsTAP services in the registry with the corresponding publisher_id.
 
Changed:
<
<
>
>
By the way, this brings the additional consideration that publisher_id should be indeed the root of obs_publisher_did.
Deleted:
<
<
 
<--  
-->

Revision 32011-03-03 - DougTody

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.


The dataset identifier is an existing IVOA and ADS standard. It is already in use in the VO registry and in existing DAL standards such as SSA. Hence, there really should be no confusion over the purpose and use of the field. Its main purpose is to identify a specific dataset and allow for later retrieval or access. The current ObsTAP spec is incorrect in specifying that the publisher DID (or creator DID etc.) cannot be used in a WHERE clause to search for datasets; this is the whole purpose of the attribute (unfortunately this was not caught until the current draft was released so we are taking up the discussion here instead).

In addition to the IVOA documents, here is a reference to the original

Changed:
<
<
ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/
>
>
ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/ This should help to clarify their intended purpose and usage.
 
Deleted:
<
<
This should help to clarify their intended purpose and usage.
 -- DougTody 2 March 2011


<--  
-->

Revision 22011-03-03 - DougTody

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.
Added:
>
>

 
Added:
>
>
The dataset identifier is an existing IVOA and ADS standard. It is already in use in the VO registry and in existing DAL standards such as SSA. Hence, there really should be no confusion over the purpose and use of the field. Its main purpose is to identify a specific dataset and allow for later retrieval or access. The current ObsTAP spec is incorrect in specifying that the publisher DID (or creator DID etc.) cannot be used in a WHERE clause to search for datasets; this is the whole purpose of the attribute (unfortunately this was not caught until the current draft was released so we are taking up the discussion here instead).
 
Added:
>
>
In addition to the IVOA documents, here is a reference to the original ADS-IVOA agreement where dataset identifiers were originally defined: http://vo.ads.harvard.edu/dv/
 
Added:
>
>
This should help to clarify their intended purpose and usage. -- DougTody 2 March 2011
 


<--  
-->

Revision 12011-02-28 - MireilleLouys

 
META TOPICPARENT name="ObsDMCoreComponents"
+ Various uses and possibilities for obs_publisher_did

  1. How the user will be able to make use of it.
This is not a ObsTAP issue, it is a more generic question: Within the IVOA architecture, how to use a obs_publisher_did? For publications? To find again the data? For programmatic access?
  1. Given it is a CLOB field, nobody can actually use it to find the same data again (and access_url is volatile).
The IVOA should seriously think how to consume it.


<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback