Proposal to extend ResourceBase model with an extended abstract field

[giohappy]

The current abstract field supports HTML inputs, through the metadata editor. This poses several problems in places where a full HTML representation is not supported. For example the short abstracts inside the client cards, but also the CSW output.

My proposal is to add a new "extended abstract" field (we might name it description?) to ResourceBase to support HTML content and revert the abstract to a plaintext field. This way

• the CSW model doesn't need to use raw_abstract anymore (which is the HTML abstract stripped of the HTML tags)
• the client cards can safely use the abstract field without breaking the layout
• the long description, as in the preview and info panel, can use the extended abstract with HTML content rendered

Opinions @afabiani @gannebamm @t-book and anyone else?

[afabiani]

👍 here

[etj]

I see that ResourceBase already contains lots of "big" metadata fields that are seldom used.
Being ResourceBase one of the main classes in the whole model, it is often queried, and its fields undergo continuous ORM processing, even when they are not used, which is most of the times.

Before adding other big fields within RB (or while doing it, since we are talking about quite a different amount of work), I guess it's time to think about splitting this class in order to have operative fields (owner, group, *published) and metadata fields (usually long descriptive strings) in different 1:1 tables.

I don't want to hijack this issue, but I guess the beginning of this kind of discussion belongs here.

[giohappy]

I totally agree @etj. I would add the need for a proper solution to having HTML contents mixed with raw metadata to your consideration.

BTW the intention of this issue is just to alleviate the problem with the HTML and abstract field.

[gannebamm]

The question is what kind of HTML content is currently stored in the abstract field. Browsing through our resources I see mostly links to other GeoNode ResourceBase objects or external Resources. Since ResourceBase is also used for documents, which sometimes do not explicitly are spatial (even though implicitly 99% of the time as we geo-people know), and GeoApps the base model should keep things simple. For me, simple is something like DublinCore and not the full-blown ISO-19139. It should guarantee that every ResourceBase can be properly used in the new UI and via the API v2 and therefore provide enough fields for faceted search.

At the same time, I would like to keep the linking functionality intact and later maybe extend it even further (think of gmd:Lineage by linking to source datasets and workflows). Currently, linking to other ResourceBase objects is only part of the document model.

We as a research institute with several data domains would like to have a base metadata model and the option to choose between different more sophisticated and complex metadata schemas which are linked to the ResourceBase model. Some part of this functionality is now possible through the JSON field (#8689), which is great but not yet fully integrated into the UI. This is something we will provide funding for if there is enough need, and a mid-term project.

[giohappy]

@gannebamm your's and @etj's comments are the foundation for a review of the metadata model and its relationship with the ResourceBase model, which also includes information only functional to the API and the client.

With regards to HTML contents (which can be set not only for abstract but also purpose, supplement information, etc.) I would drop the ability to set HTML content for metadata fields. The idea of employing those ResourceBase fields to let users format web content was unfortunate IMHO. It was a simple solution, but we are paying for it now.

So I push the idea even forward: revert the HTML editors and the raw_* to only use plain and, if anything, implement specific (non-metadata) fields specifically for web content formatting.