
| ||||||||
| Changed: | ||||||||
| < < |
| |||||||
| > > |
| |||||||
| Deleted: | ||||||||
| < < |
| |||||||
| Changed: | ||||||||
| < < | In Obs/Tap , it is not a mandatory field, it could become important in future releases if its usage is well-defined. At the moment it is just free-format, and that could be an issue. | |||||||
| > > | ||||||||
| Added: | ||||||||
| > > | Regarding extensibility, I think we should take the advice of MarkusDemleitner regarding DataProduct, and have the values added as IVOA-controlled and registered enumerations. If possible, both a hierarchical and yuxtapositional notation (à la UCD) should be used. | |||||||
| Added: | ||||||||
| > > | Regarding obs_title, I do not think we should rely on it for discovery. We should try to push for obs_creator_did, or at least for obs_publisher_did, as the ways for PIs to refer to VO datasets in their literature. Conversely, use of bib_reference should be allowed for discovery, and substituted by a VARCHAR(19) (length of a bibcode), or bigger if DOIs where to be allowed (something like VARCHAR(2048) should cover most ground for existing DOIs. | |||||||
| Changed: | ||||||||
| < < | ||||||||
| > > | -- JuanDeDiosSantanderVela - 07 Mar 2011 | |||||||
| Added: | ||||||||
| > > | ||||||||
<--
| ||||||||