The KNOT Data Model - Overview

Come spiegato nella panoramica di KNOT-DM, il data model è incentrato sull'intersezione di tre domini che riflettono aspetti specifici del tema centrale del progetto:

Questa intersezione fornisce lo schema strutturale del KNOT-DM, che è organizzato in tre segmenti che riflettono le specificità di ciascun dominio e fanno uso di concetti di uno standard riconosciuto a livello internazionale per descrivere entità, attività, agenti, temi, relazioni e informazioni spazio-temporali. I segmenti e i relativi standard sono:

Le figure 1 e 2 riassumono il nucleo di KNOT-DM evidenziando le classi chiave (caselle gialle), le proprietà (frecce) di ogni standard e la loro interconnessione, nonché la relazione con esempi di istanze di classi (punti rosa) centrali per il progetto. Ulteriori dettagli sull'estensione di ciascun segmento e sulla notazione utilizzata nel progetto sono forniti nella sezione successiva.

FIG 1. Una sintesi dei diversi segmenti che compongono KNOT-DM.
FIG 2. Un riepilogo delle classi principali e delle proprietà che compongono KNOT-DM.

L'uso di standard riconosciuti e complementari a livello internazionale deriva da una decisione iniziale di design secondo la quale KNOT-DM dovrebbe essere incentrato sulla riutilizzabilità piuttosto che sulla creazione di nuovi componenti ontologici, al fine di consentire la flessibilità e garantire la compatibilità finale con l'infrastruttura della Digital Library. Questo è esemplificato dall'uso di DCAT, che è lo standard utilizzato dal Dipartimento per la trasformazione digitale ed è una delle ontologie raccomandate dalla rete nazionale OntoPia di ontologie e vocabolari controllati promossa dal Ministero della Cultura e dalla Digital Library. Inoltre, questa flessibilità dovrebbe consentire al progetto KNOT di integrare le informazioni e i dati già esistenti della ricerca accademica, per ridurre al minimo le duplicazioni e favorire l'interconnessione. Una prima area di interesse in questo senso è l'esplorazione di come KNOT possa integrarsi con il sistema di gestione della ricerca IRIS offerto agli Atenei dal CINECA.

Tutti i termini e i concetti di KNOT-DM sono raccolti ed espressi in RDF attraverso l'Ontologia KNOT (KNOT-O), mentre alcuni dei requisiti tematici e di indicizzazione sono espressi in RDF attraverso la Tassonomia KNOT e il Thesaurus tecnologico KNOT, due vocabolari controllati basati sul modello di dati SKOS. L'uso di standard esistenti basati su, o adattati a, RDF consente al progetto KNOT di pubblicare i suoi metadati come Linked Open Data (LOD) per garantire la leggibilità automatica e massimizzare l'interoperabilità con altri dati aperti disponibili online.

La metodologia SAMOD è stata utilizzata come punto di riferimento nello sviluppo del KNOT-DM per creare un flusso di lavoro iterativo: una volta scelto il tema centrale, il dominio è stato progettato ricercando e valutando gli standard esistenti rispetto a una prima serie di requisiti ricavati in parte dalle informazioni acquisite durante il censimento dei progetti di ricerca esistenti; ogni standard è stato poi assemblato in un segmento e valutato rispetto a una prima serie di domande di competenza (chi, cosa, dove, quando, come) modellando un piccolo sottoinsieme di dati del censimento (12 voci); in seguito sono stati apportati ulteriori perfezionamenti agli elementi degli standard che il modello doveva utilizzare e al modo in cui dovevano essere collegati e usati; le intuizioni di questa fase hanno portato anche alla creazione dei vocabolari controllati; infine, è stata creata la prima versione dell'ontologia e della documentazione del data model, attingendo alle intuizioni acquisite in ogni fase precedente.

Dopo la pubblicazione della prima versione del data model nell'estate del 2023, la valutazione continuerà con particolare attenzione alla capacità del modello di rispondere ai requisiti dell'integrazione del progetto nell'infrastruttura nazionale..

Tutti gli elementi del KNOT-DM, compresi KNOT-O e i vocabolari controllati KNOT Taxonomy e KNOT Technological Thesaurus, sono pubblicati in inglese e in italiano e sono disponibili su GitHub con licenza CC BY-NC 4.0.

Il KNOT Data Model - Segmenti

Le tab sottostanti forniscono maggiori dettagli su ciascun segmento, con particolare attenzione alle classi chiave e al loro utilizzo. Si veda la sezione Moduli per gli esempi pratici e la sezione Ontologia per i dettagli completi di tutte le proprietà e le classi.

La seguente legenda si applica a tutte le rappresentazioni grafiche e le evidenziazioni testuali basate sul "Graphical Framework for OWL Ontologies" [7]: una casella gialla indica una classe, una freccia blu indica una object property, una freccia verde indica una data property, una freccia nera indica un predicato tra due entità e un punto rosa indica un'istanza di una classe (anche chiamato individuo).

Il progetto di ricerca come dati pubblici

Le figure da 3 a 5 forniscono una panoramica completa del segmento dei dati pubblici di KNOT-DM, che è il più grande in termini di classi e proprietà disponibili per l'uso. Ogni figura illustra in dettaglio le proprietà e le classi collegate a uno dei quattro concetti centrali di DCAT: Catalog, Dataset, Data Service e Distribution.

La Figura 3 illustra la prima parte del segmento, incentrata su dcat:Catalog. Questa classe è definita all'interno di KNOT-DM come un "catalogo o repository che ospita i dataset o i servizi di dati che vengono descritti" [8], sulla base del profilo applicativo DCAT. Prende anche in considerazione la definizione della specifica W3C, "una raccolta curata di metadati su risorse (ad esempio, insiemi di dati e servizi di dati nel contesto di un catalogo di dati)" [1], e una nota d'uso secondo cui i cataloghi di dati basati sul web rappresentano una singola istanza di questa classe.

Queste definizioni sono il punto di partenza per la concettualizzazione della classe Catalog come rappresentazione dei progetti di ricerca intesi come collettori di risultati, invece di attività. L'esempio più comune e pratico di questa concettualizzazione è un sito web in cui l'attività e i risultati del progetto di ricerca sono documentati (rappresentando la raccolta curata di metadati su risorse) e resi disponibili al pubblico, sia tramite download diretto che attraverso l'interazione con interfacce utente specifiche (rappresentando l'hosting di dataset o servizi di dati).

Inoltre, la specifica W3C di DCAT rende esplicitamente dcat:Catalog una sottoclasse di dcat:Dataset, il che aggiunge un altro livello a questa concettualizzazione, consentendo a KNOT-DM di trattare il contenitore come un'altra forma di output dell'attività del progetto di ricerca.

FIG 3. Classe DCAT Catalog con tutte le connessioni.

La figura 4 illustra la seconda parte del segmento, incentrata su dcat:Dataset. È definita all'interno di KNOT-DM come "una collezione di dati pubblicati o curati da un singolo agente, e disponibili per l'accesso o il download in una o più rappresentazioni" sulla base della specifica W3C e di una nota aggiuntiva che afferma "i dati si presentano in molte forme, inclusi numeri, parole, pixel, immagini, suoni e altri multi-media, e potenzialmente altri tipi, ognuno dei quali potrebbe essere raccolto in un dataset". [1]

In KNOT-DM questa classe è una delle rappresentazione degli scholarly digital objects, qualunque sia la loro forma (ovvero, siano essi dataset o meno). Quest'ultimo punto è fondamentale perché, mentre lo standard DCAT è utilizzato principalmente nell'UE e in Italia per classificare i dataset di enti pubblici, come le agenzie governative, KNOT-DM lo utilizza per coprire tutti i tipi di scholarly digital objects: un software, un corpus testuale, un database relazionale, una raccolta di immagini annotate, una mappa interattiva o un servizio di visualizzazione.

Questa classe offre anche una connessione diretta al segmento di provenienza accademica di KNOT-DM attraverso prov:wasGeneratedBy, che DCAT include per consentire agli utenti di "descrivere ulteriormente l'attività che ha generato un dataset". [1] Le specifiche DCAT indicano che per utilizzare questa proprietà la risorsa di contesto deve essere classificata come prov:Entity, che è l'approccio adottato da KNOT-DM. Questo approccio alla classificazione multipla delle istanze è descritto in dettaglio nella sezione relativa alle classi concettualmente simili.

FIG 4. Classe DCAT Dataset class con tutte le connessioni.

La Figura 5 illustra la terza e ultima parte del segmento dei dati pubblici, incentrata sulle dcat:Distribution e dcat:DataService. Queste due classi sono state raggruppate insieme perché sono strettamente collegate tra loro in quanto danno accesso ai dati inclusi nel catalogo, ma presentano alcune differenze fondamentali.

Una distribution è definita all'interno di KNOT-DM come una "forma accessibile di un set di dati, come un file scaricabile" [1], sulla base della specifica W3C. Tuttavia, il termine "forma accessibile" potrebbe essere interpretato come comprendente forme non scaricabili e quindi KNOT-DM rende esplicita la limitazione della Distribution alle forme scaricabili (questo è anche implicito nelle note d'uso e nelle definizioni di DCAT AP). Un Data Service è definito all'interno di KNOT-DM come "un insieme di operazioni che fornisce l'accesso a uno o più insiemi di dati o funzioni di elaborazione dati", sulla base della specifica DCAT AP [8].

Inoltre, KNOT-DM fa esplicito riferimento alla nota d'uso inclusa in DCAT AP 2.1.1 relativa alle distinzioni tra queste due classi, che aggiunge le seguenti dimensioni concettuali a entrambe [9]:

  • Una distribuzione non può esistere senza il suo dataset, mentre sia il dataset che il data service sono entità concettuali a sé stanti.
  • Non è necessario che una distribuzione sia il risultato di operazioni del data service.
  • Tutto ciò che non è destinato a fornire una forma scaricabile di un dataset è un data service.
  • Un data service offre modi più intelligenti e interattivi per accedere ai dati.

dcat:Distribution rappresenta la sola forma scaricabile di un dataset, ed è possibile che un dataset esista senza di essa, come ad esempio quando un database relazionale è accessibile tramite un'interfaccia di ricerca ma non direttamente per il download. dcat:DataService rappresenta tutti gli altri servizi web che consentono all'utente di accedere ai dati contenuti in un dataset attraverso un numero qualsiasi di funzioni di elaborazione. Per seguire l'esempio precedente, in questo caso l'interfaccia di ricerca per il database relazionale costituirebbe un data service. Nell'ambito del progetto KNOT, i data service possono rappresentare qualsiasi cosa, dagli endpoint API alle interfacce di ricerca dei siti web e i servizi di analisi. In molti casi è possibile che il data service faccia parte dello stesso sito web che è concettualizzato come dcat:Catalog. Pertanto, il sito web di un progetto di ricerca può svolgere la funzione concettuale sia di contenitore dei risultati del progetto, raccogliendo i (meta)dati pertinenti in un unico luogo, sia (in parte) di data service che dà accesso ai dati sottostanti e alle funzioni di elaborazione dei dati per interagire con essi, come le funzionalità di ricerca (per usare uno degli esempi più comuni). Infine, in virtù della sua capacità di fornire agli utenti l'accesso agli dataset, un data service creato durante l'attività di ricerca può anche essere concettualizzato come un altro tipo di output della ricerca e quindi classificato come prov:Entity.

FIG 5. Classi DCAT Data Service e Distribution con tutte le connessioni.

Un esempio pratico

La Figura 6 descrive in dettaglio un esempio pratico semplificato di come le quattro classi DCAT si uniscono in KNOT-DM: un progetto di ricerca si svolge nel corso di 2 anni con l'obiettivo di creare un dataset di immagini e renderlo disponibile agli utenti per l'interazione tramite un'interfaccia web e tramite download. I risultati finali del progetto sono: un sito Web, che contiene tutti gli output e la documentazione (rappresentati da dcat:Catalog, dcat:dataset, e dcat:service), nonché una sezione in cui gli utenti possono interagire con i contenuti del dataset tramite varie funzionalità (rappresentate da dcat:DataService e dcat:servesDataset) e il dataset stesso (rappresentato da dcat:Dataset). Quest'ultimo è anche reso disponibile per il download diretto per incoraggiare un ulteriore utilizzo (rappresentato da dcat:Distribution and dcat:distribution). Il dataset, data service e il sito Web sono collegati all'attività del progetto di ricerca, che è modellato utilizzando PROV-O come dettagliato nella sezione successiva (rappresentata da prov:Activity e prov:wasGeneratedBy).

FIG 6. Un esempio pratico che riassume come le classi principali DCAT vengono utilizzate per descrivere il progetto di ricerca come dati.

Si vede la sezione Moduli per ulteriori esempi pratici dettagliati di come questo segmento può essere utilizzato per descrivere progetti di ricerca accademica e la sezione Ontologia per le definizioni di tutte le diverse proprietà e classi.

Il progetto di ricerca come attività accademica

La Figura 7 fornisce una panoramica completa del segmento di provenienza accademica di KNOT-DM, che è incentrato su due classi PROV-O: Activity ed Entity.

prov:Activity è definita come "qualcosa che avviene in un periodo di tempo e agisce su o con entità; può includere il consumo, l'elaborazione, la trasformazione, la modifica, il trasferimento, l'uso o la generazione di entità" [2]. All'interno di KNOT-DM questo rappresenta i progetti di ricerca come attività, che a loro volta utilizzano e generano entità. Pertanto, all'interno di KNOT-DM un progetto di ricerca è identificato da due individui: una istanza di dcat:Catalog, per rappresentare il suo ruolo di contenitore di output, e una istanza di prov:Activity, per rappresentare il suo ruolo di attività, con la proprietà prov:wasGeneratedBy che li collega e rende esplicito che l'attività ha generato tutti gli output, incluso il contenitore.

prov:Entity è definita come "un oggetto fisico, digitale, concettuale o di altro tipo con alcuni aspetti fissi; le entità possono essere reali o immaginarie" [2]. All'interno di KNOT-DM rappresenta gli scholarly digital objects e anche le cose usate da un attività come concetti o oggetti fisici o digitali. Come menzionato nella sezione precedente, ciò significa che gli output della ricerca sono classificati come individui appartenenti a entrambe DCAT e PROV-O, al fine di soddisfare la connessione tra i segmenti dati pubblici e provenienza accademica.

Le relazioni tra queste due classi PROV-O possono essere dettagliate in vari modi. Le proprietà prov:used, prov:wasInfluencedBy, prov:generated e dct:subject collegano un'attività a un'entità (incluso concetti), mentre prov:wasInformedBy collega due attività insieme per indicare una condivisione di entità e prov:wasDerivedFrom collega due entità insieme per indicare una trasformazione. dct:isReferencedBy puo collegare un'attività alle sue pubblicazione. Si veda la sezione Moduli per i dettagli sul loro utilizzo.

Lastly the range of the prov:wasInformedBy property, which is used to connect two activities within PROV-O, was extended to also include crmdig:D7_Digital_Machine_Event in order to establish a clear connection between the Academic Provenance and Cultural Heritage Information Segments of KNOT-DM, similar to the connection created by the prov:wasGeneratedBy property. More details on this connection are given in the Cultural Heritage Information section.

Infine, il range di prov:wasInformedBy è stato esteso anche a crmdig:D7_Digital_Machine_Event, al fine di stabilire una chiara connessione tra i segmenti della provenienza accademica e del patrimonio culturale del KNOT-DM, in modo simile alla connessione con il segmento dati pubblici creata da prov:wasGeneratedBy. Maggiori dettagli su questa connessione sono riportati nella scheda del segmento sul patrimonio culturale.

FIG 7. Riassunto delle classi e proprietà PROV-O usato da KNOT-DM per descrivere la provenienza accademica.

Un esempio pratico continuato

La Figura 8 descrive la continuazione dell'esempio pratico che abbiamo iniziato nella sezione precedente, mostrando ora come vengono utilizzate le classi principali in PROV-O: il nostro progetto di ricerca ha generato tre entità (rappresentate da prov:Activity, prov:generated, e prov:Entity): il sito Web, il dataset e il servizio dati (ognuno dei quali è anche classificato utilizzando DCAT come indicato in precedenza). Il progetto, articolato attraverso la sua domanda di ricerca, intende esplorare l'architettura medievale italiana, che è quindi un concetto che ha influenzato l'attività di ricerca ed è il suo soggetto (rappresentata da prov:Entity, prov:wasInfluencedBy e dct:subject). Il progetto ha anche utilizzato raccolte di immagini esistenti per assemblare il suo dataset finale, rendendo quest'ultimo una derivazione (rappresentata da prov:used e prov:wasDerivedFrom).

FIG 8. Un esempio pratico che riassume come le classi principali PROV-O vengono utilizzate per descrivere il progetto di ricerca come attività accademica.

Si vede la sezione Moduli per ulteriori esempi pratici dettagliati di come questo segmento può essere utilizzato per descrivere progetti di ricerca accademica e la sezione Ontologia per le definizioni di tutte le diverse proprietà e classi.

Il progetto di ricerca come patrimonio culturale

La Figura 9 fornisce una panoramica completa del segmento sul patrimonio culturale diKNOT-DM, che è incentrato sulle classi chiave delle estensioni CIDOC CRMdig - D7 Digital Machine Event e D1 Digital Object - e LRMoo (FKA FRBRoo) - F5 Item e F3 Manifestation.

crmdig:D7_Digital_Machine_Event comprende "eventi che accadono su dispositivi digitali fisici a seguito di un'attività umana che ha intenzionalmente causato il suo inizio immediato o ritardato e risulta nella creazione di una nuova istanza di D1 Digital Object per conto dell'attore umano" [4]. crmdig:D1_Digital_Object comprende "elementi immateriali identificabili che possono essere rappresentati come insiemi di sequenze di bit, come dataset, testi elettronici, immagini, elementi audio o video, software, ecc. e sono documentati come singole unità" [4].

All'interno di KNOT-DM le istanze di D7 e delle sue sottoclassi (che coprono tipi più specifici di attività che possono avere luogo su un dispositivo digitale) rappresentano attività specifiche all'interno di un'attività di ricerca più generale (una prov:Activity) e sono collegate ad essa da prov:wasInformedBy, come descritto nella sezione precedente.

Le istanze di D1 e delle sue sottoclassi (che coprono tipi più specifici di oggetti digitali) sono un'altro modo di rappresentare scholarly digital objects e gli oggetti usati dentro un progetto di ricerca, ma specificamente limitati all'ambito digitale (nel caso degli scholarly digital objects) e nel contesto del patrimonio culturale, una dimensione che non è esplicita né in DCAT né in PROV-O.

KNOT-DM fa uso di due sottoclassi di D7: crmdig:D2_Digitization_Process, che rappresenta l'attività specifica di trasformazione di un oggetto fisico in uno digitale, e crmdig:D10_Software_Execution, che può essere utilizzata per rappresentare attività computazionali o di software più generiche eseguite su un dispositivo digitale, come ad esempio la trasformazione di stringhe di testo in XML. Il data model si avvale anche di due sottoclassi di D1: crmdig:D9_Data_Object, che rappresenta istanze specifiche di D1 che contengono proprietà quantitative (come ad esempio un corpus linguistico) e sono state create da D2, e crmdig:D14_Software, che rappresenta sia i programmi software o i codici informatici che un'istanza di D7 può utilizzare sia un tipo di oggetto digitale che può essere creato dall'attività del progetto di ricerca.

frbroo:F5_Item is defined as comprising “physical objects (printed books, scores, CDs, DVDs, CD-ROMS, etc.) that were produced by (P186i) an industrial process involving a given instance of F3 Manifestation,” while frbroo:F3_Manifestation is defined as comprising “products rendering one or more Expressions. A Manifestation is defined by both the overall content and the form of its presentation.” [10] Within KNOT-DM these two classes are used specifically in conjunction with D2. As such F5 represents the physical item that was used for digitization while F3 represents the manifestation that was used to produce the item. The latter can also be related to a crm:E1_Entity via crm:P129_is_about in order to attach the subject of the manifestation to the process (for example an author or a historical period).

frbroo:F5_Item è definito come comprendente "oggetti fisici (libri stampati, spartiti, CD, DVD, CD-ROM, ecc.) che sono stati prodotti da (P186i) un processo industriale che coinvolge una determinata istanza di F3 Manifestation", mentre frbroo:F3_Manifestation è definita come comprendente "prodotti che rendono una o più Expression. Una Manifestation è definita sia dal contenuto complessivo che dalla forma della sua presentazione" [10]. All'interno di KNOT-DM queste due classi sono utilizzate specificamente in combinazione con la classe D2. Perciò F5 rappresenta l'oggetto fisico che è stato utilizzato per la digitalizzazione, mentre F3 rappresenta la manifestazione dell'oggetto. Quest'ultima può anche essere correlata a crm:E1_Entity via crm:P129_is_about per associare il soggetto alla manifestazione (ad esempio un autore o un periodo storico).

FIG 9. Riassunto delle classi e proprietà CIDOC CRM usato da KNOT-DM per descrivere le informazione del patrimonio culturale.

Un esempio pratico concluso

La Figura 10 descrive l'ultima iterazione dell'esempio pratico, mostrando come vengono utilizzate le principali classi di CIDOC. Il nostro progetto di ricerca è stato informato da due attività specifiche: la digitalizzazione di vecchie fotografie e la creazione del dataset (rappresentato da prov:wasInformedBy, crmdig:D2_Digitization_Process, e crmdig:D7_Digital_Machine_Event). Le vecchie fotografie ritraggono edifici specifici di interesse relativi al tema del progetto sull'architettura medievale italiana (rappresentati da crm:E18_Physical_Thing, crm:P129_is_about, e crm:E1_Entity). La creazione del dataset ha coinvolto l'utilizzo delle scansioni, insieme alla collezione esistente descritta nella fase precedente (rappresentata da crmdig:D9_Data_Object, crmdig:D1_Digital_Object, crmdig:L10_had_input, crmdig:L11_had_output, and crm:P106_is_composed_of). Questo esempio è semplificato in modo che il processo di digitalizzazione riguardi più fotografie, anche se in realtà una singola istanza di D2 dovrebbe rappresentare la digitalizzazione di ogni foto. Allo stesso modo, le attività che hanno informato il progetto di ricerca potrebbero essere estesi alla creazione del servizio dati e del sito web (si veda la sezione Moduli per un esempio più dettagliato). Se le informazioni sono disponibili, le entità rappresentate in queste foto possono essere descritte a loro volta utilizzando CIDOC.

FIG 10. Un esempio pratico che riassume come le classi principali di CIDOC vengono utilizzate per descrivere la dimensione del patrimonio culturale del progetto di ricerca.

Si vede la sezione Moduli per ulteriori esempi pratici dettagliati di come questo segmento può essere utilizzato per descrivere progetti di ricerca accademica e la sezione Ontologia per le definizioni di tutte le diverse proprietà e classi.

Come spiegato nelle sezioni precedenti di questa panoramica, i tre standard utilizzati all'interno di KNOT-DM includono ciascuno classi che si riferiscono a concetti simili, come entita o attività, ma che sono rispettivamente definiti con differenze tali da non essere considerati uguali.

Anche se questo problema potrebbe essere risolto utilizzando owl:equivalentClass o rdfs:subClassOf (che punta a una nuova classe creata appositamente), l'obiettivo di KNOT-DM è quello di riutilizzare il più possibile gli standard esistenti piuttosto che creare nuove classi o proprietà. Per questo motivo, durante lo sviluppo, si è deciso di assegnare agli individui descritti con KNOT-DM ogni classe a seconda dei casi.

Le classi concettualmente simili comprendono:

  • Persone e/o organizzazioni coinvolte in progetti di ricerca.
    • prov:Agent con l'implicazione che l’agent ha una qualche forma di responsabilità nei confronti di una prov:Activity o prov:Entity.
    • foaf:Agent con l'implicazione che l’agent è responsabile di un'azione che è ulteriormente definita da dct:creator o dct:publisher.
    • crm:E39_Actor con un'implicazione di responsabilità simile a quella di prov:Agent, ma in relazione ad attività specifiche e non nell'ambito dell'attività complessiva del progetto di ricerca (prov:Activity).
    • Example: A researcher within our example project is responsible for the technological infrastructure that makes the final dataset available but is not involved or responsible for anything to do with the specific activities that created the dataset, such as the digitization of texts. This researcher should be given the prov:Agent and foaf:Agent classes. Conversely a researcher involved in creating the dataset but not in the development of the website or data service should be given the crm:E39_Actor and prov:Agent classes.
    • Esempio: un ricercatore all'interno del nostro progetto di esempio è responsabile dell'infrastruttura tecnologica che rende disponibile il dataset finale, ma non è coinvolto o responsabile delle attività specifiche che hanno creato il dataset, come la digitalizzazione delle imagine. A questo ricercatore dovrebbero essere assegnate le classi prov:Agent e foaf:Agent. Al contrario, un ricercatore coinvolto nella creazione del dataset ma non nello sviluppo del sito web o del data service dovrebbe ricevere le classi crm:E39_Actor e prov:Agent.
  • Luoghi in cui si è svolta l'attività di ricerca o che sono rappresentati nei risultati della ricerca.
    • prov:Location con l'implicazione che può essere un luogo geografico o non geografico in cui si è svolta un'attività.
    • dct:Location con l'implicazione che si tratta di una regione spaziale o di un luogo nominato o coperto dai dati.
    • crm:E53_Place con un'implicazione simile a quella di dct:Location in relazione alle attività.
    • Esempio: il dataset creato dal nostro progetto di esempio copra l’Italia, mentre il progetto stesso si è svolto a Roma. Pertanto, dct:Location dovrebbe essere usato per indicare l'Italia e allegarlo al dataset, mentre prov:Location e crm:E53_Place dovrebbero essere usati per indicare Roma e allegarlo alle attività che hanno portato alla creazione del dataset.
  • Entità che rappresentano oggetti e soggetti utilizzati e generati da progetti di ricerca.
    • prov:Entity con l'implicazione che può rappresentare cose con aspetti fissi, reali o immaginari create o usate nell’attività di un progetto di ricerca.
    • dcat:Dataset con l'implicazione che può rappresentare solo una raccolta di dati creati e pubblicati come risultato di un'attività di progetto di ricerca.
    • dcat:DataService con l'implicazione che può rappresentare solo un data service creato dall'attività di ricerca per accedere ai dataset che sono stati anche creati dall'attività.
    • crmdig:D1_Digital_Object (e subclassi), crm:E18_Physical_Thing (inclusa la sottoclasse F5) e crm:E1_Entity con l'implicazione che D1 e le sue sottoclassi sono utilizzate solo per rappresentare oggetti digitali creati e/o utilizzati da attività specifici all'interno dell'attività di ricerca (e che possono in definitiva far parte di o essere anche un dcat:Dataset) mentre E18/F5 è usato per rappresentare oggetti fisici che subiscono un processo di digitalizzazione ed E1 è usato per rappresentare l'entità o il concetto che è il soggetto del oggetto fisico o del processo di digitalizzazione.
    • Esempio: il dataset creato dal nostro progetto di esempio è un'istanza di prov:Entity, dcat:Dataset e crmdig:D1_Digital_Object, mentre le rappresentazioni fisiche delle foto utilizzate nel processo di digitalizzazione sono istanze di crm:E18_Physical_Thing e/o frbroo:F5_Item e i risultati del processo sono istanze di crmdig:D9_Data_Object. Il soggeto della ricerca (architettura medievale italiana) può essere rappresentato sia come prov:Entity che come crm:E1_Entity.
  • Attività che rappresentano il progetto di ricerca e sotto-attività che avvengono al suo interno.
    • prov:Activity è utilizzata per rappresentare l'attività complessiva del progetto di ricerca.
    • crmdig:D7_Digital_Machine_Event (e le sue sottoclassi) è usata per rappresentare specifiche sotto-attività all'interno della più ampia attività.
    • Queste classi sono collegate tramite prov:wasInformedBy.
    • Esempio: il nostro progetto di esempio è un'istanza di prov:Activity, mentre la digitalizzazione delle foto e la creazione del dataset basato su questa digitalizzazione sono istanze di crmdig:D2_Digitization_Process and crmdig:D10_Software_Execution (o crmdig:D7_Digital_Machine_Event se non ci sono abbastanza dettagli specifici).

References

[1] Albertoni, Riccardo. n.d. “Data Catalog Vocabulary (DCAT) - Version 2.” Www.w3.org. Accessed June 19, 2023. https://www.w3.org/TR/vocab-dcat-2/.
[2] “PROV-O: The PROV Ontology.” n.d. Www.w3.org. Accessed July 11, 2023. https://www.w3.org/TR/prov-o/.
[3] “Home.” n.d. Cidoc-crm.org. Accessed July 11, 2023. https://www.cidoc-crm.org/.
[4] “———.” n.d. Cidoc-crm.org. Accessed July 11, 2023b. https://www.cidoc-crm.org/crm-dig/.
[5] “———.” n.d. Cidoc-crm.org. Accessed July 11, 2023c. https://www.cidoc-crm.org/frbroo/.
[6] “Functional Requirements for Bibliographic Records (FRBR).” 2009. In Encyclopedia of Library and Information Sciences, Third Edition, 1884–91. CRC Press.
[7] Peroni, Silvio. “Graffoo - Graphical Framework for OWL Ontologies.” n.d. Essepuntato.It. Accessed July 13, 2023. https://essepuntato.it/graffoo/.
[8] Van Nuffelen, Bert. “DCAT Application Profile for data portals in Europe Version 2.1.0.” Joinup.ec.europa.eu. Accessed July 11, 2023. https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/dcat-application-profile-data-portals-europe.
[9] Van Nuffelen, Bert. “Usage guide on Datasets, Distributions and Data Services.” Github.com. Accessed July 11, 2023. https://github.com/SEMICeu/DCAT-AP/blob/master/releases/2.1.1/usageguide-dataset-distribution-dataservice.md.
[10] Bekiari, Chryssoula, Martin Doerr, Patrick Le Boeuf, Trond Aalberg, George Bruseker, Günther Görz, and Mika Nyman. n.d. “LRM OO (Formerly FRBR OO ) Object-Oriented Definition and Mapping from IFLA LRM.” Cidoc-crm.org. Accessed July 11, 2023. https://www.cidoc-crm.org/frbroo/sites/default/files/LRMoo_V0.9%28draft%20for%20WLIC%202022%29.pdf.

Moduli

Scopri di più su come utilizzare i diversi moduli di KNOT-DM.

L'Ontologia

Scopri di più sull'ontologia KNOT che esprime il Data Model in RDF.

Vocabolari Controllati

Scopri di più sui vocabolari controllati utilizzati in KNOT-DM, compresi quelli creati appositamente per il progetto.