Skip to content
This repository has been archived by the owner on Oct 30, 2024. It is now read-only.

Metadata #17

Open
dirkroorda opened this issue Oct 25, 2022 · 3 comments
Open

Metadata #17

dirkroorda opened this issue Oct 25, 2022 · 3 comments

Comments

@dirkroorda
Copy link
Collaborator

dirkroorda commented Oct 25, 2022

We are going to handle metadata in the following way:

Build a profile with a set of metadata components for pure3d on the Component-Registry.

That will be a public, documented set of metadata fields, freely chosen by the Pure3D project, with possible re-use of already defined components.

The HuC has a tool to generate Javascript+Json out of this profile, that we can readily integrate into the pure3d backbone, and voilà: we have metadatafields where we want, readonly or editable, whatever is needed.

Things to do:

Define and select

for: DANS + @CPapadopoulos84 + @kgschoueri + @sohinimallick16

Make a selection of metadata fields per concept:

  • project
  • edition
  • scene (optional)
  • media file (optional)

Register

for: @sohinimallick16, @dirkroorda

Make a profile at the Component Registry and register all chosen metadata fields

Integrate

for: @dirkroorda @robzeeman

Bake the registered metadata into static asset files (@robzeeman) and integrate them in the backbone (@dirkroorda).
Especially, write authorised handlers on the server to receive saved metadata values.

@ValentijnG
Copy link

ValentijnG commented Nov 4, 2022

Hi Dirk, all,

Thank you for taking the initiative on this issue. I am going to be more involved on this topic from the side of DANS. I suggest that I will, over the course of the following workdays, make a clear overview in here of the metadata fields which would be mandatory for deposits in Dataverse (/DANS Data Station) and additionally list metadata fields which I (we) consider highly recommendable.
The DANS Data Station should serve as the location for sustainable long-term preservation of data, therefore we will need to align metadata and make use of persistent identifiers to and from the interactive pages on pure3d.edu.

@dirkroorda
Copy link
Collaborator Author

Hi @ValentijnG ,
the metadata has multiple uses:

  • it will also appear in various places on the interface, as project titles, markdown descriptions of editions, etc.
  • it is also the way by which edition writers communicate their work

So it is important that Pure3D people and DANS people negotiate about this.

So far we have not decided that the contents of the Pure3D system will be archived in DANS Dataverse. It could also be archived in a HuC repository. Or both.

@dirkroorda
Copy link
Collaborator Author

Update after talk with @robzeeman: We will not use generate code for handling metadata. Reasons are

  • the baked code is for editing complete metadata sheets; we also need to edit metadata in place, i.e. in other places
    on the interface, wherever it may be displayed
  • the baked code is a bit rigid in that it does not deal with values taken from a table that is filled dynamically
  • we also let the system fill in metadata
  • the datamodel that the pure3d app maintains for the metadata is far simpler than the more generic model of the
    component registry. We prefer to stick with the minimum complexity that is needed to make the app work.

At a higher level there is a tension between

  1. making the app metadata-driven: that means that the metadata model is part of the data design of the application
  2. support metadata in full generality: that means that the metadata model is designed to cover all the
    representational needs of all possible metadata

In order to resolve this tension, it would be needed to build a bridge between the two metadata models. But that seems overly complex in view of the alternative:

  • use a simple metadata model
  • write generic code to CRUD individual fields (python and javascript)
  • invoke that code wherever it is needed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants