informatievlaanderen / oslothema-ldes Goto Github PK

Ik merk dat in de naamgevingen van de klassen, attributen en types dikwijls Nederlands en Engels door elkaar gebruikt wordt.
Het is consistenter om dit allemaal in dezelfde taal te doen en dan nog het liefst in het Engels. Ook al wordt hier gewerkt aan een Vlaamse standaard, er zullen ook niet-Nederlandstaligen werken met deze standaard. Bovendien zijn er voor sommige termen geen goed Nederlands alternatief waardoor je toch telkens moet teruggrijpen naar het Engels.
Je kan dus beter alle termen in het Engels zetten en waar nodig de mogelijkheid voorzien om waardes in meerdere talen te laten invullen.

Zie https://treecg.github.io/specification/#introduction

Er is nu een tree:ViewDescription klasse. Deze kan alsvolgt worden gebruikt:

ex:LDES1 a ldes:EventStream ; # or tree:Collection depending on what it is
    tree:view ex:Node1 .
  
ex:Node1 a tree:Node ;
  tree:viewDescription ex:Fragmentation1 ;
  tree:relation [
      # relations should of course be qualified with more triples
      tree:node <https://{host-location}/{ldes-view-short-name}/{another-fragment-id}>
  ] .
  
ex:Fragmentation1 a tree:ViewDescription ; 
  dcat:endpointURL ex:Node1 ; # One of the rootnotes from which you can access all members
  dcat:servesDataset ex:LDES1 ; # the LDES
  ldes:retentionPolicy [
    a ldes:DurationAgoPolicy ;
    # ...
  ].

Kunnen we deze minimale veranderingen ook doorvoeren in de OSLO LDES spec?

Niet alle systemen voorzien een logische delete (status vlag). Wat is de aangewezen manier om om te gaan met het publiceren van fysieke deletes in een bron (e.g. een retentie policy of alsnog een status voorzien oid.)?

Snapshots are defined as new collection, which makes it difficult for clients to discover the relation between snapshot and the LDES collection it was created from.
Defining a snapshot as a sort of view (maybe a distinct concept?) would make the whole more coherent.

Probleem met view zoals we het nu gebruikten:
2 definities:

1. Een tree:Node waarvia je alles kan bereiken → een tree:Node die verwezen wordt vanuit een ldes:EventStream via een tree:view property
2. Een specifieke indexering of fragmentatie van je dataset

In een brainstorm met @ddvlanck kwamen deze termen naar boven:

1. Voor definitie 1: een “RootNode”
2. Voor definitie 2: een “Fragmentatie”

Beide termen lijken interessant om semantiek aan te koppelen.

Deze issue werd opgeworpen eerder door @bertvannuffelen

Is het mogelijk om hier de agenda te documenteren voor de verschillende werkgroepen?

LDES servers could optionally export the tree relations of a node as a HTTP Link header.

This could help clients to speed up the data access (for instance, a forward proxy could perform prefetching of related fragments).

Issue gepost als Informatievlaanderen/OSLO-Discussion#407

Issues in deze repository dienen inhoudelijke en semantische issues met betrekking tot de verschillende OSLO domeinmodellen aan te kaarten. Om technische (broken links, verkeerde mapping van termen op URI's...) of editoriale (typo's, fouten in de HTML weergave...) problemen aan te kaarten verwijzen we naar de Data.Vlaanderen.be repository.

Model(len) waarop de issue van toepassing is:

Omschrijving van het probleem:
De definite van shape zegt: 'Een shape wordt opgelegd aan alle elementen van de LDES. Voorbeelden van zo'n shape zijn SHACL en ShEx. De shape moet cohorent zijn doorheen heel de Linked Data Event Stream

Daarmee zegt de definitie nog niet wat een shape net is - bv. dat het de properties beschrijft van de concepts of elements of data types...of zoiets
Omschrijving van een mogelijke oplossing: