URLs?

[Arnold Rots]

It may be helpful to relate the use of IVOA identifiers (URIs) in the
context of the dataset identifiers to be used in manuscripts.

The intent here is to allow a linking of datasets to papers in
perpetuity, independent of the actual location of the datasets, since
it is recognized that they may move over time.  For instance, mission
archives may start out at mission operations centers, but be moved to
aggregating NASA data centers after completion of the mission.

So, all dataset identifiers are issued under the authority of the ADS,
with agreed upon resource keys for resource centers that issue their
own dataset identifiers.
For instance, the dataset associated with Chandra's ObsId 2000 would
have a dataset identifier 
	ivo://ADS/Sa.CXO#obs/2000
ivo://ADS is the authority ID of the ADS.
The ADS assigned Sa.CXO as the resource key to Chandra.
And the Chandra archive assigned obs/2000 to this dataset.
The ADS's registry knows to translate this identifier to
	http://cda.harvard.edu/chaser/obsRetrieveEntry.do?obsid=2000
in order to get at the data, but that might change in 10 years' time,
say, to http://heasarc.gsfc.nasa.gov/CDA/obsid/2000

The point is, the use of non-URL URI's (with an adequate registry)
protects one against URLs that get out of date.

  - Arnold

Rob Seaman wrote:
> Great workshop!  Thanks to everybody who helped make it so.  Will  
> write more on this after catching up on my sleep.
> 
> On Dec 8, 2005, at 6:15 AM, Norman Gray wrote (to the semantics list):
> 
> > The big difference between URIs and URLs is, as we all know, that  
> > the former are for labelling concepts, and aren't guaranteed to be  
> > dereferencable, much less immediately retrievable.  However a long- 
> > established bit of good practice here is to make your URIs  
> > retrievable and to provide _something_ useful at the end of it, be  
> > it a human-readable description of your namespace, or of your  
> > ontology, or whatever you personally mean by the concept thus  
> > labelled.
> 
> It seems to me that we have never directly discussed the value of  
> using URIs instead of URLs as identifiers within VOEvent.  We've  
> attempted to adopt the larger IVO standard in this case as in others,  
> but while STC, for example, is having to prove its specific worth to  
> VOEvent, our packet identifiers have not.
> 
> We had a productive session on Wednesday discussing common issues  
> related to building interoperable prototypes.  Surely the packet IDs  
> will prove central to any such goal.  We also discussed, but chose  
> not to reach a conclusion about, how best to support queries against  
> a VOEvent "broker's" packet repository.  (One conclusion reached,  
> however, is that publishing an event does not automatically imply  
> persisting the event.)  Might not one way of doing this  be for a  
> particular broker to simply choose URLs as IDs?  Something like:
> 
> 	<VOEvent id="http://archive.noao.edu/voevent?123456" ...>
> 
> Perhaps this is a horrible idea.  After all, we can't ensure that  
> archive.noao.edu will persist indefinitely.  On the other hand, the  
> requirements for the permanence of VOEvent packets may well be  
> significantly shorter than for other archival VO data products.   
> Certainly it would be trivial for users to retrieve packets via such  
> a mechanism.
> 
> I'm not necessarily seeking a change, but I think VOEvent would  
> benefit from aggressively challenging this facet of the standard.   
> Having survived such a challenge, the utility of IVO identifiers  
> within the larger VO might then be further clarified (or just  
> possibly, be discarded outright).
> 
> Rob
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------