Registry discussion

[Robert Hanisch]

> > > ** Compatibility with ADEC is the most important new thing in
> > > the registry discussion. We should concentrate on that.
> >
> > This has popped up in the last week and suddenly it is the most
iumportant
> > thing in the VO world. Why?
>
> The reason we do research is to get journal publications. Once you have
> published to VO, it would be good if journal publication (ADEC) is
> straightforward. I would like for the systems to be joined -- that way the
> journals would cite VO identifiers. I would like for publication to happen
> in stages: a personal digital library, then sharing with a group, then
> public, then peer-reviewed.

For those who may not be familiar with ADEC (the Astrophysics Data centers
Executive Committee), which is the organization of NASA data centers, let me
try to shed some light on this.  The NASA data centers began an initiative a
while ago to try to find a way to support links from papers in the published
literature to the datasets upon which they are based.  (The CDS has
initiated a similar kind of facility with A&A, where object names in papers
are linked to their SIMBAD entries.)  The ADS (Astrophysics Data System) is
a member of ADEC, and ADEC took the initiative to try to develop this
interlinking system with the AAS journals (ApJ and AJ).  The NASA data
centers are also members of the US NVO project.  So, we are all one big
(happy) family!

Our original white papers on the VO included the idea that the published
literature is an integral component of the VO.  Published papers are just
another sort of data -- albeit highly processed and selective.  Many of the
tables published in the literature are ultimately ingested into services
like Vizier and NED, and thus are also the stuff of which the VO is made.
As Roy W. has noted recently, there is really a continuum from raw data -- 
pixels on a detector -- to the peer-reviewed literature.

So the reason that the means by which we link peer-reviewed papers to their
underlying datasets is important is because it is really the same issue as
persistent identifers in resource registries.  (It is analogous to the
bibcode or the DOI, both of which are identifiers that exist outside of a
particular IP domain name.)  It would be unfortunate if we needed different
mechanisms or required totally different syntaxes and parsing schemes to
handle these two cases.

Bob