Sparna Blog http://blog.sparna.fr Web de données | Architecture de l'information | Accès aux connaissances Wed, 30 Jun 2021 08:34:52 +0000 fr-FR hourly 1 Fair Data Collective is doing cool things with SKOS Play and xls2rdf http://blog.sparna.fr/2021/06/30/fair-data-collective-is-doing-cool-things-with-skos-play-and-xls2rdf/ http://blog.sparna.fr/2021/06/30/fair-data-collective-is-doing-cool-things-with-skos-play-and-xls2rdf/#comments Wed, 30 Jun 2021 08:34:52 +0000 http://blog.sparna.fr/?p=1440 The FAIR Data Collective is doing cool things to enable researchers to easily publish their vocabularies as SKOS linked data while easily editing the vocabulary content in Excel spreadsheets, converted using the xls2rdf library in SKOS Play from Sparna. They turned the converter in a Github actions pipeline, so that you push your Excel spreadsheet…

Cet article Fair Data Collective is doing cool things with SKOS Play and xls2rdf est apparu en premier sur Sparna Blog.

]]>
The FAIR Data Collective is doing cool things to enable researchers to easily publish their vocabularies as SKOS linked data while easily editing the vocabulary content in Excel spreadsheets, converted using the xls2rdf library in SKOS Play from Sparna. They turned the converter in a Github actions pipeline, so that you push your Excel spreadsheet based on a provided Excel template to your Github repo, and abracadabra ! you get a SKOS RDF file that can be loaded in a Fuseki instance and visible in Skosmos, and even submitted to BioPortal or OntoPortal.

Here is also nice video showing how to visualize such a SKOS vocabulary in SKOS Play visualization tools.

Thanks to Nikola Vasiljevic and John Graybeal from FAIR Data Collective for this nice integration !

You can check out the Fair Data Collective page on LinkedIn : « Making practical and easy-to-use FAIR data solutions ».

Cet article Fair Data Collective is doing cool things with SKOS Play and xls2rdf est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2021/06/30/fair-data-collective-is-doing-cool-things-with-skos-play-and-xls2rdf/feed/ 0
Alimenter Talend avec SPARQL (sur Wikidata) http://blog.sparna.fr/2021/03/24/alimenter-talend-avec-sparql-sur-wikidata/ http://blog.sparna.fr/2021/03/24/alimenter-talend-avec-sparql-sur-wikidata/#comments Wed, 24 Mar 2021 09:40:55 +0000 http://blog.sparna.fr/?p=1409 Dans le billet précédent nous avons vu comment Talend pouvait être utilisé pour convertir des données existantes vers du RDF/XML pour alimenter un graphe de connaissances. Ici nous allons voir… exactement l’inverse ! Comment alimenter Talend avec une requête SPARQL ? En d’autres termes comment votre graphe de connaissances RDF pourra servir d’entrée à un…

Cet article Alimenter Talend avec SPARQL (sur Wikidata) est apparu en premier sur Sparna Blog.

]]>
Dans le billet précédent nous avons vu comment Talend pouvait être utilisé pour convertir des données existantes vers du RDF/XML pour alimenter un graphe de connaissances. Ici nous allons voir… exactement l’inverse ! Comment alimenter Talend avec une requête SPARQL ? En d’autres termes comment votre graphe de connaissances RDF pourra servir d’entrée à un traitement de conversion de données pour exporter des données tabulaires, alimenter d’autres bases, ou se combiner avec d’autres flux.

Le principe est simple : arriver à exécuter une requête SPARQL puis traiter les résultats correspondants pour en faire un tableau de données. Ce tableau de données pourra ensuite être exporté, combiné, enregistré, comme vous le souhaitez.

Pour illustrer cela nous allons interroger Wikidata au travers de son service d’interrogation SPARQL en utilisant sa première requête d’exemple qui récupère… les chats !

La requête est la suivante, et voici le lien direct pour l’exécuter dans Wikidata :

SELECT ?item ?itemLabel
WHERE {
  ?item wdt:P31 wd:Q146.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
LIMIT 10

Vous pouvez télécharger le job présenté ici dans ce repository Github d’exemple, et l’importer directement dans Talend.

Nous allons utiliser les composants Talend suivant :

1_Flow

Création d’un Job

Pour commencer, vous devez créer un nouveau job.

  • Faite un clic droit sur Jobs dans le panneau de gauche. choisissez l’option Créer un Job.

2_CréerJob

  •  Remplissez les champs nécessaires de la fenêtre Nouveau Job et cliquez sur le bouton finish.

3_ParametrerJob

 Appel SPARQL avec tRESTClient

  • Ajoutez au job le composant tRESTClient.
  • Cliquez deux fois sur le composant tRESTClient, allez à la propriété Paramètres simple et remplissez les paramètres suivants:
    1. URL: L’URL du service SPARQL de Wikidata est https://query.wikidata.org/sparql .
    2. Méthode HTTP: Choisissez la méthode HTTP GET
    3. Paramètre de la Requête: Nous devons ajouter le paramètre “query”, cliquez sur le bouton plus [+], et dans la colonne Nom entrez “query”. Dans la colonne Valeur vous allez saisir la requête SPARQL.

Attention!  La requête SPARQL est une chaîne de caractères Java, vous devez donc : 1/ L’entourer avec des guillemets doubles 2/ ajouter le caractère d’échappement \ avant les guillemets dans la requête et 3/ écrire la requête sur une seule ligne. Voici la chaîne de caractères correspondante :

“SELECT ?item ?itemLabel WHERE { ?item wdt:P31 wd:Q146. SERVICE wikibase:label { bd:serviceParam wikibase:language \"[AUTO_LANGUAGE],en\". } } LIMIT 10”

 

4_ParametrerComponentSource

Transformation des résultats SPARQL avec tExtractXMLField

  • Ajoutez dans le projet un composant tExtractXMLField.
  • Connectez le composant tRESTClient au tExtractXMLField.

Nous allons paramétrer le tExtractXMLField :

5_tExtractXMLField_Colonne

  1. Cliquez sur le bouton Modifier le schéma pour ouvrir la fenêtre des colonnes d’entrée et sortie du composant tExtractXMLField.
  2. Ajoutez deux nouvelles colonnes Uri et Label de type String avec le bouton plus [+] et cliquez sur le bouton Ok. 6_tExtractXMLField_Colonne_sortie
  3. Allez à Paramètres simple et modifiez les options suivantes:
  • Champ XML: Choisissez le champs “body”, qui est le champ qui contient la réponse à l’appel SPARQL du composant précédent;
  • Requête XPath boucle: Saisissez « /sparql/results/result » qui est d’après la spec du format de résultat SPARQL le chemin vers chaque ligne de résultats dans la réponse.
  • La table Mapping : c’est ici que tout se joue !!! ce mapping va vous permettre d’associer les colonnes de votre résultat SPARQL au champs de sortie du composant, par le biais de chemins XPath:
    1. Pour la colonne Uri la valeur de la colonne Requête Xpath sera « binding[@name=’item’]/uri »
    2. pour la colonne Label la valeur de la colonne Requête Xpath sera « binding[@name=’itemLabel’]/literal ».
    3. Si la requête SPARQL retournait plus de colonnes, il faudrait ajouter ici les mappings correspondants pour alimenter les autres colonnes du résultat.

7_tExtractXMLField_Component

 Génération du fichier de sortie

  • Ajoutez le composant de sortie tFileOutputDelimited.
  • Connectez le composant tExtractXMLField au composant tFileOutputDelimited.
  • Paramétrez le composant dans la section de Paramètres simpleNom de fichier: le chemin dans lequel vous souhaitez sauvegarder le fichier de sortie.

8_tFileOutputDelimited

 Lancer le Job

  • Allez à la section Exécuter.
  • Cliquez sur le bouton Exécuter.

9_LancerJob

 Profitez !

Naviguez vers l’emplacement du fichier pour le récupérer.

10_RouteFile

Et voilà le résultat :

 

Uri;Label
 http://www.wikidata.org/entity/Q378619;CC
 http://www.wikidata.org/entity/Q498787;Muezza
 http://www.wikidata.org/entity/Q677525;Orangey
 http://www.wikidata.org/entity/Q851190;Mrs. Chippy
 http://www.wikidata.org/entity/Q1050083;Catmando
 http://www.wikidata.org/entity/Q1201902;Tama
 http://www.wikidata.org/entity/Q1207136;Dewey Readmore Books
 http://www.wikidata.org/entity/Q1371145;Socks
 http://www.wikidata.org/entity/Q1386318;F. D. C. Willard
 http://www.wikidata.org/entity/Q1413628;Nora

Vous savez donc maintenant comment alimenter Talend à partir d’une base accessible en SPARQL, en quelques clics et sans code ! Cela permet de valoriser votre graphe de connaissances pour l’intégrer dans le reste du système d’information.

Cet article Alimenter Talend avec SPARQL (sur Wikidata) est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2021/03/24/alimenter-talend-avec-sparql-sur-wikidata/feed/ 0
Générer du RDF avec Talend (un tutorial) http://blog.sparna.fr/2021/03/17/rdf-talend-tutorial/ http://blog.sparna.fr/2021/03/17/rdf-talend-tutorial/#comments Wed, 17 Mar 2021 17:42:32 +0000 http://blog.sparna.fr/?p=1352 Talend Open Studio est un outil d’ETL, open-source et avec une version gratuite, utilisé pour récupérer des données d’une ou plusieurs bases, ou flux, les transformer, et alimenter d’autres bases, ou générer des rapports. On le rencontre parfois en lien avec des projets de graphes de connaissances RDF, sans toutefois l’avoir jamais réellement mis en…

Cet article Générer du RDF avec Talend (un tutorial) est apparu en premier sur Sparna Blog.

]]>
Talend Open Studio est un outil d’ETL, open-source et avec une version gratuite, utilisé pour récupérer des données d’une ou plusieurs bases, ou flux, les transformer, et alimenter d’autres bases, ou générer des rapports.

On le rencontre parfois en lien avec des projets de graphes de connaissances RDF, sans toutefois l’avoir jamais réellement mis en œuvre. Nous vous proposons ici d’explorer comment Talend peut être utilisé pour convertir des données CSV en RDF (RDF/XML plus précisément), tout cela uniquement avec des composants graphiques et sans écrire de code. C’est là un des gros avantages de l’approche : l’agencement de composants graphiques, de façon (relativement) simple, permet le paramétrage de jobs de conversion par des profils qui ne sont pas des développeurs.

Le code source du Job Talend pour produire du RDF que nous vous proposons de suivre ici peut être téléchargé depuis ce repository Github pour être importé dans Talend.

Les projets de mise en place de graphes de connaissances nécessitent en effet invariablement de la conversion de données vers du RDF pour alimenter le graphe. Ces conversions peuvent être faites :

  • de façon massive et une seule fois (reprise intégrale d’une source de données pour basculer dans le graphe)
  • de façon massive et répétées plusieurs fois (synchronisation périodique d’une source de données avec le graphe, pour maintenir les deux en synchro, mais sans temps réel)
  • de façon unitaire au fil de l’eau (synchronisation des enregistrements un par un, à chaque modification dans les données source, pour maintenir les données source et le graphe synchronisés en temps réel ou quasi temps-réel)

Il y a de nombreuses techniques de conversion des données source pour alimenter le graphe, on citera :

  • les feuilles de style XSLT pour traiter du XML (pour moi la “voie royale”), à l’expressivité quasi sans limite et aux performances excellentes (technique utilisée dans le développement du convertisseur Records in Context par exemple);
  • L’ajout d’entêtes de @context JSON-LD sur des flux JSON, pour que le flux JSON soit interprétable directement comme du RDF;
  • L’écriture de scripts custom, bien sûr, Python, Java, etc.
  • L’utilisation d’outils de mapping de base relationnelles basés sur R2RML comme OnTop;
  • L’utilisation de la nouvelle interface de mapping RDF de GraphDB, comme une extension d’OpenRefine (il faudra qu’on en reparle);
  • L’utilisation du convertisseur Excel vers RDF de SKOS Play, lorsque les données source sont saisies à la main dans des tableurs (on fait plein de choses avec ça, y compris créer des règles SHACL);

Et donc, en plus de tout cela, nous pouvons maintenant ajouter Talend à la panoplie des techniques possibles de production de graphes RDF !

Installez Talend et paramétrez un Job avec 3 composants

Pour suivre l’exemple de job de conversion proposé ici, téléchargez et installez Talend Open Studio For Data Integration.

Le job d’exemple que nous allons paramétrer utilise les composants suivants :

  • Un composant tFixedFlowInput pour lire (ici, générer) les données d’entrée.
  • Un composant tMap pour transformer les données et en particulier générer tout ce qui est nécessaire pour produire le RDF, en particulier les URIs des sujets et des objets.
  • Un composant tAdvancedFileOutputXML pour créer le fichier RDF/XML de sortie.

1

Créez un nouveau Job Talend, et à partir de la palette de composants sur la droite de l’écran, ajoutez les 3 composants dans votre job.

Configurer les données d’entrée

Nous allons configurer des données d’entrée d’exemple, type CSV, avec 3 colonnes qui décrivent des personnes : ID, Prénom et Nom.

  1. Dans l’espace de travail, sélectionnez le tFixedFlowInput_1 .
  2. Cliquez sur la vue Component pour paramétrer ses propriétés de base dans l’onglet Basic settings.
  3. Cliquez sur le bouton […] à côté du champ Edit Schema pour décrire la structure des données que vous souhaitez à partir des variables internes. Dans ce scénario, le schéma est constitué de trois colonnes : IDfirst et last, toutes de type String.
  4. Cliquez sur OK pour fermer la boîte de dialogue.
  5.  Dans les propriétés Basic settings du composant tFixedFlowInput 1 sélectionnez “Use Inline Content (delimited file)”. Dans le champ contenu, ajoutez les informations:  

    1;John;Doe
    2;Rutherford;McKinley
    3;Marc;Van Buren
    4;Theodore;Roosevelt
    5;John;Truman
    schema_source_donnees
  6. Connectez le composant tFixedFlowInput_1  au tMAP_1 avec le bouton gauche de la souris. Choisir l’option Row > Main et connectez au composant tMAP.

 

Connection1

Mapper les données pour générer des URIs (et le reste)

La seconde étape consiste à produire tout ce dont on a besoin pour générer le RDF, en particulier générer les URI des ressources. Nous allons donc générer une URI pour chaque personne à partir de son ID.

  1. Configurez le composant tMAP_1.
  • Éditez le composant avec l’option éditeur de mapping. Cette option ouvrira une fenêtre séparée.   


tMap_Editeur

tMap_Schema

  • Ajoutez une table de sortie avec le bouton plus [+] et donner un nom : out1.
  • Ajoutez les colonnes dans la section correspondante comme affiché dans l’image ci-dessous : en sortie nous allons produire une colonne “URI” à la place de “ID”, et les colonnes “First” et “Last” restent les même.

tMap_OutputColonne

  • Glissez chaque colonne d’entrée à la table de sortie :
    • First va sur First
    • Last va sur Last
    • et ID va vers URI

 

  • Nous allons transformer la colonne ID pour générer l’URI, en utilisant une expression de concaténation « http://sparna.fr/dataset/persons/person_ »+row1.ID.toString(). Pour cela, dans le champs “Expression” de la colonne “URI, copiez/collez l’expression de concaténation « http://sparna.fr/dataset/persons/person_ »+row1.ID.toString(). Vous pouvez également cliquer sur le bouton “constructeur d’expression” pour ouvrir une fenêtre dédiée où vous pourrez saisir l’expression.  

tMap_StructureOutput

tMap_Expression

 

  • Cliquez sur OKpour valider et revenir à l’espace de modélisation.
  • Reliez le composant tMap_1 au composant tAdvancedFileOutputXML_1

 

Configurer la sortie RDF/XML

 

Une fois que toutes les informations nécessaires à la génération du RDF (en particulier les URIs) ont été produites, on peut mapper les différentes informations vers la structure d’un fichier RDF/XML de sortie.

  1. Nous allons définir l’arbre XML dans le composant tAdvancedFileOutputXML_1.
  2. Double-cliquez sur le composant tAdvancedFileOutputXML_1 pour ouvrir l’interface dédiée ou cliquez sur le bouton […] du champ Configure Xml Tree de l’onglet Basic settings dans la vue Component.
  3. Dans la section Linked Target (cible du lien),  définissez la structure XML comme sortie.
    • Cliquez sur la ligne  rootTag et renommer par rdf:RDF.RDFXML_Racine
    • Cliquez sur le bouton plus [+] et ajoutez une ligne de type namespace avec son prefix rdf et son namespace “http://www.w3.org/1999/02/22-rdf-syntax-ns#”.
      • Etape 1:RDFXML_NameSpace
      • Étape 2: Choisissez l’option create as name space.RDFXML_NameSpace_Option
      •  Étape 3: Tapez le prefix et le Namespace.

RDFXML_NameSpace_Prefix_Namespace

  • Ajoutez autre namespace comment les pas précédents. et avec le prefix foaf et le namespace “http://xmlns.com/foaf/0.1/”.
  • Choisissez la ligne racine (rdf:RDF) et  Créer une sous élément qui doit s’appelle foaf:Person et cliquez sur le bouton OK.  

RDFXML_SousElement

RDFXML_SousElement_libelle

  • Cliquez sur la ligne foaf:Person et créer un attribut rdf:about et cliquez sur le bouton OK.

RDFXML_attribut
RDFXML_attribut_libelle

 

  • Cliquez sur la ligne foaf:Person et ajoutez les sous éléments foaf:firstName et foaf:lastName.
  • Pour connecter les sources avec la structure, glissez chaque champ source  avec le champ cible.  URI → @rdf:about et immédiatement s’afficher une  fenêtre où nous devons choisir l’option Add linker to target node.

RDFXML_Linker
RDFXML_Structure_final

 

  1. Cliquez sur le bouton OK pour confirmer.

 

  1. Dans le Basic Settings du composant tAdvancedFileOutputXML_1, entrez le chemin de sauvegarde du fichier XML de sortie.

RDFXML_Composant

Lancer notre Job.

  1. Aller à la section Exécuter.
  2. Cliquez sur le bouton Exécuter.

Job_Executer

  1. Le résultat final est la création du fichier RDF/XML, qui est stocké à l’endroit configuré.

Job_FileOutput

 

 

Et voilà un magnifique fichier RDF/XML, produit à partir de CSV, en quelques clics et avec des composants graphiques ! Pas belle la vie ?

<rdf:RDF 
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:foaf="http://xmlns.com/foaf/0.1/">
   
    <foaf:Person rdf:about="http://sparna.fr/dataset/persons/person_1">
        <foaf:firstName>Theodore</foaf:firstName>
        <foaf:lastName>Roosevelt</foaf:lastName>
    </foaf:Person>
    <foaf:Person rdf:about="http://sparna.fr/dataset/persons/person_2">
        <foaf:firstName>Ulysses</foaf:firstName>
        <foaf:lastName>Clinton</foaf:lastName>
    </foaf:Person>
    <foaf:Person rdf:about="http://sparna.fr/dataset/persons/person_3">
        <foaf:firstName>John</foaf:firstName>
        <foaf:lastName>Truman</foaf:lastName>
    </foaf:Person>
    <foaf:Person rdf:about="http://sparna.fr/dataset/persons/person_4">
        <foaf:firstName>Chester</foaf:firstName>
        <foaf:lastName>Van Buren</foaf:lastName>
    </foaf:Person>
    <foaf:Person rdf:about="http://sparna.fr/dataset/persons/person_5">
        <foaf:firstName>Rutherford</foaf:firstName>
        <foaf:lastName>McKinley</foaf:lastName>
    </foaf:Person>
</rdf:RDF>

 

Crédit illustration : Talend et RDF

Cet article Générer du RDF avec Talend (un tutorial) est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2021/03/17/rdf-talend-tutorial/feed/ 0
semweb.pro 2020 : vidéos en ligne et 2 après-midi de rencontres (virtuelles) les jeudi 19/11 et 26/11 http://blog.sparna.fr/2020/11/14/semweb-pro-2020-videos-jeudi-1911-et-2611/ http://blog.sparna.fr/2020/11/14/semweb-pro-2020-videos-jeudi-1911-et-2611/#comments Sat, 14 Nov 2020 18:10:39 +0000 http://blog.sparna.fr/?p=1337 Semweb.pro 2020 c’est bientôt et ca se passera évidemment en ligne, becoz confinement. En ligne et à travers des vidéos d’intervention pré-enregistrées, accessibles librement à partir de maintenant et jusqu’aux 2 après-midi de rencontres virtuelles. Pour regarder les vidéos, c’est par ici ! J’y interviens 2 fois cette année. D’abord avec le Réseau Canopé pour…

Cet article semweb.pro 2020 : vidéos en ligne et 2 après-midi de rencontres (virtuelles) les jeudi 19/11 et 26/11 est apparu en premier sur Sparna Blog.

]]>
Semweb.pro 2020 c’est bientôt et ca se passera évidemment en ligne, becoz confinement. En ligne et à travers des vidéos d’intervention pré-enregistrées, accessibles librement à partir de maintenant et jusqu’aux 2 après-midi de rencontres virtuelles. Pour regarder les vidéos, c’est par ici !

J’y interviens 2 fois cette année. D’abord avec le Réseau Canopé pour présenter la mise en ligne et les spécificités des vocabulaires du ScolomFr pour l’indexation des ressources pédagogiques. J’avais décrit le navigateur et la timeline permettant de remonter dans les versions du vocabulaire dans un précédent billet. Le ScolomFr s’est enrichi dans sa dernière version de particularités excitantes que nous présentons :

Ensuite avec les Archives Nationales pour présenter le travail effectué depuis un an sur Rico-converter, un outil de conversion d’instruments de recherche en EAD et de notices d’autorités en EAC vers un graphe sémantique structuré suivant l’ontologie Records In Context (RiC-O). RiC est le nouveau modèle conceptuel mis au point par et pour la communauté des archivistes, que j’avais décrit dans un précédent billet. Le convertisseur a permis de convertir 15000 notices EAC et 28000 fichiers EAC des Archives Nationales en RDF (environ 155 millions de triplets). Une préfiguration d’un futur data.archives-nationales.culture.gouv.fr ?

Les 2 après-midi de rencontre auront lieu les jeudi 19/11 et 26/11, dans ce monde virtuel gather.town :

gathertown

 

Merci à Logilab de continuer d’organiser cet évènement.

Au plaisir de vous voir nombreux à semweb.pro 2020 !

 

Crédit illustration : sur le blog de Logilab, pour semweb.pro 2019

 

Cet article semweb.pro 2020 : vidéos en ligne et 2 après-midi de rencontres (virtuelles) les jeudi 19/11 et 26/11 est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2020/11/14/semweb-pro-2020-videos-jeudi-1911-et-2611/feed/ 0
Dessiner des ontologies, visualiser des graphes : quels outils ? http://blog.sparna.fr/2020/07/29/dessiner-ontologies-visualiser-graphes-outils/ http://blog.sparna.fr/2020/07/29/dessiner-ontologies-visualiser-graphes-outils/#comments Wed, 29 Jul 2020 13:25:09 +0000 http://blog.sparna.fr/?p=1317 Un récent fil de discussion sur la mailing-list public-lod demandait quels étaient les bons « Graphic softwares for creating drawings and diagrams in cross-sectoral scientific papers » (sic), ce qui m’a donné envie de compiler les différents outils cités en réponse, mais aussi d’autres qui n’ont pas été cités et que j’utilise ponctuellement. Dans le métier d’ingénieur…

Cet article Dessiner des ontologies, visualiser des graphes : quels outils ? est apparu en premier sur Sparna Blog.

]]>
Un récent fil de discussion sur la mailing-list public-lod demandait quels étaient les bons « Graphic softwares for creating drawings and diagrams in cross-sectoral scientific papers » (sic), ce qui m’a donné envie de compiler les différents outils cités en réponse, mais aussi d’autres qui n’ont pas été cités et que j’utilise ponctuellement. Dans le métier d’ingénieur de la connaissance et du travail sur la data, il est indispensable de savoir non seulement concevoir mais aussi expliquer et transmettre la structure d’un modèle de données ou d’un graphe, et rien de mieux qu’une représentation visuelle pour cela.

Il y a deux grandes catégories d’outils : les outils d’authoring, en phase de conception d’ontologie et pour pouvoir communiquer sur un modèle de données, et des outils de visualisation qui permettent de voir des graphes RDF ou des modèles déjà constitués.

Dessiner/concevoir des ontologies

Powerpoint / Google slides

Je suis un utilisateur de Linux et Ubuntu est mon environnement de travail quotidien. Et pourtant… j’ai quand même une machine virtuelle Windows juste pour utiliser la suite Office et en particulier Powerpoint; je n’ai jamais réussi à être efficace et à créer des diagrammes jolis avec LibreOffice, et il faut dire que le côté quasi universel des documents Office permet de les échanger facilement avec les clients, de les montrer en présentation, et de les intégrer rapidement dans d’autres documents (Word). C’est avec Powerpoint que j’ai par exemple dessiné les diagrammes du profil d’application de l’ISSN, de l’ontologie ELI-DL (ELI for Draft Legislation), ou de l’ontologie ScolomFR. J’aime bien en particulier le formalisme de présentation de ELI-DL : 1 planche d’explication, 1 diagramme, 1 planche d’explication, 1 diagramme, etc. cela permet de « scenariser » la présentation du modèle de façon pédagogique. Le gros défaut en terme de saisie, et c’est tout bête, c’est qu’on ne peut pas associer un libellé à un connecteur… on bouge le connecteur, il faut bouger le libellé avec…

Dans la même veine, Google Slides ajoute la dimension collaborative en temps réel.

Bien sûr, les diagrammes produits ne sont que des images, et n’ont pas de vrais structures de graphe, avec possibilité de faire une mise en page automatique ou un export en SVG par exemple.

Yed et Yed-live

Bernard Chabot, grand Ontologiste et Architecte de la Connaissance (on se croirait dans une loge maçonnique), m’avait plusieurs fois fait la promotion de Yed, un outil de dessin de graphe. C’est un open-source, java, qui existe depuis looooongtemps dans le paysage. Yed qui est une application de bureau a son pendant en ligne, yed-live. C’est avec ces outils que Bernard dessine par exemple les diagrammes de son article »dicho-scope » sur les grands axes de construction d’un modèle sémantique (auquel on ajouterait peut-être la distinction intention vs. extension, mais c’est un autre sujet), ou encore les diagrammes du modèle E2M pour la modélisation de réseaux d’acteurs (oui, un FOAF béton avec une approche ingéniérie de la connaissance).

J’avais utilisé Yed-live et ce que j’avais trouvé vraiment bien ce sont les fonctions de regroupement des noeuds, de layout automatique (et temps réel !), et (mais je n’était pas allé jusque là), la possibilité d’avoir sa propre palette d’objets. Après, attention, l’éditeur est en ligne mais ce n’est pas collaboratif. Ca permet toutefois d’enregistrer son graphe dans un cloud ou par exemple dans un Gist github, et de pouvoir ensuite l’échanger via un partage d’URL.

YeD-E2M_Chabot

Extrait d’une plache du modèle E2M par Bernard Chabot, modélisée avec YeD

diagrams.net

Le fil de discussion mentionne diagrams.net, qui a l’air d’être une solution d’édition de graphes online et open-source. Comme Yed-live, s’intègre avec Google Drive ou Github ou Dropbox pour le stockage. Pas besoin de login, et on est dans un look and feel très proche des applications Google. Ca a l’air très sympa et puissant !

Omnigraffle ou LucidCharts (solutions payantes)

On mentionne également Omnigraffle (pour Mac seulement), qui n’a pas l’air tout jeune, et LucidCharts, 2 solutions de dessins de diagrammes et de graphes, mais cette fois-ci commerciales. La présentation corporate de LucidCharts nous apprend qu’on peut (si je comprends bien) venir injecter des données de sources externes (tableur, etc.) dans un modèle de diagramme; intéressant.

Visualiser des ontologies ou des graphes

Plantuml

C’est sur le fil de discussion mentionné plus haut que je découvre PlantUML, un outil qui dessine tout plein de diagrammes UML (mais pas que, aussi des Mind Map ou des Wireframes), à partir d’un bout de texte ! Par exemple, si on écrit

Object <|-- ArrayList

Object : equals()
ArrayList : Object[] elementData
ArrayList : size()

On obtient

Du coup, vous voyez le truc : ce bout de texte, on peut imaginer de le générer… à partir de RDF pour une visualisation de graphe, ou à partir de SHACL pour générer diagramme de classes UML. Et c’est Vladimir Alexiev d’Ontotext qui a cette idée dans son projet « rdfpuml » qui génère des graphes PlantUML à partir de fichiers Turtle (voir ces tweets). Effectivement, si on dessine des graphes à partir de RDF, on doit pouvoir dessiner des diagrammes de classes UML à partir de Shapes… (ce qu’on ne peut pas bien faire à partir d’ontologies OWL, qui, je le rappelle, ne définissent pas des modèles de données fermés mais des domaines de connaissances ouverts). Une idée de fonctionnalité pour SHACL Play !

PlantUML me parait très prometteur pour automatiser cette génération de diagrammes (mais moins pour les éditer à la main).

D3

On ne présente plus D3js, bibliothèque Javascript de dataviz au sens large. Elle est intégrée dans les visualisations de SKOS Play pour visualiser des hiérarchies de thesaurus en SKOS. On est donc là-aussi sur un outil de rendu de graphe ou de données.

Gephi + sigmajs

J’avais présenté la solution Gephi et son export en sigmajs dans un autre billet. Là aussi, on est sur un outil de rendering de graphe, avec la possibilité de manipuler de gros graphes de données et d’éditer le rendu avec des algorithmes très puissant. Mais ce n’est pas un outil d’authoring des données. A l’époque (2015) le plugin d’import RDF me semblait légèrement instable et pas trop mis à jour. Continue-t-il à être maintenu et Gephi est-il toujours une solution viable pour générer des vues de graphes RDF ?

WebVOWL

Dans le registre des solutions de visualisations automatiques, Il ne faut pas oublier WebVOWL qui propose une visualisations de tous les axiomes OWL. Le résultat n’est franchement pas simple à lire, mais a l’avantage d’être quelque chose de très différent des diagrammes de classes UML, et vraiment fait pour la représentation graphique d’ontologies. WebVOLW est intégré à Widoco, un utilitaire de génération de documentation automatiques d’ontologies OWL, que je vous recommende (le successeur de LODE, qui l’intégre d’ailleurs).

Plugins Protégé

Pour être tout à fait complet sur la partie visualisation d’ontologies on ne peut pas passer sous silence les plugins de visualisation intégrés dans Protégé.

 

Bel été, et n’hésitez pas à poster vos plus beaux diagrammes d’ontologies :-) !

 

Illustration de l’article : https://www.slideshare.net/Jean_Rohmer/de-lia-au-calcul-littraire-pourquoi-jai-zapp-le-web-smantique/17 « Réseau Sémantique et Logique du XVIeme siècle dans la cathédrale de Grenade modélisant la Sainte Trinité », Jean Rohmer, dans la présentation « De l’IA au Calcul Littéraire: Pourquoi j’ai zappé le Web Sémantique« avec l’aimable autorisation de Jean Rohmer. « Pater non est Filius », « Pater non est Spiritus Sanctus », « Filius non est Spiritus Sanctus », « Deus est Pater », « Deus est Filius », « Deus est Spiritus Sanctus »

 

Cet article Dessiner des ontologies, visualiser des graphes : quels outils ? est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2020/07/29/dessiner-ontologies-visualiser-graphes-outils/feed/ 14
RiC-CM, RiC-O : les Archives se dotent de leur modèle conceptuel (Records in Contexts) http://blog.sparna.fr/2020/04/20/rico-records-in-contexts-archives-modele-conceptuel/ http://blog.sparna.fr/2020/04/20/rico-records-in-contexts-archives-modele-conceptuel/#comments Mon, 20 Apr 2020 14:33:13 +0000 http://blog.sparna.fr/?p=1274 Records In Contexts, ou RiC pour les intimes, est disponible depuis peu en 2 variantes sur le site du Conseil International des Archives : RiC-CM, le modèle conceptuel, et RiC-O, son implémentation sous forme d’ontologie OWL (dont une bonne introduction est donnée sur la page de l’ontologie elle-même à https://www.ica.org/standards/RiC/ontology). Ce modèle conceptuel a été…

Cet article RiC-CM, RiC-O : les Archives se dotent de leur modèle conceptuel (Records in Contexts) est apparu en premier sur Sparna Blog.

]]>
Records In Contexts, ou RiC pour les intimes, est disponible depuis peu en 2 variantes sur le site du Conseil International des Archives : RiC-CM, le modèle conceptuel, et RiC-O, son implémentation sous forme d’ontologie OWL (dont une bonne introduction est donnée sur la page de l’ontologie elle-même à https://www.ica.org/standards/RiC/ontology). Ce modèle conceptuel a été élaboré au sein du groupe EGAD (Expert Group on Archival Description) du CIA, créé fin 2012. Il succède, et donc vise à unifier et à remplacer, les normes actuelles que sont l’ISAD-G, l’ISAAR(CPF), l’ISDF et l’ISDIAH. Une bonne perspective de contexte historique est donné dans le document « Toward an International Conceptual Model for Archival Description: A Preliminary Report from the International Council on Archives«  publié peu après le début des travaux de l’EGAD.

Les sources de l’ontologie RiC-O sont dans Github à https://github.com/ICA-EGAD/RiC-O.

4 entités au coeur de RiC-CM

RiC-CM défini 4 entités « noyaux » du modèle conceptuel : la Record Resource, ses Instantiations, des Agents et des Activités. La RecordResource est une description intellectuelle qui peut avoir plusieurs matérialités (typiquement document original vs. numérisation), ses Instantiations. Une « Record Resource » peut se préciser soit en Record Set (ensemble de notices), en Record (notice seule) ou en Record Part (partie de notice), la frontière entre ces 3 notions n’étant pas toujours facile.

Sous la notion générique d’Agent, RiC-CM déclare les 3 types d’agents archivistiques classiques Person, Family et Corporate Body, mais introduit également comme des Agents les « Positions » (Fonctions dans un organigramme) et les « Mechanisms » (typiquement les logiciels), qui peuvent donc être utilisés dans une relation de Provenance.

Ces 4 entités « noyaux » sont complétées par la notion de Rule (règle, loi, normes, « contexts that establish the conditions for the performance of the activities ») et les entités classiques de Date et Place.

Le modèle conceptuel RiC-CM défini un ensemble de 78 relations majoritairement entre les 4 entités noyaux du modèle, et c’est là que la notion de Contextes (au pluriel) prends tout son sens :

  1. Relations Partitives tout/partie : Record has consituent Record Part, Event has subevent Event, Group has subdivision Group, etc…
  2. Relations Séquentielles avant/après : Record is original of Record, Instantiation has derived instantiation Instantiation, Agent is antecedent of Agent, etc..
  3. Relations de Sujet : Record Resource has subject Thing ou Record Resource describes Thing, etc.
  4. Relations inter-Record Resource : Record Resource has copy Record Resource, Record Set includes Record, etc.
  5. Relations de Record Resource à Instantiation : Record Resource has instantiation Instantiation, etc.
  6. Relations de Provenance (Record Resource à Agent) : Record Resource created by Agent, etc.
  7. Relations inter-Instantiations, typiquement Instantiation has derived instantiation Instantiation (cas de la copie numérique d’un orginal), etc.
  8. Relations de Management : Group or Person or Position is owner of Thing, Agent controls Agent, etc.
  9. Relations inter-Agent : Person is leader of Group, Person has child Person, Person occupies Position, Person knows Person, etc.
  10. Relations des Events/Activities, typiquement Activity performed by Agent
  11. Relations des Rules : Rule regulates Thing, Mandate authorizes Agent, etc.
  12. Relations de Datation
  13. Relations Spatiales

Ce diagramme (tiré de cette présentation de RiC-CM aux Archives Nationales et du code source de RiC-O dans Github) donne l’aperçu haut-niveau de RiC-CM et des relations qui articulent les entités de haut-niveau du modèle :

RiC-CM-02-overview-diagram

Diagramme haut-niveau du Modèle Conceptuel Records in Contexts 0.2

RiC dans la famille des modèles conceptuels

RiC s’inscrit dans la famille des modèles conceptuels développés depuis 3 décennies dans le domaine de l’infodoc : FRBR en 1992-1995 pour les notices bibliographiques des bibliothèques, puis le CIDOC-CRM à partir de 1996 pour la description des objets muséaux et patrimoniaux en général, puis l’intégration de FRBR dans le CIDOC-CRM, à partir de 2003, qui donnera naissance à FRBRoo en 2008. Et plus récemment, en 2017, IFLA-LRM qui consolide les modèles de la famille FRBR.

On notera la temporalité longue pour l’élaboration de ces standards internationaux : réunions internationales, disponibilité des participants, nécessaires discussions longues sur l’identification des concepts fondamentaux du métier. On notera aussi le retard de la communauté des archives, avec le début du groupe EGAD en 2012 et la version 0.1 de RiC-CM publiée en 2016, sur cette réflexion au niveau conceptuel, par rapport aux bibliothèques et aux musées. Cela peut s’expliquer par la présence d’un standard technique unique et utilisé mondialement, l’EAD, et par des moyens plus réduits dans la communauté archivistique.

La communauté du CIDOC-CRM s’est empressé de dénoncer la « secte des archivistes » qui réinventent leur propre modèle conceptuel plutôt que de s’appuyer sur les fondations théoriques du CIDOC-CRM. Mais cette phase de réflexion où sont réexaminés l’existence, le périmètre, la pertinence et l’articulation de de chaque concept métier est bien nécessaire à une communauté de pratique avant que celle-ci ne puisse proposer un éventuel accostage avec le point de vue – certes générique et théoriquement fondé, mais issu d’une autre communauté de pratiques – du CIDOC-CRM. Le document « Toward an International Conceptual Model for Archival Description… » mentionné plus haut mentionne déjà cela :

« Avant de collaborer, la communauté archivistique doit développer un modèle conceptuel qui réponde d’abord et avant tout aux principes et aux besoins des archivistes. Une fois ce modèle élaboré, la communauté sera bien placée pour se joindre aux communautés professionnelles apparentées dans une quête commune pour fournir un accès intégré à l’expression humaine sous toutes ses formes. »

Quelques années de patience, donc, avant une intégration RiC-CM / CIDOC-CRM  (RiCoo ? :-) )

Ricoconverter : Un convertisseur EAD et EAC vers RiC-O, par les Archives Nationales

Florence Clavaud, responsable de la mission Référentiels aux Archives Nationales, a largement développé l’ontologie RiC-O au sein du groupe EGAD. Sous son impulsion avait déjà été développé en 2017-2018 le prototype PIAFF (Pilote d’interopérabilité pour les Autorités Archivistiques françaises), incluant 276 notices d’autorités des AN, de la BNF et du SIAFF, converties dans la première version de RiC-CM et RiC-O qui datait de 2016.

Les Archives Nationales ont souhaité un passage à l’échelle après le succès de PIAFF, pour la conversion de l’intégralité des 28000 instruments de recherche et 15000 notices d’autorité des Archives Nationales, dans la version la plus récente de RiC-O. Le travail a été confié à votre serviteur. Le résultat est ricoconverter, un logiciel opensource, permettant de lancer simplement en ligne de commande une conversion d’un ensemble de fichiers EAD ou EAC vers du RDF/XML structuré en RiC-O. Ricoconverter est essentiellement basé sur 2 feuilles de style XSLT qui font l’essentiel du travail, enrobées dans un script Java. La feuille de style convertissant l’EAC est assez générique et transposable dans d’autres contextes probablement assez directement, la feuille de style EAD répond à l’implémentation spécifique de l’EAD aux AN et demandera plus d’adaptions; mais l’objectif de Ricoconverter est bel et bien de pouvoir être adapté et utilisé pas d’autres services d’archives pour produire des graphes de données RiC-O.

Les sources de ricoconverter sont disponibles dans Github à https://github.com/ArchivesNationalesFR/rico-converter.

Cerise sur le gâteau, quand on a un joli graphe RiC-O, on peut avoir un joli Sparnatural (voir ce billet de blog) qui permet de naviguer dans le graphe et de chercher par exemple « toutes les archives numérisées des organisations ayant succédé à la Direction des Beaux Arts (1848-1852) » (cliquer sur l’image pour voir le screencast) :

sparnatural-demo-ricoPrésentations de RiC-CM et RiC-O aux Archives Nationales le 28/01/2020

Pour aller plus loin on peut consulter les présentations sur RiC-CM, RiC-O, ricoconverter et plus encore faites lors de la journée d’étude du 28 janvier 2020 aux Archives Nationales.

Illustration : Institut, [salle des] archives : [photographie de presse] / [Agence Rol] Agence Rol. Agence photographique depuis Gallica.

Cet article RiC-CM, RiC-O : les Archives se dotent de leur modèle conceptuel (Records in Contexts) est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2020/04/20/rico-records-in-contexts-archives-modele-conceptuel/feed/ 4
SHACL Play! free online SHACL validator for RDF data http://blog.sparna.fr/2020/03/11/shacl-play-online-shacl-rdf-validator/ http://blog.sparna.fr/2020/03/11/shacl-play-online-shacl-rdf-validator/#comments Wed, 11 Mar 2020 14:00:37 +0000 http://blog.sparna.fr/?p=1301 SHACL Play! at http://shacl-play.sparna.fr/ is a free online RDF validator based on SHACL. It encapsulates TopQuadrant’s Java SHACL implementation as the actual validation engine. The code of SHACL Play is available on Github. Give the input RDF data to be validated, by uploading an RDF file, pointing to a URL, or copy/pasting inline data; Give the…

Cet article SHACL Play! free online SHACL validator for RDF data est apparu en premier sur Sparna Blog.

]]>
SHACL Play! at http://shacl-play.sparna.fr/ is a free online RDF validator based on SHACL. It encapsulates TopQuadrant’s Java SHACL implementation as the actual validation engine. The code of SHACL Play is available on Github.

  1. Give the input RDF data to be validated, by uploading an RDF file, pointing to a URL, or copy/pasting inline data;
  2. Give the SHACL rules to use for validation, by uploading a file, pointing to a URL, copy/pasting inline data, or selecting the shapes from the catalog (see below);
  3. Validate, and get a human-readable report generated from the SHACL raw validation report;
  4. Access to the report in its RDF or CSV variant;

Here is a screenshot of how the validation report looks like :

shacl-play-validation-report

SHACL Play! features :

  1. Free, no registration required, no limit;
  2. Easy-to-use input form;
  3. Multiple RDF serialisations supported (Turtle, RDF/XML, n3, TriG);
  4. Versatile input methods for both RDF data and SHACL rules (upload, URL, copy/paste, catalog);
  5. Human-readable validation report, for quick analysis of the issues to be fixed in the data (or adjusted in the shapes);
  6. Downloadable validation reports in CSV or raw RDF;
  7. Asynchronous validation to avoid timeouts, for large datasets (greater than 100000 triples);
  8. Permalinks to validation reports when both RDF dataset and SHACL rules are online;
  9. Catalog of online public shapes for documentation and quick validation (see below);

SHACL Play also features a command-line variant (see the documentation on the Github wiki).

Future features could include :

  1. Improved display of validation report, with possibly different styles of report (depending on the « styles » of the Shapes):
  2. Human-readable display of a SHACL graph;
  3. Online data transformation engine based on SHACL Rules, with a first focus on converting an OWL ontology to SHACL constraints (see this excellent description of one possible set of rules to derive SHACL shapes from an OWL ontology, by Irene Polikoff from TopQuadrant);

 

The Shapes Catalog

SHACL Play includes a catalog of online Shapes. The catalog is collaboratively editable by modifying the Shapes Catalog source file on Github, through pull requests.

Adding an entry to the catalog allows to:

Another SHACL Validator

Another SHACL validator is the SHACL playground is at https://shacl.org/playground/. However the UI is too technical for newcomers, and it relies on a Javascript validator in the browser, thus I am not sure it would be capable of validating large Datasets.

How to edit/create SHACL rules ?

You need to create your own set of SHACL rules ? You don’t have a tool to do that and you don’t want to write Turtle file by hand ? One technique I use is to edit them in an Excel spreadsheet that is converted in RDF using SKOS Play Excel 2 RDF converter. Here are 1 example of such a file : OpenArchaeo shapes in Excel.

You could start from this template and modify it to create your own Shapes Graph.

Now let’s SHACL Play!

 

Post illustration : « Calculateur » Bulletin des sciences mathématiques 1922, found from https://www.bnf.fr/fr/mathematiques-informatique-et-sciences-du-numerique, from Gallica at https://gallica.bnf.fr/ark:/12148/bpt6k9620547z/f123.item

Cet article SHACL Play! free online SHACL validator for RDF data est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2020/03/11/shacl-play-online-shacl-rdf-validator/feed/ 0
Semantic Markdown Specifications http://blog.sparna.fr/2020/02/20/semantic-markdown/ http://blog.sparna.fr/2020/02/20/semantic-markdown/#comments Thu, 20 Feb 2020 14:46:34 +0000 http://blog.sparna.fr/?p=1267 Markdown (MD) has become the de facto standard syntax for writing on the web, pushed by Github and StackOverflow. It is heavily used everytime one need to enter a comment, or write a simple (document-style) HTML page. What if we could embed semantic annotations in a markdown document ? We would get Semantic Markdown !…

Cet article Semantic Markdown Specifications est apparu en premier sur Sparna Blog.

]]>
Markdown (MD) has become the de facto standard syntax for writing on the web, pushed by Github and StackOverflow. It is heavily used everytime one need to enter a comment, or write a simple (document-style) HTML page. What if we could embed semantic annotations in a markdown document ? We would get Semantic Markdown ! imagine the best of both worlds between human readable/writable documents and machine-readable/writable (RDF) structured data. We could feed an RDF knowledge graph that is coupled with our set of MD documents, and we would have an easy way to put structure in content.

I see a lot of potential in this, and already see some use-cases. Unfortunately I don’t have the bandwith, nor the full skills to make this happens. So I am just writing this in the hope that the idea is implemented by someone, or that someone tells me it is totally nonsense…

Here are the semantic annotations use-cases I see with such a Semantic Markdown :

  1. Annotate a span or title that corresponds to an entity ;
  2. Annotate a piece of text with an existing URI for an entity;
  3. Create some statements on an entity;

Note that I am not necessarily looking for a way to produce RDFa annotations on the generated HTML, although that would be nice for a schema.org use-case. Any conversion route from the original semantically annotated markdown to a set of triples would be fine.

My source of inspiration is essentially Span Inline Attribute Lists » from the Kramdown syntax.

Annotate a span that corresponds to an entity

This piece of Semantic Markdown :

Tomorrow I am travelling to _Berlin_ {.schema:Place}

When interprered by a Semantic Markdown parser would produce this set of triples :

_:1 a <http://schema.org/Place> .
_:1 rdfs:label “Berlin” .

The span immediately preceding the « {.xxxx} » annotation is taken as the label of the entity. The use of rdfs:label to store the label of the entity could be subject to a parser configuration option.

One could imagine that a semantic markdown parser relies on the same RDFa Initial Context to interpret the « schema: » prefix without further declaration. But what about other ontologies ? we would need some kind of prefixes / vocab declaration somewhere in the document, just like in RDFa.

Note also that Markdown parser supporting the « {.xxxxx} » syntax will also insert this value as a CSS class on the corresponding span, so we win both on the CSS level and the semantic level.

Annotate a title

Similarly, we could annotate a title

### European Semantic Web Conference {.schema:Event}
Lorem ipsum...

In that case, the full content of the title is interpreted as the label of the entity :

_:1 a <http://schema.org/Event> .
_:1 rdfs:label “European Semantic Web Conference” .

Annotate with a known URI

Tomorrow I am travelling to [Berlin](https://www.wikidata.org/wiki/Q64) {.schema:Place}

Would yield

<https://www.wikidata.org/wiki/Q64> a <http://schema.org/Place> .
<https://www.wikidata.org/wiki/Q64> rdfs:label “Berlin” .

Describe an entity

If a list follows an annotated entity, then it should be interpreted as a set of predicates with this entity as subject :

### Specifications Meeting {.schema:Event}

* Date : _11/10_{.schema:startDate}
* Place {.schema:location} : Our office, Street name, 75014 Paris
* Meeting participants : 
  {.schema:attendee}
  * Thomas Francart{.schema:Person}
  * [Someone else](https://www.wikidata.org/wiki/Q80)
  * Tim Foo
* Description : Some information not annotated

### titre suivant
Lorem ipsum...

Should yield :

_:1 a <http://schema.org/Event> .
_:1 rdfs:label “Specifications Meeting” .
_:1 <http://schema.org/startDate> "11/10" .
_:1 <http://schema.org/location> "Our office, Street name, 75014 Paris" .
_:1 <http://schema.org/attendee> _:2 , <https://www.wikidata.org/wiki/Q80>, _:3 .

# attendee that is annotated : we know a type and a name
_:2 a <http://schema.org/Person>
_:2 rdfs:label “Thomas Francart” .

# attendee that is annotated with a URI : we keep the URI and add a label to it (?)
<https://www.wikidata.org/wiki/Q80> rdfs:label "Someone else" .

# attendee that is not annotated - but we know he was an attendee
_:3 rdfs:label "Tim Foo" .
  1. If a list follows a title or a paragraph that contains an annotated entity…
  2. Then items in this list correspond to a property of this entity…
  3. And can be annotated with a property
  4. The property annotation can be placed on an inline text, or right before or after a `:` or `=` character
  5. If the property annotation immediatly precedes a list, then all items in this list would be considered values for that property, and in that case could be either : entities annotated with a type, or entities identified by a URI, or entites not annotated (and in that case we would consider them as blank nodes with only a label

Related works

Metadata for Markdown, a Python extension to generated JSON-LD from YAML section in a Markdown document.

EDIT : PanDoc divs and spans : https://pandoc.org/MANUAL.html#divs-and-spans

I like the <span> syntax :

[This is *some text*]{.class key="val"}

This is close ! but still would not produce triples, unless one writes explicitely RDFa :

My name is [Thomas Francart]{typeof="schema:Person"}

Cet article Semantic Markdown Specifications est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2020/02/20/semantic-markdown/feed/ 12
SPARNAtural : écrire des requêtes SPARQL, tout naturellement http://blog.sparna.fr/2019/06/13/sparnatural-ecrire-des-requetes-sparql-tout-naturellement/ http://blog.sparna.fr/2019/06/13/sparnatural-ecrire-des-requetes-sparql-tout-naturellement/#comments Thu, 13 Jun 2019 15:19:57 +0000 http://blog.sparna.fr/?p=1258 Sparnatural est un composant Javascript permettant  de naviguer dans un graphe de connaissances RDF en construisant visuellement des requêtes SPARQL. UPDATE avril 2021 : Sparnatural a un nouveau site web a http://sparnatural.eu ! Dans la copie d’écran ci-dessus, on demande « Toutes les oeuvres exposées dans un musée Français qui expose une oeuvre du Caravage, et…

Cet article SPARNAtural : écrire des requêtes SPARQL, tout naturellement est apparu en premier sur Sparna Blog.

]]>
Sparnatural est un composant Javascript permettant  de naviguer dans un graphe de connaissances RDF en construisant visuellement des requêtes SPARQL.

UPDATE avril 2021 : Sparnatural a un nouveau site web a http://sparnatural.eu !

Dans la copie d’écran ci-dessus, on demande « Toutes les oeuvres exposées dans un musée Français qui expose une oeuvre du Caravage, et dont l’auteur est Italien ».

Démo de Sparnatural sur DBPedia

Le screencast ci-dessus est extrait de la démo de Sparnatural paramétrée sur DBPedia avec laquelle vous pouvez jouer en ligne.

Le développement de ce composant a été réalisé dans le cadre du projet OpenArchaeo où il est utilisé pour naviguer dans des données archéologiques. Il est autonome du projet et peut être réutilisé dans le cadre de sa license LGPL. Le code source est ouvert et il est interdit de « refermer » le code source, toute modification doit être publiée sous la même licence, et idéalement reversée dans le dépôt Github du projet.

Sparnatural s’inspire en grande partie de la navigation proposée par l’interface ResearchSpace du British Museum.

Et pourquoi c’est cool ?

  • Parce que ça n’existait pas !  (en dehors de ResearchSpace, mais dont le source est en React), en tout cas pas comme un composant autonome et paramétrable
  • Parce que le composant est paramétrable à souhait pour construire des requêtes sur différentes structures de graphe, en changeant le paramétrage des classes et des propriétés; vous pouvez jeter un oeil au fichier de paramétrage de la démo.
  • Parce qu’il est orienté end-user et que, en particulier, la structure du graphe que l’on présente à l’utilisateur n’est pas obligatoirement – en fait n’est jamais – celle du graphe de données sous-jacent:
    • Chaque classe dans le composant peut être mappé sur un critère plus complexe (On présente à l’utilisateur « Type d’activité », qui est mappé sur « tous les skos:Concept ayant un skos:inScheme ex:ActivityType »)
    • Chaque lien dans le composant peut être mappé sur une séquence de liens RDF dans le graphe (un property path) (Le lien « Musée expose oeuvre » dans le composant de construction de query est l’inverse du lien RDF « Oeuvre dbpedia:museum Musée »). Typiquement le paramétrage de tous les liens inverses permet à un utilisateur d’explorer le graphe en le prenant par n’importe quel bout;
    • On peut limiter les types d’objets et les types de liens que l’on présente dans le composant pour ne permettre d’interroger qu’une sous-partie des données;
  • Parce qu’il offre plusieurs mode de sélection des valeurs :
    • un champ d’autocompletion, à associer à une requête SPARQL (ou pas SPARQL) qui ira proposer des valeurs sur la base des caractères tapés dans le champs;
    • un champ de dropdown, pour les petites listes;
    • un champ de recherche texte;
    • un champ d’input de date (début / fin);
  • Parce que la requête peut s’exécuter au fur et à mesure de la construction de l’équation de recherche; pas besoin d’appuyer sur un bouton; cela fait beaucoup pour obtenir une expérience utilisateur de découverte des données;
  • Parce que c’est multilingue : on peut associer des libellés en plusieurs langue à chaque classe et chaque propriétés;
  • Parce que c’est facile d’injecter des icônes fontawesome pour illustrer chaque classe dans les menus;
  • Parce qu’on peut post-traiter la requête après que le composant l’a construite : ajouter la sélection de plusieurs colonnes, ajouter des préfixes, etc.
  • Parce que ça peut joliment égayer la platitude morne des formulaires de requêtes SPARQL que l’on expose à des utilisateurs, en s’intégrant avec YASGUI, pour permettre une découverte intuitive des données;

Le résultat, au-delà d’un simple éditeur SPARQL, offre une vraie expérience d’exploration des données, avec des mécanismes d’essai-erreur, retour arrière, prise du graphe par un autre bout, etc.

Limites de l’exercice

L’objectif est d’offrir un moyen simple et compréhensible de naviguer dans des données. En conséquence, Sparnatural n’est capable que de construire des motifs de graphe SPARQL simple, et ne sais pas gérer les UNION, OPTIONAL, sous-select, BIND, etc.

Par ailleurs le composant s’arrête à sélectionner les URIs des objets cherchés, il n’est pas possible pour un utilisateur de choisir les colonnes présentées dans le tableau de résultats. Il faut post-traiter la requête pour injecter la sélection des valeurs de colonnes.

Si, comme pour la démo DBPedia, vous intégrez Sparnatural avec YASGui et YASR et que la page HTML envoie la requête SPARQL, faites attention que le service SPARQL doit supporter les requêtes CORS (Cross-Origin Resource Sharing), ce qui n’est pas le cas de tous les services SPARQL… mais ça devrait !

Envie d’essayer ?

Rendez-vous sur le dépôt Github de Sparnatural si vous voulez un peu plus de doc ou que vous voulez remonter un ticket, un bug, ou contribuer au code. D’autres démos devraient suivre, stay tuned !

 

Cet article SPARNAtural : écrire des requêtes SPARQL, tout naturellement est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2019/06/13/sparnatural-ecrire-des-requetes-sparql-tout-naturellement/feed/ 4
Le CIDOC-CRM, ne nous arrachons plus les cheveux ! http://blog.sparna.fr/2019/03/26/le-cidoc-crm-ne-nous-arrachons-plus-les-cheveux/ http://blog.sparna.fr/2019/03/26/le-cidoc-crm-ne-nous-arrachons-plus-les-cheveux/#comments Tue, 26 Mar 2019 14:35:24 +0000 http://blog.sparna.fr/?p=1245 C’est vrai que quand on commence à entendre parler du CIDOC-CRM, il y a de quoi se sentir « Désespéré » (comme le tableau de Courbet); moi aussi, il y a quelques années, si on m’avait demandé de faire quelque chose avec le CIDOC-CRM je me serais arraché les cheveux si je les avais eu encore longs.…

Cet article Le CIDOC-CRM, ne nous arrachons plus les cheveux ! est apparu en premier sur Sparna Blog.

]]>
C’est vrai que quand on commence à entendre parler du CIDOC-CRM, il y a de quoi se sentir « Désespéré » (comme le tableau de Courbet); moi aussi, il y a quelques années, si on m’avait demandé de faire quelque chose avec le CIDOC-CRM je me serais arraché les cheveux si je les avais eu encore longs. Mais en fait, ce n’est pas si terrible, et après avoir utilisé ce modèle dans plusieurs projets, je le trouve d’une grande force et d’une grande richesse. Je vous propose plus bas 2 ressources que j’ai mis au point pour des formations sur le CIDOC-CRM : une navigation visuelle dans les classes du CRM+FRBRoo, et un début de tutorial SPARQL sur les données du British Museum.

Le CIDOC-CRM est une ontologie formelle de haut-niveau permettant de structurer la description et l’histoire d’objets patrimoniaux (tableaux, sculptures, bâtiments, fouilles archéologiques, etc.) – ou d’autres informations similaires. L’objectif de ce modèle est de permettre l’intégration de données provenant de sources hétérogènes dans un graphe commun, cohérent, à l’échelle d’une institution ou au-delà, permettant ainsi l’accès et l’interprétation scientifique de ces informations.
Le périmètre du CRM, tel qu’il est défini, est « toutes les informations requises pour l’échange et l’intégration de données scientifiques à propos du passé humain et de toutes les preuves de ce passé arrivées jusqu’à nous ». Etant fait pour la description structurée de l’histoire d’objets patrimoniaux, le CRM utilise a plein une modélisation évènementielle; c’est-à-dire que fondamentalement, on ne dit pas « Le tableau Le Désespéré a pour date de création : [entre 1843 et 1845] », mais « Entre 1843 et 1845, Gustave Courbet a conduit une Activité de Création dont l’objet était le tableau Le désespéré« ; nuance. D’ailleurs, si j’en crois la notice Wikipedia, on ne dit pas non plus « ce tableau a pour titre Le Désespéré« ; on dit « Gustave Courbet a effectué une activité de nommage de ce tableau qu’il a baptisé Désespoir« , puis « Quelqu’un d’autre (qui ?) a (probablement) effectué une autre activité de nommage (quand ?) et a baptisé le même tableau Le Désespéré« .

Ce qui fait la force du CIDOC-CRM…

Le CIDOC-CRM est un modèle issu de plus de vingt ans de standardisation au sein du Comité International pour la Documentation (CIDOC) du Conseil International des Musées. Autant dire qu’il est le résultat d’une sédimentation de longues réflexions, ce qui rend ses fondations théoriques extrêmement solides. Le CRM a fait l’objet de 2 versions d’un standard ISO, ISO21127:2004 et ISO21127:2014. Il donne donc un cadre de modélisation rigoureux, mais avec une logique qu’il faut s’approprier.

Son paradigme de modélisation événementielle est très puissant et permet d’exprimer de nombreuses informations de façon très flexible. Les Evènements (ou plutôt, les Activités) sont les objets centraux que l’on décrit à l’aide du CIDOC-CRM : des Acteurs participent à des Evenements, qui se produisent dans un Lieu donné, une Temporalité donnée, et affectent des Objets donnés; tout cela pouvant être nommé avec des Appellations et typer avec des Types. Voilà, en une phrase, vous savez tout !

Le CIDOC-CRM est un modèle générique avec un fort niveau d’abstraction, et il ne descend volontairement pas dans le détail de spécifications de certains domaines métier particulier; c’est pourquoi il a fait l’objet d’extensions pour des domaines spécifiques. Dans le monde de l’infodoc on citera en particulier FRBRoo, l’intégration des principes du FRBR dans le cadre de la modélisation orientée objet du CIDOC-CRM, ou bien PRESSoo, lui-même une extension de FRBRoo pour la carctérisation des publication en série; dans d’autres domaines, on peut citer CRMarchaeo, une extension pour la description des données archéologiques, une communauté active autour du CIDOC-CRM.

…Et ce qui le rend compliqué

Ce n’est pas la taille de ce modèle qui le rend compliqué. Le CIDOC-CRM contient 84 classes et 154 propriétés (288 si on compte aussi les inverses) (chiffre approximatif). C’est peu, si l’on compare aux 602 classes et 877 propriétés de schema.org, et cela en fait une ontologie de taille moyenne.

Franchement, la chose qui le rend le plus compliqué, c’est peut-être sa documentation. Un sympathique fichier PDF de 115 pages (tiens, une nouvelle version sort aujourd’hui 26 mars 2019, un hasard), ça c’est sûr, c’est de la spécification formelle ! de bon vieux tableaux de propriétés à la schema.org pourraient être les bienvenus. MAIS MAIS mais, pour vous aider à vous plonger dans le CIDOC, voici une petite visualisation de l’arborescence des classes du modèle et de FRBRoo, construite à partir de SKOS-Play :


Par ailleurs, les diagrammes fournis pour les uses-cases, assez utiles, utilisent un formalisme auquel on n’est pas habitué dans la modélisation d’ontologies classiques. Pour d’autres documents d’introduction on pourra consulter avec profit la présentation du CRM et de FRBRoo sur le site de Doremus.

Un des autres aspects qui le rend compliqué c’est son fort niveau d’abstraction. Le CRM définit en effet des notions comme « Persistent Item », « Man-Made Thing », « Propositional Object »… pas évident de s’approprier la définition de ces notions. Ajoutez à cela que tous les identifiants du CRM commencent par un code : « E5_Event », « E70_Thing », « P94_has_created », et la lecture devient compliquée. Cette identification, rebutante au premier abord, n’est finalement pas pire qu’une autre, d’autant que les noms des propriétés et des classes sont associés à des définitions très précises, et on fini par connaître par coeur les plus importants (E55_Type, P14_carried_out_by…).

Par ailleurs le CRM est formellement défini dans le PDF de référence sus-mentionné, et il n’existe pas d’implémentations de référence du modèle en OWL. Les implémentations OWL fournies sur le site sont explictement non-officielles, et de toutes façons pas à jour. L’implémentation OWL la plus à jour (mais qui date tout de même d’il y a 2 ans, et de 3 versions du modèle) semble être celle d’Erlangen-CRM. Ce n’est donc pas forcément immédiat d’intégrer ce modèle dans une application basée sur les technologies du web de données.

Les projets qui utilisent le CIDOC-CRM

Mais qui qui qui (sont les snorkis) se sert du CIDOC-CRM ? L’implémentation la plus impressionnante est celle du British Museum, notamment au travers de l’interface ResearchSpace. Vous aimez les spaghettis ? voici la formalisation des données du catalogue du BM en CIDOC-CRM :

Vous voulez expérimenter avec les données CIDOC-CRM du BM ? je vous propose un tutorial d’interrogation des données du British Museum en SPARQL.

Aux Etats-Unis, le Yale Center for British Art publie également des données dans le CIDOC-CRM, mais semble-t-il assez light.

Le projet Doremus a créé une extension de FRBRoo / CIDOC-CRM pour la musique classique (composition, concerts), documentée ici.

Je travaille en ce moment sur une première version de la plateforme OpenArchaeo pour l’intégration de données de fouilles archéologiques, alignées sur le CIDOC-CRM à partir de base relationnelles (base ARSOL) et de fichiers XML (base AERBA).

Par ailleurs, dans le cadre de ELI (European Legislation Identifier), j’ai spécifié l’extension du modèle ELI pour la description des étapes et des documents lors de l’élaboration des projets de lois : ELI-DL (pour « draft legislation »); c’est un bon cas pour l’utilisation du CIDOC-CRM et de FRBRoo, puisque l’élaboration d’une loi est vue comme une séquence d’Activités utilisant ou produisant des documents, jusqu’à la publication finale de la loi au JO. C’est également un bon scenario d’utilisation du CIDOC-CRM comme cadre méthodologique, tout en utilisant uniquement des propriétés métier pour masquer les notions trop abstraites du CRM.

On peut également supposer que l’Institut National d’Histoire de l’Art (INHA) s’intéresse à ce genre de sujet. Le laboratoire LARHRA, laboratoire de recherche historique à Lyon, s’y intéresse également dans le cadre du projet SYMOGIH, pour lequel un autre modèle de données avait été initialement mis au point.

Les outils pour convertir

Le CIDOC-CRM étant un modèle fait pour l’intégration de données, le labo de FORTH, en Crète, qui abrite les cerveaux du CRM, a mis au point un language et un outil de mapping, X3ML, permettant de mapper et convertir des fichiers XML vers le modèle CIDOC-CRM. Pour convertir les données de bases relationnelles, on peut utiliser –Ontop–.

Alors, près à vous frotter au CIDOC-CRM ? avec toutes ces infos au moins, vous ne vous arracherez pas les cheveux !

Cet article Le CIDOC-CRM, ne nous arrachons plus les cheveux ! est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2019/03/26/le-cidoc-crm-ne-nous-arrachons-plus-les-cheveux/feed/ 6