FEATURE: Generic Viewer

[agy-why]

Daiquiri allows to publish Tabular Data but also Object Data.

An object usually consist of several representations: partly stored in one or several tables, but also represented as one or several downloadable file. It may also have some preview or documentation, and most of the time we also give it a DOI.

Due to the variability of an Object, it is useful to design a so called viewer: an automatically generated web page that organize and represent the Object in a concise form.

Until now, gathering all the aspect of an object, tabular data, files, previews, doi... required insider knowledge about the structure of the database and systematically required (complex) adapters, even apps in some cases.

It seems that we the new version of Daiquiri we found a universal way to describe an object (thanks to Datalink), allowing us to gather all the necessary information from an object without having to write an adapter:

Identifier

An object need to be identified via an identifier, the latter is used as a datalinkID preffixed by the type of object we are describing:
datalink_ID = <type-of-object>/<object-id>

For instance in rave-survey.org:
https://www.rave-survey.org/datalink/fields/20120403_0815m47/
The datalinkID = fields/20120403_0815m47 the latter is also the path to the viewer:
https://www.rave-survey.org/fields/20120403_0815m47/

DOI

The doi of an object can be found in the datalink table: semantic: #doi

Tabular Information

For a given object the tabular information is often store in several tables, and may contain a large number of values.
In order to access the information from these tables, they all need to have a foreign key of the identifier: <object_id>.
Additionally to declare which information need to be visible on the viewer the ucd meta.main should be used. This ucd, declares which column can be considered as main part of the data. This is also used by the conesearch service.

Nevertheless in order to gather the main information from the table without any knowledge about the structure of the DB, one needs to declare which table is relevant for which object. This could be done via settings, but since it is relevant for findability, we suggest to use datalink for this purpose.

In this case for each object one needs to declare a new entry for each auxiliary table like:

datalink_id	access_url	description	semantics	content_type	content_size
<objtype>/<obj_id>	<base_url>/metadata/<schema>.<table>	Auxiliary table containing further information	#auxiliary	appliaction/html	0

Thanks to this entries, the datalink service can be queried with the corresponsing datalink_id and will provide a list of table that should be queries to gather the content related to the object.

Files and Previews

Files and previous are downloadable resources. Their download URL need to be provided and their URI for visualization, additionally one would like to see the size of the resources and its type.

All this information are available via the datalink service. And can be gathered automatically.

Rendering

The rendering could be done flexible by providing templates and templatetags to allow the framework user to render the default context in the way it fits to the instance.