Display of simple and reified definitions

[saubin78]

Current situation

• only non reified definitions are correctly displayed
• for reified definitions, their URI only is displayed
• font is colored (according to each portal), italicised
• colored fonts seem to denote a clickable link, which is not relevant for definitions (inconsistency) + accessiblity issues

currently for reified definitions

currently for non reified definitions

Guiding Principles for Handling Definitions

1. Faithful rendering – no synthetic data

   • The portal never creates dates, identifiers, or provenance information that are not already present in the uploaded RDF.
   • Only the triples supplied by the data‑owner are displayed.

2. Simple (non‑reified) definitions

   • Represented by a plain skos:definition literal.
   • UI shows the definition text only – no “Reified” badge, no source column, no date column.

3. Reified definitions (the definition is a separate RDF node)

   • With source only – the UI adds a “Reified” badge, shows the source (inline or in a collapsible <details> element), and leaves the Date(s) column empty. If no row in the whole table contains a date, the Date(s) column is hidden.
   • With source and dates – the UI shows the badge, the source, and the dates. Dates are rendered with a <time> element (e.g., <time datetime="2022‑04‑15">15 Apr 2022</time>) and, when a modification date exists, a small “modified …” note.
   • With dates only (no source) – the UI shows the badge and the dates, but no source field.

4. Conditional column visibility

   • The Date(s) column is rendered only when at least one definition row contains either dct:created or dct:modified.
   • Empty Date(s) cells are hidden, and the whole column disappears if it would be completely empty.

5. Respect of information provided in the RS file

   • If a definition was supplied as a simple literal, it remains a simple line in the UI.
   • If a definition appears as a reified node, the UI respects the additional metadata attached to that node (source and/or dates). The portal never auto‑reifies a simple definition.

6. User‑driven provenance

   • The presence of the “Reified” badge signals to the user that the definition carries extra provenance information (source, creation date, modification date).
   • Absence of the badge indicates a plain, un‑annotated definition.

These principles ensure that the portal displays exactly what the contributor provided, while making provenance and temporal information visible whenever it exists, without introducing any artificial metadata.

Proposed presentation

Remaining questions

• could there be information about the definition other than the source citation, the creation and modification dates ?

Note: done with a little help from Argo (prompt, code and explanations)

[maboukerfa]

Reified

Multilinguism

[jonquet]

We discussed this quite a bit with @maboukerfa.

The problem is that we’d end up implementing something that only works for INRAETHES. Mohamed has already added some clauses/tests to check additional properties for AGROVOC, but that won’t work for BIODIVTHES. In the longer term, within the OntoPortal Alliance, this would just become another piece of portal-specific code.

So we’ll try to meet halfway and propose something a bit more generic. It will work for any URI in a semantic artifact that is not of a type we already recognize (i.e., outside the standard OWL or SKOS types). It will still check rdf:value, rdfs:label, and skos:prefLabel in an attempt to display a meaningful value for the URI rather than the URI itself.

As with reified labels, we’ll display the small reification icon (instead of the word “reified”). Clicking it will open a dialog showing everything we can find about that URI. As a result, the dialog will simply display entries such as dct:source: and, on the next line, dct:created: , because we don’t want to implement heuristics to recognize and interpret properties from Schema.org, Dublin Core Terms (DCT), IAO, or other vocabularies.

Let’s discuss this during the next technical iteration.