Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEATURE: Generic Viewer #217

Open
agy-why opened this issue Sep 4, 2023 · 0 comments
Open

FEATURE: Generic Viewer #217

agy-why opened this issue Sep 4, 2023 · 0 comments
Labels

Comments

@agy-why
Copy link
Member

agy-why commented Sep 4, 2023

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.

@agy-why agy-why added this to the Next version milestone Sep 4, 2023
@kimakan kimakan removed this from the Next version milestone Jul 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants