|   | 
				
					
	
		  | 
	 
	
		| Paper: | 
		Building an Archive Backbone Extending TAP | 
	 
	
		| Volume: | 
		485, Astronomical Data Analysis Software and Systems XXIII | 
	 
	
		| Page: | 
		139 | 
	 
	
		| Authors: | 
		Molinaro, M.; Apollo, P.; Knapic, C.; Smareglia, R. | 
	 
	
	
		| Abstract: | 
		A data center (DC) willing to add VO (Virtual Observatory) 
 capabilities to existing archival resources, or new ones, will 
 probably face some issues regarding the constraints on the existing 
   structure of the datasets. On the opposite direction a DC may 
 want to give priority to VO flavored data access but maintain 
 flexibility on proprietary or dedicated access solutions. This 
 contribution tries to delineate a solution, feasible for both 
 approaches, taking advantage of the IVOA (International Virtual 
 Observatory Alliance) existing standards and, at the same time, 
 forcing no constraint at archive generation or ingestion level. The 
 IVOA TAP (Table Access Protocol) specification generalizes the way a 
 set of database schemas and tables, related or not, can be deployed as 
 a queryable resource in the framewok of the Virtual Observatory. The 
 TAP protocol itself has, at its core, a DB schema, named 
 TAP_SCHEMA, that actually acts as an attribute-extended 
 information schema for the exposed set of tables; the 
 TAP_SCHEMA, in short, describes the content of the schemas and 
 tables, and their connections, in a VO aware flavour. It seems then 
 quite immediate to think about pushing the generalization step a 
 little further, i.e. to extend the TAP_SCHEMA itself to provide 
 a more general description of an astrophysical archive (or part of 
 it). Here we discuss on how, adding optional tables and columns to the 
 TAP_SCHEMA, it would be possible to create an archive thin 
 layer solution in terms of this DB schema alongside with a content 
 manager application for it. The goal is to provide a re-usable, 
 configurable connection between an archive's back end and front end, 
 having the benefit of creating a VO translation layer to ease VO 
 resource and service deployment and preserving custom data access and 
 publishing. | 
	 
	
		| 
			
			
		 | 
	 
	
		  | 
	 
 
					 
				 | 
				  |