Another star to light on EU’s linked open data maturity flag !

Not talking about 2024 exceptional Northern Lights to come, but this one’s also good news for science !

➡️ Late 2023, the Publications Office of the European Union announced on social media the public release of the new CORDIS SPARQL endpoint.

CORDIS, aka « the Community Research and Development Information Service of the European Commission », is « the […] primary source of results from the projects funded by the EU’s framework programmes for research and innovation, from FP1 to Horizon Europe ». Described as a « rich and structured public repository with all project information held by the European Commission such as project factsheets, participants, reports, deliverables and links to open-access publications », the CORDIS catalog has also been made available in 6 European languages by Publications Office’s editorial team.

Cherry on top of a whole process, the CORDIS SPARQL endpoint release comes to crown a long-term linked open data project. The aim identifying, acquiring, preserving and providing access to knowledge in a common will to share with the widest public possible a trust-worthy, qualified and structured information (see Publications Office 2021 Annual Management Report).

In the context of the pandemic (and recent opening of data.europa.eu, the official portal for European data, as defined in 2017–2025 European Open Data Space strategy), the EuroSciVoc taxonomy of fields of science was released April 2020, followed December 2021 by the publishing of European research information ontology (EURIO) on the EU Vocabularies website .

As presented at ENDORSE conference March 2021, the redesign of CORDIS data-model in accordance with Semantic Web standards contributed to bring the platform « from acting as a data repository to finally playing an active role as data provider », where EuroSciVoc taxonomy & EURIO ontology both played key roles in the creation of future CORDIS knowledge graph and SPARQL endpoint :

EuroSciVoc […] is a multilingual, SKOS-XL based taxonomy that represents all the main fields of science that were discovered from the CORDIS content, e.g., project abstracts. It was built starting from the hierarchy of the OECD’s Fields of R&D classification (FoRD) as root and extended through a semi-automatic process based on NLP techniques. It contains almost 1 000 categories in 6 languages (English, French, German, Italian, Polish and Spanish) and each category is enriched with relevant keywords extracted from the textual description of CORDIS projects. It is constantly evolving and is available on EU Vocabularies website […].

In order to transform CORDIS data into Linked Open Data, thus aligning with Semantic Web standards, best practices and tools in industry and public organizations, the need for an ontology emerged. CORDIS created the EURIO (European Research Information Ontology) based on data about research projects funded by the EU’s framework programmes for research and innovation. EURIO is aligned with EU ontologies such as DINGO and FRAPO and de facto standard ontologies such as schema.org and the Organization Ontology from W3C. It models projects, their results and actors such as people and organizations, and includes administrative information like funding schemes and grants.

EURIO, which is available on EU Vocabularies website, was the starting point to develop a Knowledge Graph of CORDIS data that will be publicly available via a dedicated SPARQL endpoint. »

(Enrico Bignotti & Baya Remaoun, « EuroSciVoc taxonomy and EURIO ontology: CORDIS as (semantic) data provider  » , ENDORSE March 16, 2021. PDF VIDEO)

… A Knowledge graph that was soon released in 2022-2023 (see INDUSTRY TRACK 1 on Tuesday, 25 October of ISWC 2022 Conference for more detail), until final opening of a CORDIS SPARQL endpoint late november 2023.

Now fancy a few SPARQL queries in there ?

Follow the SPARQL

CORDIS SPARQL endpoint is actually made available on CORDIS Datalab (and already referenced in EU Knowledge Graph among other European SPARQL endpoints ! see the query / see the results)

Here you can access a quick documentation guide to CORDIS Linked Open Data : https://cordis.europa.eu/about/sparql.

Let’s have a look at EURIO ontology first : we need to understand it to query CORDIS knowledge graph.

As we are told in the guide, the latest version can be downloaded on EU Vocabularies website. When we unzip the archive we access the whole documentation about EURIO Classes & properties that we need to write our SPARQL queries – and a diagram of main classes and properties of CORDIS data model : 

At first sight we can observe on the schema 3 main groups of entities :

• On the top right, the projects & publications associated, key ressources of CORDIS ;
• On the top left, the fundings & grants materials, on « monetary » side of the project ;
• On the bottom, the organisations & persons implied, with references & coordinates.

Let’s open CORDIS SPARQL endpoint – some easy queries can be run to begin exploring CORDIS knowledge graph.

Nb : the data on SPARQL endpoint is a snapshot, but freshest dumps can be found on European data portal !

Here a simple one to find a list of FundingSchemes with their titles and IDs corresponding to « Horizon 2020 » programme :

▶️ See the results

The FILTER REGEX enables us to display the IDs corresponding to H2020 Funding Schemes.

We can make another query to get the projects with the Funding Scheme Programme they are related to (note that, in EURIO a eurio:hasFundingSchemeProgramme is a sub-property of eurio:fundingScheme) :

▶️ See the results

(Here we used a property path with a « / » to shorten the query to get the acronyms of projects & Funding Scheme Programmes codes).

… and combining with the first query we can find the projects depending on H2020 Funding Scheme Programme in particular :

▶️ See the results

It is also possible to get the list of all existing Funding Scheme Programmes CORDIS projects have been funded by – we observe 27 of them here (from the SPARQL endpoint) – while adding a count function to know how many projects per FundingSchemeProgramme :

▶️ See the results

Querying the organisations properties will return other kind of useful informations about geographical location of the projects stakeholders. Let’s figure out we want to find the projects whose coordinating organisations have sites located in France :

Projects whose coordinating organisations have sites located in France  PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX eurio: <http://data.europa.eu/s66#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?project ?acronym ?role ?organisation ?country WHERE { # select the projects with their acronyms … ?project a eurio:Project. ?project eurio:hasAcronym/eurio:shortForm ?acronym. # … and organisations with ‘coordinator’ role and name … ?project eurio:hasInvolvedParty ?organisationrole. ?organisationrole eurio:roleLabel ?role. ?organisationrole eurio:roleLabel « coordinator ». ?organisationrole eurio:isRoleOf/eurio:legalName ?organisation. # … with address country for the sites defined at ‘FR’ ?organisationrole eurio:isRoleOf/eurio:hasSite/eurio:hasAddress/eurio:addressCountry ?country. VALUES ?country { ‘FR’ } } LIMIT 100

▶️ See the results

Depending on available data, you can either query via PostalAddress info (eurio:addressCountry ‘FR’) or AdministrativeArea (eurio:hasGeographicalLocation) … Here we’re lucky as both fields are mandatory ones.

Last but not least, we can also play with CORDIS vocabularies : here you’ll have the choice to investigate via plain keywords of Projects or Publications items, querying titles, abstracts or other types of literals…

An example of projects with abstracts containing string ❄ ‘winter’ ❄ – the URL giving the exact link to the project online :

▶️ See the results

But funniest way will be using EuroSciVoc taxonomy (and navigating through thesaurus hierarchy) : to do so we need to navigate through property « eurio:hasEuroSciVocClassification » to get the Concepts skosxl:prefLabel property … to finally obtain the thesaurus labels (don’t forget to choose a prefered language with a FILTER (lang parameter) :

Projects with their associated EuroSciVoc keywords (English prefLabels ) PREFIX skosxl: <http://www.w3.org/2008/05/skos-xl#> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX eurio: <http://data.europa.eu/s66#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?project ?acronym ?ESV WHERE { # select the projects with their acronyms … ?project eurio:hasAcronym/eurio:shortForm ?acronym. # … with EuroSciVoc Classification prefLabels … ?project eurio:hasEuroSciVocClassification/skosxl:prefLabel/skosxl:literalForm ?ESV. # … only returning ‘English’ prefLabels FILTER (lang(?ESV) = ‘en’) } LIMIT 100

▶️ See the results

A bit more complex one using first level of hierarchy of the taxonomy : here we are searching for all skos:broader concepts « with no other broader concept » (the FILTER NOT EXISTS formula), aka the top concepts or root concepts of the vocabulary used to describe the projects. Then counting the projects by each category :

▶️ See the results

… and maybe again more explicit results if refined to level 2 of hierarchy  :

▶️ See the results

And a little last one with a count, to enumerate most used EuroSciVoc Concepts for indexing projects :

▶️ See the results

This one an ideal one to generate a word cloud maybe ?

What if we send the CSV data to some nice online word cloud generator then ?

(OMG they also have a shooting star shape  in there 🤩)

As a conclusion…

According to Science (CORDIS saying !), New Year’s resolutions appear difficult to be held… because most of time too ambitious, restrictive or unprecisely formulated : indeed, « the effectiveness of resolutions depends on how they are framed. »

Horizon 2024, let’s suggest a(n RDF ?) well-framed one : may CORDIS SPARQL endpoint initiative be an example for other structures who want to share Linked Open Data !

Wishing you Best Interoperability and a Very Merry ✨ Sparqling New Year ! ✨

Cet article CORDIS : a SPARQL endpoint is born ! est apparu en premier sur Sparna Blog.

To inaugurate my first article on Sparna’s blog, let’s share a little feedback of mine today about Sparna’s well-known SKOSPlay! whose 10 years’ birthday is to celebrate this year !

10 yo, quite a historic tool ! but more than ever actual in a context where the semantic technologies get front of the scene anew due to growing interest shown by the digital humanities movement to data interoperability projects via the standardized knowledge structuration (Wikipedia-Wikidata projects e.g., as semantic wiki devices), and also due to the last progress of artificial intelligence, now able to processing large amount of data and soon fully leveraging the potential of ontologies and knowledge graphs.

From asking for a taxonomy to querying RDF files with an API…

This said, in a more practical way, semantic web standards are not always easy to manipulate as a professional – if non-initiate to SPARQL and nor confirmed data scientist, and even when you have got to deal with a simple structured list of terms !

Either your data is already SKOS-standardized (great !), there sometimes come to have a gap between normalization step and visualization step that requires a bit more technical IT skills. Either – most of time – the common muggle-born is to start with a plain Excel spreadsheet, create a list, add some hierarchy, maybe other scope notes or definitions and… end far puzzled wondering how to get a 5-star data vocabulary ⭐ !

A SKOSPlay!-within-a-SKOSPlay!

Wink to @belett, anything possible now with SKOSPlay!

Aiming at visualizing (and printing !) SKOS thesauri, taxonomies and vocabularies at the very beginning, SKOSPlay! is a full online free and open source tool leveraging semantic technologies (RDF, SPARQL, inference, Linked Data) to generate downloadable HTML or PDF documents. More and more new features have been added since then : alignments display, OWL and SKOS-XL files processing, autocomplete fields and permuted indexes generating …

Hello @veronikaheim, maybe SKOSPlay! could match your need ?

… among other nice and useful developments.

But as an Excel aficionada, the one that I prefer is the Excel-to-RDF converter tool.

One sheet. One import. One result. Easy-peasy, happy terminologist :))

(And you can even keep your custom colors templates and formats !!! 🦄 )

Come on & let’s SKOSPlay!

Let’s figure out you want to display or construct a small vocabulary you could quickly visualize in a standardized SKOS-structured way :

Now to fit in the SKOS model your data has to follow a particular template you can fullfill by downloading on SKOSPlay! website.

First you have to define the header of the template : the global scheme of your vocabulary, its URI, title and description :

Adding the terms of your list (with the URIs)… Here with the “@en” language indication on top of the column as I am to create an English-French multilingual vocabulary :

Recreating the arborescent structure through the Excel template (don’t mind my color palette, I always like colouring my Excel sheets to better visualize the info at a glance !).

The hierarchical broader-narrower structure is to be recreated by adding a “skos:narrower” column (or skos:broader, as you want, with only 1 broader value per line) where you will list the different specific values front of the more generic one (separated by comas). Here I used a PREFIX too in order to shorten my http:// URIs, SKOSPlay! can process them anyway !

Then adding a few notes and other information (multilingual values, skos:notation, any other default properties known in the converter (see the documentation) or different custom elements of yours by adding other PREFIXes :

Your Excel template is ready to go ! quite an easy configuration in my demo here, but SKOSPlay! can also deal with skos:Collections, SKOS-XL and other advanced RDF structures : blank nodes, RDF lists, named graphs. And now possible to generate OWL and SHACL files with the converter too !

Now it’s time to turn your (finally-not-so-dirty-) data into a SKOS-charming file. Take your favorite magic wand SKOSPlay! Excel-to-RDF converter tool and load your Excel file in it (adding some optional parameters if needed).

Well done, it’s a wonderful RDF-ized vocabulary file (here in a Turtle format but you have also RDF/XML, N-Triples, N-Quads, N3 and TriG available) :

Wingardium Visualiza !

We’re almost done. Go back to the website, tab “Play!”, load your last RDF-serialized file and go to the next step to chose the kind of display you want to get, endly press (SKOS)Play! and … abracadataaaaaaa !

Many different options to visualize your arborescent data. Tree, static and dynamic, but also more « professional » and printable sorts of displays like alphabetical, hierarchical or permuted views :

And KWIC (as for « KeyWord In Context ») :

Even possible to load an online Google spreadsheet (mine is shared here), just by adapting a little its URL for the converter’s need. Interesting feature in a collaborative purpose when you are team-building a vocabulary !

The whole pack fully documented and findable on Sparna’s website & Git. Some recent users even produced a short video tutorial to show what they managed to do with different SKOSPlay! visualization tools.

Already knew about SKOSPlay! ? go see his little brother, SHACLPlay! and feel free to give us some feedback in the comments 

Happy Birthday SKOSPlay! & Long live Semantic Web !

A bit more Vouvray with your nougat de Tours ?

Cet article 2013-2023 : ‘Tis SKOSPlay!’s Birthday ! est apparu en premier sur Sparna Blog.

Réutiliser d’autres vocabulaires/modèles

Le web de données permet de partager et relier des données sur le web, et il permet également de partager et relier des modèles de données. Réutiliser un modèle déjà existant pour exprimer ses données permet 1/ de bénéficier de la réflexion et des bonnes pratiques de modélisation qui ont sédimenté dans ce modèle et 2/ de rendre les données ainsi exprimées plus facilement compréhensibles et compatibles avec d’autres applications.

Il est donc tout à fait possible pour modéliser son domaine de « faire son marché » parmi les modèles déjà publiés, par exemple en parcourant l’annuaire du LOV (Linked Open Vocabularies). Trois modèles notamment sont réutilisables presque à tous les coups : FOAF pour décrire des personnes, des organisations et des documents, DCTerms pour des métadonnées qui s’appliquent largement (« creator », « subject », « publisher », etc.), et SKOS (dont je re-mentionne au passage la traduction française) pour tout ce qui est liste contrôlée. Ces 3 vocabulaires sont d’ailleurs les plus réutilisés dans l’écosystème des modèles du web de données.

Outre ces 3 vocabulaires, nous avons également pour le modèle de description des fonds d’archives réutilisé OWL Time pour la représentation des dates et des intervalles temporels, wgs84_pos pour l’expression des latitudes/longitudes, et une seule propriété de PROV-O, le modèle de description de la provenance récemment recommandé par le W3C (voir plus bas).

Qualifier les propriétés

Si vous lisez ceci je ne vous apprendrai rien en disant que RDF est un modèle de triplets, sujet-prédicat-objet (dans le cas contraire, voir cette introduction). Donc en RDF on dit : « L’entreprise Lafarge (sujet) possède un siège social (prédicat) en France (objet) ». Le problème, dans les descriptions archivistiques, c’est que les entités sont décrites, par définition, au passé. Et que, dans le passé, il s’en est passé des choses, justement, et que les informations relatives à une entité ont évolué. Il faut donc être capable, pour toutes les informations composant la description d’une entité (nom, siège social, liens avec d’autres entités…), de les qualifier avec des dates de validité (et pourquoi pas également des lieux de validité). C’est-à-dire qu’au lieu de dire « Lafarge possède un siège social en France », on dit « Lafarge entretient une relation de siège social avec la France, relation qui était valable jusqu’en avril 2014″ (le cimentier Français ayant décidé de déplacer son siège social en Suisse après sa fusion avec Holcim).

On dit qu’on réifie la relation, on la transforme en ressource à part entière pour pouvoir exprimer des choses dessus. Autant dire que cela complexifie nettement le modèle. Mais c’est le prix à payer pour structurer ces informations complexes. Dans la syntaxe RDF Turtle, on passe, sans qualification de dates, de :

ex:Lafarge mdfa:pays ex:France .

à ceci, avec une date de validité exprimée à la fois comme date structurée (« 2014-04-11″) et à la fois comme chaine de caractères (« jusqu’en avril 2014″) :

ex:Lafarge mdfa:pays _:b .
_:b rdf:type mdfa:RelationLieu .
_:b mdfa:lieu ex:France .
_:b mdfa:dateValidite _:c .
_:c time:hasEnd _:d .
_:c rdfs:label "jusqu'en avril 2014" .
_:d time:inXSDDateTime "2014-04-11"^^xsd:date .

Ou, en notation Turtle abbréviée :

ex:Lafarge mdfa:pays [
  rdf:type mdfa:RelationLieu ;
  mdfa:lieu ex:France ;
  mdfa:dateValidite [
    time:hasEnd [ 
      time:inXSDDateTime "2014-04-11"^^xsd:date ;
    ] ;
  ] ;
  rdfs:label "jusqu'en avril 2014";
]

Prendre en compte les valeurs textuelles

J’espère qu’aucun archiviste qui lit ceci ne sera vexé si je dis que les descriptions d’archives actuelles ne sont pas très structurées. J’entends par là que, de ce que j’ai pu en voir, le contenu des descriptions est essentiellement textuel, et que peu de listes contrôlées ou de thesaurus sont utilisés pour structurer les valeurs que l’on renseigne dans les différents champs de la description. D’autre part, par la force des choses, certains éléments d’information sont manquants, ou imprécis, et il peut être difficile ou impossible de leur donner une valeur contrôlée. Quelques exemples :

• Pour indiquer la plage de date couverte par un fonds d’archives : « 1923-1932, 1936-1945 (manque 1933 à 1935) » (tiré de la norme ISAD(G));
• Pour indiquer la modalité d’entrée d’un fonds aux services d’archives : « Don de la Société ardoisière de l’Anjou (exploitation de Renazé) aux Archives départementales de la Mayenne, 1969″ (tiré de la norme ISAD(G));
• Pour indiquer une source complémentaire à un fonds (un autre fonds d’archives, géré dans un autre service, pouvant donner des informations supplémentaires sur les mêmes institutions/personnes/lieux) : « Archives départementales de la Savoie $ SA 243-244 : collèges d’Avignon (dont celui d’Annecy) »;

La création d’un modèle de description des fonds d’archives ayant pour objectif de structurer de telles descriptions se doit à la fois de les amener à plus de structuration pour améliorer l’accès et la gestion de l’information, et en même temps se doit de rester compatible avec les données telles qu’elles sont aujourd’hui; c’est-à-dire qu’il faut tout à la fois conserver la valeur de date « 1923-1932, 1936-1945 (manque 1933 à 1935) » sans perte, et en même temps permettre de structurer cette valeur si possible, pour donner la possibilité de rechercher les fonds en utilisant une plage de dates que l’on sélectionne dans des calendriers, ce qui n’est pas possible si les informations de dates sont laissées textuellement.

Cela a eu des conséquences à plusieurs endroits dans le modèle :

• Première conséquence, lorsqu’il est nécessaire d’indiquer une référence à un autre fonds d’archives, géré par un autre service d’archives, il faut pouvoir y faire référence même si ce fonds ne possède pas (encore) d’URI sur le web de données. RDF propose pour cela un mécanisme de noeuds blancs, ou noeuds anonymes, permettant d’associer des informations à une ressource dont on ne connait pas l’identifiant, ou qu’on ne souhaite pas identifier avec une URI. Cependant ce n’est pas vraiment ce que l’on veut faire ici. Lorsque l’on indique comme source complémentaire « Archives départementales de la Savoie $ SA 243-244 : collèges d’Avignon (dont celui d’Annecy) », il ne s’agit pas nécessairement du titre exact ou de la cote exacte d’un autre fonds, mais simplement d’une référence textuelle à quelque chose (peut-être à plusieurs choses d’ailleurs) dont le titre par exemple, est différent de ce que l’on indique en y faisant référence. Le modèle contient donc un mécanisme de référence textuelle pour faire référence à un fonds ou à une entité, qui permet :

1. de rester compatible avec les valeurs textuelles existantes dans les données actuelles;
2. de pouvoir faire référence à un fonds ou à une entité dont on ne connait pas précisément le titre, l’intitulé ou l’URI;
3. de pouvoir travailler dans un mode « on exprime la relation d’abord, et on essaie de résoudre la valeur contrôlée ensuite »;
4. de pouvoir travailler à un niveau de granularité et de finesse que l’on choisit (trouver/sélectionner la bonne valeur contrôlée prend du temps, en rester à une référence pas/peu contrôlée est plus simple);

Prenons l’exemple d’un fonds d’archives qui serait la copie d’un autre, et dont on veut indiquer l’original :

On peut indiquer cette référence sous forme de texte ainsi :

ex:fondsArchives_1 mdfa:aPourOriginal [
        mdfa:referenceTextuelle "collège Saint-Nicolas d'Annecy (1642-1785)." ;
]

Ou bien résoudre la référence, trouver la bonne URI contrôlée, et l’indiquer :

ex:fondsArchives_1 mdfa:aPourOriginal [
        mdfa:referenceTextuelle "collège Saint-Nicolas d'Annecy (1642-1785)." ;
        mdfa:ressource ex:uriUnAutreFondArchives ;
]

• Deuxième conséquence sur la description des dates : les dates mentionnées dans les descriptions de fonds sont soit : 1/ compliquées à décrire (« 1923-1932, 1936-1945 (manque 1933 à 1935) ») ou 2/ imprécises (« milieu du XIXème siècle »). On ne peut donc pas se contenter de 2 propriétés de dates (début et fin), il faut également pouvoir associer à l’information de date une description textuelle, et donner la possibilité, lorsque cela est possible/souhaitable, de structurer l’information. Pour cela nous avons réutilisé l’ontologie OWL Time qui permet de décrire des intervalles de dates, et d’associer à l’intervalle lui-même, ou bien à une date de début ou de fin d’intervalle, une description textuelle aussi bien qu’une information de date contrôlée;

Premier exemple, pour décrire les dates de contenu d’un fonds :

:fondsArchives_1 mdfa:datesContenu [
        rdfs:label "Du 1er janvier 1920 jusqu'aux environs de 1951"
        time:hasBeginning [ time:inXSDDateTime "1920-01-01"^^xsd:dateTime ] ;
        time:hasEnd [ time:inXSDDateTime "1951-01-01"^^xsd:dateTime ] ;
  ]

Deuxième exemple, pour décrire les dates de naissance et de décès d’une personne :

:personne_1 mdfa:datesExistence [
        rdfs:label "Date de naissance inconnue, mort le 23/10/1873"
        time:hasEnd [ time:inXSDDateTime "1873-10-23"^^xsd:dateTime ] ;
]

• Troisième conséquence sur des propriétés tantôt littérales, tantôt contrôlées; RDF et OWL permettent, on a un peu tendance à l’oublier, de déclarer des propriétés sans préciser si leur valeur sera une valeur contrôlée ou une valeur littérale. C’est ce que fait SKOS par exemple, pour les propriétés de notes descriptives : une note SKOS peut être une valeur littérale, ou une référence à une entité représentant la note (voir le SKOS PRIMER). De telles propriétés sont des Annotation Properties. C’est ce mécanisme que nous avons utilisé pour déclarer par exemple les propriétés correspondant au statut juridique, à la modalité d’entrée ou au support d’une ressource archivistique. Cela veut donc dire par exemple que, dans le cadre de cette ontologie, on laisse le choix de décrire les statuts juridiques comme une liste de valeurs contrôlées par un thesaurus en SKOS, ou bien comme une valeur textuelle libre.

On pourra donc dire tout aussi bien, pour indiquer la langue en utilisant une valeur contrôlée :

ex:notice_de_fonds_archives_1 dcterms:language <http://lexvo.org/id/iso639-3/lat> .

(on utilise dans cet exemple l’identifiant de langue latine issu de Lexvo, mais tout autre thesaurus contrôlé des langues peut faire l’affaire).

Ou bien ceci, en utilisant une description textuelle :

ex:notice_de_fonds_archives_1 dcterms:language "Latin. Ecriture insulaire 
(noter en particulier l'abréviation utilisée pour per)" .

Spécialiser les entités

La vision du monde RDF et OWL comporte un présupposé majeur : il existerait dans le monde réel des « choses » que l’on peut identifier de manière certaine, que l’on peut isoler des autres, et auxquelles on peut donner une URI. C’est une vision où le monde se « discretise » pour mieux se manipuler. Une manipulation du monde sans le langage. Mais il n’est pas du tout sûr que des « entités » que l’on puisse identifier et isoler existent ailleurs que dans notre tête (je crois que Chomsky et Gondry parlent de ça, si j’ai bien compris, mais il faudrait que je revoie le film). Et une vision du monde qui ne prend pas en compte l’aspect temporel. Alors que tout change. Qu’on ne se baigne jamais deux fois dans la même eau. Que seul le changement est permanent. etc.

Mais revenons à nos archives pour replacer ce problème en contexte : l’archiviste décrit toujours une entité (comme une société par exemple) en regardant dans le rétroviseur, au passé. On ne décrit donc pas « une société », on décrit « la vie de la société ». Est-on en droit de dire que l’on parle de la même société lors de son immatriculation et 30 ans plus tard quand elle est devenue une multinationale ? Est-ce que la société Apple au début des années 1980 et la société Apple en 2014 sont la même chose ? peut-être pas. Ou pas complètement. Tout ce qui se rapporte à « Apple au début des années 1980″ ne se rapporte pas forcément à « Apple en 2014″.

On ne peut pas se contenter d’assigner une seule URI unique pour identifier une entité dont on souhaite rendre compte de l’évolution. Il nous en faut plusieurs. Et autant le point de départ de ce paragraphe nous a emmené dans des questions philosophiques théoriques, autant la solution pragmatique à ces questions est simple. Le modèle d’ontologie proposé par le W3C pour décrire la « provenance » (on dirait plutôt l’ « origine » ou l’ « historique », en français), PROV-O, propose 2 notions intéressantes : la notion d’ « Entité » (qui peut être ce qu’on veut : « An entity is a physical, digital, conceptual, or other kind of thing with some fixed aspects; entities may be real or imaginary. ») , et la notion de « spécialisation d’entité ». Et c’est cette dernière notion qui va particulièrement nous intéresser : la « spécialisation » d’une entité « en possède toutes les caractéristiques et présente en plus certains aspects spécifiques de cette entité. En particulier la plage de validité (lifespan) de l’entité qui est spécialisée contient les plages de validité de ses spécialisations. Des exemples de spécialisation peuvent être une période de temps ou un certain contexte. »

On pourra donc par exemple avoir 1/ une URI pour désigner « Apple » en tant qu’entité générique 2/ une URI pour chaque grande période de la vie de société, comme par exemple les 6 grandes périodes décrites dans l’historique de la page Wikipedia :

ex:Apple_entre_1976_et_1980 prov:specializationOf ex:Apple_en_general .
ex:Apple_entre_1981_et_1989 prov:specializationOf ex:Apple_en_general .
ex:Apple_entre_1990_et_1999 prov:specializationOf ex:Apple_en_general .
etc...

La finesse du découpage de la vie de l’entité en périodes historiques est laissée à l’appréciation de chacun. Les ressources archivistiques peuvent alors se rapporter soit à l’entité « générique », soit à l’une de ses « spécialisations ». Chacune des spécialisations portera ses caractéristiques propres (nombre d’employés, siège social, organigramme, etc.). On gagne en finesse de description de l’entité, et en finesse d’indexation des ressources.

Cet article Penser, modéliser (pour le web de données) – 2/2 est apparu en premier sur Sparna Blog.

Pour quoi modélise-t-on ?

La question n’est pas aussi simple qu’il n’y parait, et il y a tout à gagner à mettre à plat dès le début du travail de modélisation la distinction entre :

• un modèle/format de travail;
• un modèle/format d’échange;
• et un modèle conceptuel;

Est-ce que l’on cherche à définir un modèle de travail qui sera utilisé à l’intérieur d’un système logiciel (le schéma des tables de sa base de données, pour faire simple) ? ou bien est-ce qu’on cherche à définir un modèle d’échange qui sera fait pour publier les données à l’extérieur du système logiciel, sur le web de données ? La distinction est empruntée à Bruno Bachimont (dans Ingénierie des connaissances et des contenus : le numérique entre ontologies et documents (Lavoisier, 2007)) :

« Les formats d’échange permettent de rendre lisibles par différentes applications les mêmes données. Les formats de travail permettent à une application d’effectuer tous les traitements nécessaires et de créer les structures à cet effet. »

Ou bien encore, et c’est un peu différent, est-ce que l’on cherche à esquisser un modèle conceptuel du domaine, c’est-à-dire se mettre d’accord sur les principales entités de ce domaine et les relations qu’elles entretiennent entre elles, sans rentrer dans les détails d’implémentation ? FRBR par exemple est un modèle conceptuel, et RDA est une implémentation de FRBR en tant que modèle d’échange; et rien n’implique qu’un logiciel compatible avec ce format d’échange l’utilise effectivement en tant que format de travail; il y a même toutes les chances que non.

La distinction entre ces 3 objectifs est importante car chacun va apporter ses contraintes : par exemple, faire le modèle de travail d’une application implique de prendre en compte des contraintes de facilité de saisie ou de navigation dans les données pour l’utilisateur, ou de traçabilité des informations (quel utilisateur a créé quoi). Faire un modèle de publication pour le web de données amène des contraintes de facilité de compréhension, et de réutilisation du modèle. Faire un modèle de domaine ne demande pas de rentrer dans le détail de chaque propriété et de chaque relation, mais d’être tout à fait clair sur la définition de chaque entité.

Retour d’expérience numéro 1 : déterminer précisément l’objectif du modèle : modèle interne à une application, modèle de publication, ou modèle conceptuel.

« Be real »

Les modèles, les ontologies et tous ces bazars conceptuels ont ce côté rassurant des arrières-mondes que l’on fabrique pour s’échapper du douloureux réel. Tant que l’on reste dans le modèle, tout va bien, mais quand on commence à regarder les données, les vraies données qui existent réellement pour de vrai, ça fait toujours un peu mal : on a oublié de prendre en compte telle colonne dans le fichier de données, telle autre contient du texte alors qu’on avait prévu une référence contrôlée, etc. Pour paraphraser la boutade philosophico-geek « le réel, c’est ce qui fait mal quand on éteint l’ordinateur », on pourrait dire « les données, c’est ce qui fait mal quand on a fini le modèle ». « Reality is broken », par essence.

Non content de faire un modèle avec des boîtes et des flèches, il faut travailler le plus tôt possible dans le processus de modélisation sur les vraies données. Les exemples de données existantes exprimées suivant le modèle conçu doivent faire partie des livrables, autant que le modèle lui-même.

Retour d’expérience numéro 2 : travailler sur des exemples de vraies données, en les exprimant dans le modèle cible.

Modéliser c’est communiquer

Tous les modèles sont imparfaits, on a beau le savoir il faut se le redire sans cesse pour ne pas oublier la réalité que ce modèle tente de capturer. Ce n’est pas la réalité qui est cassée (« reality is broken »), ce sont nos modèles. Ou plutôt, la réalité est cassée parce qu’on en fait des modèles.

Tous les modèles sont imparfaits, car, malgré toutes les précautions que vous aurez prises pour faire émerger une objectivité, celle-ci ne restera finalement que votre vision du monde, la vôtre personnellement, ou celle du groupe de gens qui ont participé à sa mise au point. Eternelle subjectivité. Et c’est précisément parce que votre modèle est subjectif qu’il faut être capable de l’expliciter, de l’expliquer, de le communiquer aux autres. Le modèle doit servir de moyen, de support à la communication de votre vision du domaine métier. Il doit permettre d’instaurer un dialogue. Eternelle inter-subjectivité. Dès lors, il faut s’appliquer à rendre le modèle communicable :

• 99% des modèles OWL que l’on trouve sur le web utilisent des URIs et des libellés en anglais. Mais pourquoi ne pas faire un modèle en français, si on le voit comme un support de communication à destination d’acteurs francophones ? c’est le parti que nous avons pris avec Anaphore. Pensons local avant de penser universel, il sera toujours temps, le jour où le modèle aura un succès international, de le traduire ;
• un fichier d’ontologie OWL ne suffit pas; c’est incompréhensible. Faites des diagrammes, des schémas, dès le début du processus de modélisation, pour vous mettre d’accord et pouvoir parler du modèle. La communication autour du modèle commence dès sa conception ;
• c’est une évidence, mais documentez les classes et les propriétés du modèle, et le modèle lui-même, en suivant les pratiques de bon sens documentées dans le LOV ;
• utilisez les outils de génération automatique de documentation à partir du fichier OWL, comme LODE ou Parrot. Nous avons utilisé LODE pour son rendu propre et la possibilité d’intégrer les images des diagrammes dans la documentation ;
• prévoyez un moyen de recevoir du feedback une fois votre modèle publié; a minima une adresse e-mail, ou une mailing-list, un forum, un formulaire de suggestion, un hashtag, ce que vous voulez, mais permettez qu’un dialogue s’instaure.

Retour d’expérience numéro 3 : penser dès le départ le modèle comme un moyen de communication, autant qu’un moyen de structurer les informations dans un système informatique.

Un arbre plutôt que du marbre

Si vous vous placez dans la perspective de publier un modèle OWL sur le web, il faut envisager cela à la fois, bien sûr, comme l’aboutissement d’un travail de réflexion, mais aussi comme le début d’un processus d’évolution. Ne pensez pas que votre modèle va être figé une fois publié. Si, comme évoqué précédemment, vous avez tenu compte de la réalité des données, et que vous avez prévu les moyens de dialogue et de feedback, alors votre modèle évoluera en tenant compte des évolutions dans l’expression des données et des retours de la communauté. Soyez donc prêt à prendre en compte ces retours, en prévoyant pourquoi pas un mécanisme de versioning, et en établissant clairement le processus de mise à jour; sans faire l’erreur de FOAF qui a incorporé un numéro de version dans son URI, en étant maintenant incapable de la changer sans embêter tous ses utilisateurs !

« …the technical namespace ID [of FOAF] remains fixed and includes the original value of « 0.1 ». It long ago became impractical to update the namespace URI without causing huge disruption to both producers and consumers of FOAF data. We are left with the digits « 0.1 » in our URI. This stands as a warning to all those who might embed metadata in their vocabulary identifiers. »

Bref, pensez à votre modèle comme quelque chose de vivant, un arbre plutôt que quelque chose de figé dans le marbre. Une certaine automatisation dans son processus de publication sur le web peut donc être bienvenue.

Evidemment, si votre modèle est un modèle de travail interne pour une solution logicielle, son évolution est moins aisée, la problématique est différente.

Retour d’expérience numéro 4 : penser à l’évolution du modèle une fois sa mise en ligne, ne pas hésiter à le faire évoluer.

Le second volet de ces quelques réflexions, dont le titre « Penser, modéliser » s’inspire du livre « Penser, classer » de Georges Perec, sera consacré aux motifs de conception (design pattern) utilisés pour construire ce modèle de description des fonds d’archives.

Cet article Penser, modéliser (pour le web de données) (1/2) est apparu en premier sur Sparna Blog.

Cet article Ontologie, Thesaurus et Taxonomie sur le web de données est apparu en premier sur Sparna Blog.