Skip to content

2026-06-27 git revert vs git reset --hard

arcangelo7
arcangelo7Jun 10, 2026 · opencitations/ramose

fix(skgif): normalize local identifier URLs with merged scheme slashes [release]

Reverse proxies such as Traefik sanitize request paths by collapsing duplicate slashes, so a full URL passed as local identifier reaches the API as "https:/example.org/...". The new normalize_local_identifier_url preprocess function restores the scheme separator, so specs can accept both the canonical and the merged form.

arcangelo7
arcangelo7Jun 11, 2026 · opencitations/ramose

feat(skgif): add per-triplestore text-search backend addon modules

The package default keeps FILTER CONTAINS for endpoints without a text index; the blazegraph, fuseki, graphdb, qlever and virtuoso modules override that behaviour. They can be imported as ramose.skgif_addon.virtuoso, ramose.skgif_addon.qlever, ecc.

arcangelo7
arcangelo7Jun 15, 2026 · opencitations/ramose

fix(skg-if): emit single_entity meta for single-entity lookups [release]

La nuova BBuusta di metadati per products/{local_identifier}

"meta": {
"local_identifier": "https://example.com/skg-if/api/products/product-1-fgp",
"entity_type": "single_entity",
"api_items": [
{
"local_identifier": "person-5-mw",
"urls": [
{
"entity_type": "link",
"rel": "self",
"href": "https://example.com/skg-if/api/persons/person-5-mw"
}
]
},
{
"local_identifier": "affiliation-organisation-1",
"urls": [
{
"entity_type": "link",
"rel": "self",
"href": "https://example.com/skg-if/api/organisations/affiliation-organisation-1"
}
]
},
{
"local_identifier": "datasource-1-aa",
"urls": [
{
"entity_type": "link",
"rel": "self",
"href": "https://example.com/skg-if/api/datasources/datasource-1-aa"
}
]
},
{
"local_identifier": "venue-5-sd",
"urls": [
{
"entity_type": "link",
"rel": "self",
"href": "https://example.com/skg-if/api/venues/venue-5-sd"
}
]
}
]
}

Io ho implementato e local_identifier e “entity_type”: “single_entity”, che sono obbligatori. api_items lo metto?

#custom_params continua a funzionare come già funziona, ma con una possibilità in più. Se come handler del parametro custom specifichi una funzione, te la implementi tu e di sicuro puoi farci più cose. In alternativa, al posto del nome della funzione, puoi indicare il percorso a un file YAML.

Il file mappa ogni filtro ai “buchi” della query. Per ogni filtro la chiave è il nome con cui lo si invoca nella richiesta; sotto, dici in quale placeholder [[...]] della query SPARQL va iniettato il frammento, e qual è il frammento. Il valore passato nella richiesta entra nel frammento dove scrivi {{value}}.

Nel file hf hai

#custom_params filter,ocdm.yaml,preprocess,Search filter.

Esempio:

identifiers.id:
filter: "?product datacite:hasIdentifier [ literal:hasLiteralValue {{value}} ] ."
cf.cites:
filter_preamble: |
@@with source=index
SELECT ?product WHERE { ?ci cito:hasCitedEntity {{value}} ;
cito:hasCitingEntity ?product . }
@@join ?product ?product type=inner

Dove la query dell’operazione è:

SELECT ?product ?title WHERE {
[[filter_preamble]]
?product dcterms:title ?title .
[[filter]]
}

Ripristinare un’entità ripristinava l’intero vicinato di un’entità. Ripristinare il ra di un’autore ripristinava anche la br collegata nel grafo corrente: i suoi link tornavano a puntare agli ar originali. C’era un bug per cui le entità correlate venivano scoperte solo nel grafo corrente e non in quello storico, per cui se ad esempio avevo cancellato gli ar originali, ecco che la br perdeva tutti i ruoli connessi al ripristino di un ra collegato.

Tuttavia, trovo che ripristinare tutte le entità collegate sia una cosa un po’ pazzerella. L’utente, quando clicca restore, si aspetta di ripristinare quell’entità e quelle modificate nella transazione di quell’entità, tipo un ra e l’id collegato, non anche le br associate e gli ar associati ecc.

Il revert co-transazionale equivale a un git revert. Il revert del vicinato completo equivale a un git reset —hard dell’intero repo. Mi sembra un po’ too much.

Scegliendo di applicare la semantica del git revert non pregiudica di ottenere il risultato del git rest. Basta scegliere la radice giusta, mentre la semantica opposta sarebbe più vincolante.

Per essere chiaro, non è solo un problema di direzionalità dei collegamenti. Il problema non è solo recuperare le entità che referenziano quella corrente come oggetto e includerle nel revert, ma anche includere nel revert quelle collegate come oggetto diretto o indiretto all’entità corrente. Cambia solo la scala del problema, ma il problema rimane.

Esempio, ripristino un br alla versione T. Un altro utente, la settimana scorsa (dopo T), ha corretto un refuso nel literal di un identifier, in un salvataggio che non c’entrava nulla col br. Restore-a-T outgoing-only: l’identifier torna al valore sbagliato.

Per revert co-transazionale mi riferisco al revert delle operazioni eseguite nello stesso salvataggio: ripristinando un’entità a una versione T, vengono annullate le sue modifiche successive a T e, per ogni entità correlata, soltanto le modifiche scritte negli stessi salvataggi che si stanno annullando (riconoscibili dal prov:generatedAtTime condiviso), lasciando intatte quelle ricevute in operazioni indipendenti.

C’è però un problema a livello di interfaccia, perché se l’utente va a ispezionare la storia di un’entità, vedrà anche lo stato vecchio delle entità correlate. Quindi facendo un revert potrebbe aspettarsi di ripristinare anche le identità correlate per come le ha viste nella versione vecchia. Tuttavia io mi aspetto che un utente che fa un revert vada ad annullare le proprie azioni, le proprie modifiche, non le modifiche del mondo. Cioè non mi aspetto che l’utente faccia un audit completo di tutte le entità correlate quando fa un revert

arcangelo7
arcangelo7Jun 13, 2026 · opencitations/heritrace

fix(restore): scope version restore to the transactions being undone

Restoring a version rebuilt every related entity from its snapshot at the target time, which also reverted changes those entities received in unrelated later transactions.

Io non ho idea di come rendere i filtri di SKF-IF agnostici rispetto al data model e riutilizzabili dalla community. Al momento il parametro custom “filter” è associato ad un addon che inietta nella query SPARQL i predicati dell’OCDM.

Secondo me dovrebbe essere discussa e entrare in specifica una paginazione di default quando l’utente non specifica nulla nelle ricerche. È impensabile ritornare una lista piatta di tutto come default.