Hi Arnold and Ray,
I've also been thinking about Ray's proposal, and in the last couple of days I have read up on the IVOA identifier WD and spoken to both Guenther and Arnold about this.
I think the proposal is good and can be adopted for use by the ADEC dataset linking/verification system. For the sake of clarity (and to confirm that I am fully understanding what Ray is proposing) let me restate a few things. Ray, please let me know if this matches up with what you have been thinking.
The identifier to be used in journals to refer to a dataset will be in the form:
authorityID/datacollection#PrivateID
where both "authorityID" and "authorityID/datacollection" have entries in the registry. PrivateID can be anything the authorityID has chosen it to be, and represents a unique identifier that has been assigned to a dataset within the particular data collection.
For instance, MAST has a number of missions it holds data for, each with a set of datacollections available (see http://archive.stsci.edu/dataset_verifier.html). Assuming the authorityID of "NASA.HST" has been created for the HST mission , the identifiers for its datasets would look something like this:
NASA.HST/STIS#O4LT010E0 NASA.HST/ACS#J8FF03021 NASA.HST/WFPC2#U32L0104T ...
I'm not sure what to do with missions that do not currently have explicit datasets defined for them, e.g. IUE. One solution would be to allow the identifiers to have an empty datacollection:
NASA.IUE/#LWP25899 This would be akin to being able to specify URLs of the kind http://ads.harvard.edu/ rather than http://ads.harvard.edu/index.html, but it complicates things a bit when it comes to implementing the registry lookup, since NASA.IUE would have to appear as both an authority ID and a datacollection. Or maybe we should similarly stipulate that a default data collection name should be used if none has been specified.
Also, while we're at it, I would suggest specifying an explicit scheme prefix to indicate what domain these identifiers belong to. I'm thinking of simply prepending vo: or vo:// to it, like Ray has specified in the VO identifier WD:
vo://NASA.HST/STIS#O4LT010E0
This will clearly mark the identifier unanbiguously as something that needs to be resolved against the VO registry. It also means that in principle we can mix identifiers of different kinds in our documents and leave the resolution to the appropriate authorities and tools. This is similar to what the DOI foundation does for their own identifiers, which use a syntax of "doi:authority/object_id" (Speaking of DOIs, there is no reason in my mind why we could not make use of them as well, but I'll save that for another discussion).
I still have some questions about how the deployment of resolvers should take place both in the short and in the long run, but I don't see a reason why this should stop us from adopting this syntax right away.
Arnold Rots wrote:
> Ray, > > I have been mulling this over and I am not sure what the merit is of > introducing a third element into the ADEC identifier. > Can't we just have an authority Id and a dataset identifier, where the > former (everything before the first /) is resolved to a physical URL > with the latter provided as, say a parameter, to that URL? > I'm not partiucualrly fond of the # and, frankly, I don't see the > advantage. > > Also, instead of going through the system of type and status > attributes, woudl it not be preferable to just have an expiration > date? That would automatically indicate whether the Id is persistent > (please note spelling), expired, or whatever. > > - Arnold > > Ray Plante wrote: >
> > -------------------------------------------------------------------------- > 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/ > --------------------------------------------------------------------------
-- **************************************************************************** Alberto Accomazzi NASA Astrophysics Data System http://adswww.harvard.edu Harvard-Smithsonian Center for Astrophysics http://cfa-www.harvard.edu 60 Garden Street, MS 31, Cambridge, MA 02138 USA ****************************************************************************Received on 2003-09-17Z15:59:54