Credits and IVOA Identifiers in SSA0.97

[Doug Tody]

On Mon, 18 Dec 2006, Alberto Micol wrote:

> On Dec 18, 2006, at 16:35, Doug Tody wrote:
>> Probably STECF is the Creator of this data collection.  You should
>> define registry entries for Creator and Collection, and each spectrum
>> should have a unique CreatorDID within the collection.  If we then
>> replicate the collection at MAST and CADC, those are Publishers
>> and have their own PublisherDID for each dataset, with Creator
>> and CreatorDID unchanged.
>
> I like the fact that CreatorDID remains the original one. That makes possible
> to compare two products from different publishers, and see whether they are
> actually the same product or not.

Yes.

> And, I guess, also the DataID.Collection should remain untouched in that 
> case.

Yes.

> It will be via the DataID.Collection that a user could look up into the 
> registry
> to see whether the same collection can be retrieved from a different 
> publisher
> (e.g. when there is a network problem, etc). The problem though is that
> the Collection as defined in 3.3.3.11 is not necessarily unique, it is not
> a ivoa identifier.

This is true.  The collection shortName is more convenient for queries
(via the COLLECTION parameter; this is likely to be unique as the
scope of a query to single service is limited), however to use it
with a registry lookup implies a global query rather than a direct
reference.  If we find we need to do this sort of thing very much,
we should probably include the CollectionID as well.

> About Credits:
>
> How to give credits in general?
> In particular: there might be cases where a second creator/publisher changes
> (slightly or heavily) the products originated by the first creator.
> In that case Creator, CreatorDID, Publisher and PublisherDID will all be
> related to the second creator, and information about the first one gets lost.
> How to give credit to the first Creator?

Good question.  This is always a problem with derived products.
Probably there is no way to really do this at present except at the
level of the data source/collection and in DataID, however this does
not give credit one step further back in the processing chain for a
derived data collection.  We do have DataID.Contributor, but that isn't
quite right for this.  You would probably have to go to the Collection
metadata to trace further back like this (the whole issue of Provenance
or dataset history is like this; you always end up needing to trace
backward through a set of links).


> Last question:
>
> DataID.Creator is a recommended field and
> Curation.Publisher is a mandatory fields.
>
> Those are short strings, not at all guaranteed to be unique.
> Why not mandating the usage of the CreatorID and PublisherID
> being them ivo identifiers? Important to look them up into the registry...

It is true these names are less formal, and in the ideal world using
IDs with a registry lookup (likewise for Collection) is a more powerful
and correct mechanism.  It is just that the short names are more useful
for the client to display for the user (without requiring a registry
lookup), may be adequate for the client to subsequently return as
a query parameter to the same service, and datums like "Creator"
may not have a registry entry but may still be known in some sense.

In general we support both short names and IDs in the full model.
There may be some things missing which we should reconsider (e.g.,
CollectionID).  This is an issue with the registry and resource metadata
as well, e.g., RM defines "Creator" but not "CreatorID".

 	- Doug