Database metadata (license, documentation, etc.)

[marcua]

A user might want to provide context about their database (e.g., license(s), readme/documentation).

There are three paths I can imagine this taking:

• A lightweight option to support this, like in user/entity profiles where we allow links, is to provide a collection of labeled links (e.g., license = https://github.com/user/dbproject/LICENSE.md).
• Alternatively, the contents of various metadata files can be stored in ayb in some form or another.
• Finally, it can be done by identifying a metadata table inside the database itself (e.g., _meta) where a user can add as many key/value pairs identifying the license/documentation that they would like. ayb can still provide convenience methods/commands to make it easy to update this content.

I lean toward options 1 (lightweight) or 3 (self-contained) but would like to hear from others and think on it for a bit.

[sofiaritz]

I like the third option the most :)

An ayb_meta table with a definition like this:

CREATE TABLE ayb_meta IF NOT EXISTS (
    meta_key VARCHAR NOT NULL,
    link VARCHAR CHECK(content IS NULL),
    content VARCHAR CHECK(link IS NULL)
);

That way people can choose to either use a link or to store the content in the database. What do you think?

[marcua]

Overall I like it! You can even render content as markdown, etc.

Perhaps ayb's DB can store the (optional) name of the metadata table in case the user doesn't want us imposing a name on them.

The downside of this approach (which I really like, not a reason not to continue exploring it) is that it requires a query to the user's DB, so it's harder to support things like cross-dataset search (e.g., "Show me all public domain-licensed datasets"). If that sort of stuff is really important, you could imagine indexing/caching some of the data in ayb, but I'm getting ahead of myself given how we're most likely to use this data :).

I really like that approach 3 has the metadata travel with the database if it gets forked/copied.