Paired with the CIDOC-CRM in a federated way, OpenArchaeo aims at :

• making available the archaeological datasets produced by the MASAplus consortium’s partners on the semantic web, in the form of a triplestore with data aligned with the ontology and its extensions dedicated to archaeology ;
• providing an intuitive query interface for archaeological data.

The latter query interface integrates the Sparnatural knowledge graph exploration component. The UI of this component was heavily inspired by the British Museum’s ResearchSpace semantic search feature, as the system proposes the user to build his own queries based on the CIDOC-CRM model underlying the data.

About ResearchSpace platform

Initiated in 2009 by a cross-disciplinary team at the British Museum, ResearchSpace is « A full CIDOC-CRM authoring and search system, based on an exhaustive collection of forms that reflects all applicable relationships from the CIDOC CRM ontology. »

Among a wide range of semantic tools to create, manipulate, analyse and visualise data, the platform provides a semantic structured search component based on categories and relations.

While open source, ResearchSpace’s code didn’t fit our architecture : we just chose to follow the simple visual elements of ResearchSpace’s query interface to develop our own Sparnatural query builder for OpenArchaeo, and set up a system of icons to identify the main components of the archaeological data.

ResearchSpace has recently (december 2024) released a brand new 4.0.0 version. This latest can be installed easily and now comes with a default setup of forms based on the CIDOC-CRM. It enables image annotations, knowledge maps creations, semantic narratives writing, timeline productions, and more semantic tools.

Sparnatural’s first use-case was OpenArchaeo’s CIDOC-CRM model !

The structure of the knowledge graph of OpenArchaeo relies on the CIDOC-CRM and some of its extension (CRMarchaeo, CRMsci and CRMba). It is a generic model that covers the basic concepts found in most archaeological corpuses (site, operation, structure, feature, wall, burial, stratigraphic unit and artifact).

Here a focus on Class S19 :

Several external thesauri were added too for querying the datasets : PACTOLS thesaurus for archaelogy, but also Geonames and Periodo for spatial and temporal searches.

This way, when users wish to connect two elements (artifact and site for example), the interface automatically suggests the available relationships between these entities, enabling users to formulate their request in a simple way without having to know either the entities and properties of CIDOC CRM, or the structure of the system : the SPARQL queries that correspond to the sentences visually built by users will be automatically computed. In addition, the usage of thesauri allows the users to cross-reference easily multiple datasets through the different widgets proposed in Sparnatural.

Get the latest release of Sparnatural !

Since it was created for OpenArchaeo in 2019, Sparnatural UI has been fully redesigned. It now offers a large panel of features, from different widgets for value selection (dropdown lists, ordered by occurrence count or alphabetically, autocomplete search fields, date pickers, tree widgets…) to brand new result display plugins : the default visualisation is a table of results, but if the results are geolocalized they can be shown in a map. Also grid, stats, pie or bar charts, and a timeline plugin have been made available and documented.

To go further on OpenArchaeo’s platform …

See a presentation of the project on the CIDOC Museum Documentation Channel
(« Semantic modelling of archaeological data online workshop series »)

The platform : http://openarchaeo.huma-num.fr/

The project : https://masa.hypotheses.org/openarchaeo

Read full research paper about the project : https://ceur-ws.org/Vol-2375/paper1.pdf

Image : Vestiges of a large villa in Courbehaye « les Deux Muids / le Moulin de Mongé », photo Alain Lelong (2003), Atlas des Établissements Ruraux de Beauce Antique, licence CC BY-NC-SA

Cet article The Genesis of Sparnatural in the context of the OpenArchaeo platform est apparu en premier sur Sparna Blog.

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.

• RobotDonnées, le module développé par Logilab pour data.bnf.fr qui permet le regroupement semi-automatique des éditions en œuvres;
  • où l’on apprend que data.bnf.fr ne comporte « que » 300 000 œuvres, alors que la cible théorique serait à plusieurs millions; par exemple on voit bien en regardant les oeuvres dont Michel Houellebecq est auteur dans data.bnf.fr que « La carte et le territoire » n’apparaît pas comme œuvre, mais que toutes les éditions de cet ouvrage sont bien listées quand on regarde tous les documents dont Houellebecq est l’auteur.
  • où l’on apprend également que ce regroupement en œuvre est progressivement réintroduit dans le catalogue général de la BNF;
• BiblioStratus, pour aligner un catalogue externe avec celui de la BNF sur la base de plusieurs heuristiques (ISBN, EAN ou bien titre+auteur+date ou titre+auteur); où l’on apprend que la transition n’est pas qu’écologique mais qu’il existe également une transition bibliographique;
• l’ANR ELKER pour « Enhancing Link Keys: Extraction and Reasoning », porté notamment par l’INRIA Grenoble pour la détection automatique des attributs permettant de trouver des correspondances dans 2 jeux de données RDF arbitraires; très impressionnant;
• CultuurLink, à tester pour tous ceux qui s’intéressent aux processus d’alignement de vocabulaires, bien que l’outil soit restreint aux vocabulaires patrimoniaux des Pays-Bas;
• et encore plein d’autres choses (cf les liens sur la page de l’atelier);

OnAGUI pour aligner 2 thesaurus SKOS

Je voulais profiter de cette thématique des alignements pour parler d’un autre outil d’alignement de thesaurus SKOS : OnAGUI pour « Ontology Alignment Graphical Interface« . OnAGUI est le genre d’outil qui ne paie pas de mine au premier abord mais qui est à mon avis l’outil dont la prise en main est la plus immédiate pour qui veut aligner 2 thesaurus en SKOS, tout en permettant d’outiller le processus depuis l’alignement linguistique automatique jusqu’à la validation manuelle de l’alignement produit.

L’interface d’OnAGUI pour aligner 2 thesaurus

Quelques considérations générales : d’abord l’acronyme parle d’alignement d’ « ontologies », mais pas de panique, ça marche pour des thesaurus en SKOS; surtout pour des thesaurus en SKOS, d’ailleurs. Ensuite, c’est open-source; ça s’installe facilement sur n’importe quel poste équipé de Java, c’est une application « de bureau », qui ne nécessite pas d’infrastructure client-serveur, etc. l’interface est en français (et anglais) puisque le développement à été fait par Laurent Mazuel à l’époque où il travaillait avec Jean Charlet au LIMICS (INSERM). L’outil est maintenu, notamment par votre serviteur.

Vous pouvez consulter la documentation d’OnAGUI où vous trouverez des informations plus détaillées sur le logiciel.

Alignement avec RAMEAU

Maintenant, le cas d’usage : il m’ait arrivé de rencontrer des personnes qui avaient besoin d’aligner un vocabulaire vers le langage d’indexation RAMEAU de la BNF. Comment faire ?

1. Je ne détaille pas ici la structure de RAMEAU et son mécanisme de « vedettes-matières pré-coordonnées » que je ne connais pas bien d’ailleurs, mais je pars (naïvement) de ce qui existe : le fichier des Thèmes Rameau que l’on télécharge depuis le site des dumps de données de la BNF. Il s’agit du fichier intitulé « [RDF/XML] Thèmes RAMEAU« .
2. A ce stade il faut l’avouer : la BNF a encore des efforts à faire sur diffusion des données de RAMEAU; les données telles qu’on les télécharge sont inutilisables telles qu’elles, et nécessitent : 1/ un nettoyage et 2/ une fusion en un seul fichier; je ne m’étends pas sur cette étape que j’ai réalisé à l’aide de scripts RDF4J dont je me sers régulièrement, mais on se ramène au final à un seul fichier RDF contenant tout RAMEAU en SKOS; si vous voulez tester OnAGUI sur un autre vocabulaire ne nécessitant pas cette étape de « magie noire », essayez avec le thesaurus de l’UNESCO ou Eurovoc;
3. Il faut ensuite avoir son propre thesaurus en SKOS; on peut utiliser pour cela l’outil de conversion Excel vers SKOS disponible dans SKOS Play;
4. Il faut télécharger OnAGUI en prenant soin de prendre une version postérieure à 0.3.2, version pour laquelle des améliorations ont été apportées pour fonctionner avec RAMEAU;
5. Muni donc de votre vocabulaire en SKOS d’un côté, de RAMEAU (nettoyé) de l’autre, et d’OnAGUI entre les deux, vous pouvez ensuite :
   1. Charger votre thesaurus dans OnaGUI (Menu « Fichier > Charger vocabulaire 1 > Charger en SKOS »);
   2. Charger RAMEAU dans OnaGUI (Menu « Fichier > Charger vocabulaire 2 > Charger en SKOS »), qui va vaillamment charger 160000+ concepts;
   3. Lancer un alignement linguistique (Menu « Alignement > I-Sub distance ») en prenant soin de :
      1. sélectionner la langue « fr » dans les 2 thesaurus;
      2. abaisser légèrement le seuil de tolérance de l’algorithme, en le mettant à 0.85 par exemple; ne le mettez pas trop bas sinon vous aurez trop de correspondances qui ne veulent rien dire, ni trop haut sinon vous allez rater des choses;
   4. Aller prendre un petit café, ou deux, ou trois… en fonction de la taille du vocabulaire que vous avez besoin d’aligner; patientez entre quelques secondes et une nuit entière;
   5. Analyser le tableau de résultat fourni et soit :
      1. supprimer des lignes de correspondances fausses; regardez le score de chaque correspondance : plus le score tend vers 1, meilleure est la correspondance linguisitique, plus le score diminue, plus les libellés sont éloignés;
      2. ajouter des nouvelles correspondances qui auraient été ratées;
   6. Puis exporter l’alignement (Menu « Fichier > Exporter l’alignemenr ») soit dans un format RDF EDOAL, le plus expressif, soit avec les propriétés d’alignement SKOS, soit en CSV pour une analyse dans un tableur;

Vocabulaire Rameau chargé dans OnaGUI

OnAGUI est un outil perfectible sur bien des aspects mais qui permet de valider « pour de vrai » des alignements sur des vrais projets, sans besoin d’infrastructure compliquée ou d’outil commercial. J’ai pu le mettre en œuvre à 2 reprises : pour l’alignement du thesaurus de l’IRSTEA vers le GEMET et Agrovoc, et plus récemment pour un essai d’alignement du vocabulaire thématique d’indexation de la loi Luxembourgeoise avec le thesaurus Eurovoc utilisé au niveau européen, sur la base de l’analyse des transpositions des directives européennes dans la loi nationale. Il peut également prendre en charger des cas d’usage d’alignement partiel, en alignant seulement les concepts créés ou modifiés après une certaine date, de façon à ne pas à avoir à refaire l’intégralité de l’alignement à chaque nouvelle version du thesaurus.

Si vous avez des questions, des cas d’usage ou des retours d’expérience sur OnAGUI, n’hésitez pas à soumettre des tickets dans le site du projet.

Cet article Aligner son thesaurus avec RAMEAU en utilisant OnAGUI est apparu en premier sur Sparna Blog.

Print thesaurus alignments

The major enhancement recently added is the ability to generate tables to display thesaurus alignments (declared using the mapping properties skos:exactMatch, skos:broadMatch, skos:narrowMatch or skos:relatedMatch). Here is an example of printing a thesaurus alignment in PDF :

This architecture thesaurus from french Ministry of Culture (published in data.culture.fr using GINCO) is aligned with Getty AAT, french DBPedia and Rameau (published in data.bnf.fr). The table is listing source concepts, and for each of them, the mappings to the other thesauri. It is also possible to generate a slightly different output by grouping the mappings by target thesaurus rather than with an alphabetical listing of the source concepts.

Note that this is real Linked Data here : SKOS Play doesn’t simply display the URIs of the target concepts (e.g. http://data.bnf.fr/11936410/abattoirs/), but rather their labels by following the URIs and fetching the labels dynamically. This can obviously take a long time if the alignement is large. Of course, each target concept label is clickable so that you can navigate to the corresponding page.

Print OWL files, too !

In some cases, people working on large ontologies with lots of classes (e.g. medical ontologies, like HRDO with > 13000 classes) also have a need to print them, much like people working on thesauri. This is why SKOS Play now includes an option to convert an OWL class hierarchy to SKOS, to be able to print it. Of course by doing so we lose the rest of the ontology structure; here is exactly what this conversion does :

• the OWL Ontology becomes a SKOS concept scheme;
• every OWL class becomes a SKOS concept, and is declared « skos:inScheme » of the generated concept scheme;
• the rdfs:subClassOf links yields skos:narrower and skos:broader relations;
• rdfs:labels on OWL classes generate skos:prefLabel;

While this remains pretty basic, it gives a nice a easy path to use SKOS Play to display OWL classes hierarchies.

Use data expressed using SKOS-XL

SKOS comes with the optional extension SKOS-XL, that allows to declare the labels themselves as separate resources. Until now SKOS Play was not compatible with this extension. It is now the case, with an additionnal option (activated by default) that will apply simple inference rules to regenerate internally plain SKOS labels (pref, alt or hidden) from their SKOS-XL equivalent.

Generate autocomplete field with the thesaurus terms

A  typical usage of a thesaurus in a search system is to guide the user typing queries in an input field. While this functionnaly is usually achieved using search engines autocomplete features (see SolR suggester), it is sometimes desirable to be able to do the same entirely on the client side when no search engine is available. And this is what SKOS Play does :

1. You see a page with an input field saying « search 1234 terms in thesaurus Y » :

2. When you start typing, you get suggestions from the thesaurus, with definition and scope note displayed for each of them :

3. When clicking on a suggested term, the corresponding concept URI is selected and can be sent to a search index to fetch resources indexed on that concept.

This is implemented using JQuery UI autocomplete widget and everything is on the client side – no server required ! the page can be saved locally and adapted to an existing search portal. The terms fueling the completion list are written in JSON in the page :

{
    "uri" : "http://skos.um.es/unescothes/C00007",
    "label" : "Abstract journals",
    "pref" : "Abstracts",
    "type" : "alt"
  }, {
    "uri" : "http://skos.um.es/unescothes/C03290",
    "label" : "Abstract reasoning",
    "pref" : "Reasoning",
    "type" : "alt"
  }, {
    "uri" : "http://skos.um.es/unescothes/C00007",
    "label" : "Abstracts",
    "scopeNote" : "The usually non-critical indication of the subject contents of a document, aiming to permit the user a decision about the relevance of the document.",
    "type" : "pref"
  }

Generate professional-looking PDF documents for your thesauri

SKOS Play is used by french Ministry of Culture to generate professional-looking PDF documents, in their effort to structure, align and publish controlled vocabularies on http://data.culture.fr/thesaurus/ (using GINCO and GINCO Diffusion). SKOS Play was used to generate the final PDF rendering of the « Thesaurus de la désignation des oeuvres architecturales et des espaces aménagés » and the « Thesaurus de la désignation des objets mobiliers« .

These PDFs include :

• an alphabetical index containing for each term :
  • the corresponding preferred term, if the term is non-preferred;
  • if the term is a preferred term :
    • its broader, narrowers, related and top term (clickable to navigate in the PDF);
    • a scope note and a definition (if available);
• a hierarchical display, with each entry being clickable to navigate to the alphabetical index;
• translation tables, when the thesaurus is multilingual;

An effort as been made on the page layout and design to achieve optimal readability.

Generate permuted indexes (KWIC)

SKOS Play also allows you to generate permuted indexes from the labels of the thesaurus :

This can be used to easily search a term in the thesaurus, or check in which label a given word appear. Note that the computed permutations are correctly excluding stopwords based on the chosen language.

As usual, the output is available in HTML or PDF.

More to come in 2015 !

Probably new enhancements will come in 2015 :

• display images associated with each concepts, if they are available;
• handle right-to-left languages (arabic);

and more, based on your feedback, most welcomed as usual !

Cet article SKOS Play : alignments, SKOS-XL, autocomplete search fields, and more ! 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.

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

J’espère que cette traduction pourra favoriser d’une part la migration des systèmes d’organisation des connaissances existants vers les mécanismes de publication et de partage du web sémantique, et d’autre part la réutilisation des systèmes d’organisation déjà publiés, ou les alignements entre SOC existants.

Les commentaires et les retours sur cette traduction sont les bienvenus.

Voici quelques-uns des choix faits pendant cette traduction :

Cet article Traduction française de SKOS est apparu en premier sur Sparna Blog.

Première Impression…

Première impression à l’installation : la procédure d’installation, certes documentée (seulement en anglais, dommage pour un projet qui sort du ministère de la culture français !),  n’est pas à la portée de tout le monde. Si les mots WAR, JDBC, LDAP ou les outils comme Tomcat ou Postgresql ne vous disent rien, vous allez avoir du mal à faire fonctionner l’application. Le MCC propose également une machine virtuelle préconfigurée avec l’application déjà installée permettant de la tester plus facilement.

Deuxième impression…

Deuxième impression, à l’usage cette fois-ci : hou là, mais il y a beaucoup de boutons ! et c’est tant mieux !

On dispose en effet dans GINCO de fonctionnalités de base aussi bien que des fonctionnalités avancées que l’on attend d’un TMS (Thesaurus Management System). C’est une vraie application de gestion. L’ergonomie à base d’onglets est déroutante, mais c’est le prix à payer pour avoir les objets qu’on manipule sous la main (un utilisateur d’Eclipse ne sera pas dépaysé).

Ce que je range dans les fonctionnalités de base et sur lesquelles je passe rapidement : la création de concepts, leurs organisation en arborescence générique-spécifique, la gestion des top concepts, des termes associés, du multilinguisme, des notes sur les concepts, l’affichage de l’arbre hiérarchique des concepts, la gestion des groupes de concepts.

Parmi les fonctionnalités avancées, je retiens :

• La séparation Concepts / Termes : les valeurs lexicales (termes) sont distinctes des entrées de vocabulaires à proprement parler (concepts), conformément à l’ISO-25964 sur laquelle GINCO s’appuie. Chaque concept est lié à un ou plusieurs termes, dont au moins un comme terme préférentiel. Cela permet de gérer un certain nombre d’informations au niveau de la valeur lexicale, comme la source ou le statut de validation;
• La possibilité d’ajouter des attributs personnalisés sur les concepts et sur les termes (dommage que ces attributs n’apparaissent pas dans les exports SKOS comme des propriétés RDF additionnelles, et dommage que ce ne soient que des champs texte et pas des liens vers d’autres concepts);
• La gestion des statuts de validation (candidat, validé, rejeté, déprécié, etc…) sur les concepts et les termes (d’ailleurs parfois un peu pénible car il faut penser à valider les termes et les concepts avant de pouvoir les utiliser);
• La gestion d’un historique de modification (piste d’audit) sur les vocabulaires que l’on peut exporter en CSV;
• La gestion des concepts complexes (regroupement de plusieurs autres concepts);
• La gestion des tableaux de concepts (Thesaurus Array de l’ISO 25964) permettant d’implémenter le mécanisme de facettes dans un thesaurus;
• La gestion du marquage des versions sur les vocabulaires (mais pas moyen a priori de revenir à une version précédente);

Troisième impression…

Troisième impression, une fois testée toutes les fonctions d’édition : les exports. 2 formats d’export sont proposés, l’un dans un format XML propriétaire permettant de capturer toute la richesse des données, l’autre en SKOS. Pas d’export dans le format XML de l’ISO 25964. Le SKOS exporté est tout à fait propre et rentre bien dans SKOS Play pour générer un PDF ou un index alphabétique du thesaurus. Ce qui fait de GINCO une solution open-source très pointue, d’un niveau professionnel, pour éditer/créer du SKOS (plusieurs crans au-dessus d’un ThManager ou d’un TemaTres par exemple). En rentrant dans le détail je n’ai malgré tout pas réussi à exporter de Collection SKOS.

Et pour finir…

Si je peux me permettre une liste de souhaits sur les évolutions futures, en vrac :

• La possibilité de chercher des concepts sur certains critères, notamment le statut (pouvoir avoir la liste de tous les concepts/termes en statut « Candidat » pour les valider). Par ailleurs je n’ai jamais rien réussi à trouver dans la boite de recherche en haut, j’ai peut-être raté quelque chose dans la configuration…
• La possibilité d’exporter dans le SKOS les attributs personnalisés et la possibilité de créer des attributs personnalisés qui soient des liens vers d’autres concepts ou d’autres termes;
• La possibilité de traduire l’interface dans d’autres langues, prioritairement en anglais;
• L’export des Groupes dans le SKOS en tant que skos:Collection (pas moyen de les avoir dans l’export);
• La possibilité de désactiver la gestion des statuts sur un vocabulaire pour ne pas avoir systématiquement à valider tout ce qu’on créé;
• La publication des concepts et des termes sur une plate-forme Linked Data;
• Eventuellement un export en SKOS-XL pour conserver la finesse de description des termes.

En tous cas GINCO est un outil à suivre pour la gestion de thesaurus SKOS. S’il vous intéresse pour un projet impliquant des vocabulaires contrôlés, je peux peut-être vous aider, n’hésitez pas à me contacter.

Cet article Ginco – Un éditeur SKOS Open Source est apparu en premier sur Sparna Blog.

I have received some feedback during summer, and I thank everyone that took the time to write and share ideas or report problems. This new version (0.40) brings the following new features and enhancements :

• 2 new visualisations :
  • concept listing : lists all the concepts with all their attributes in a given language; this is close to the existing « alphabetical index expanded », but while the « alphabetical index » view is label-oriented (each label is an entry in the list), this one is concept-oriented (each concept is an entry in the list);
  • language correspondence table : generates a 2-columns table with the translation of each concept in a target language; this allows to review thesaurus translations, and immediately see which concept is missing a prefLabel in a target language;
• complete re-engineering of the internal « display data model », allowing to easily add new visualisations in the future;
• included the Reegle Thesaurus for clean energy as a thesaurus example;
• added the ability to read SKOS data encoded in RDFa attributes within an HTML page (using the semargl library) (but I am still looking for a good example of this);
• enhanced header generation : header now tries to read a dcterms:description or dc:description to include in the header; the concept scheme title is read from skos:prefLabel, dc:title or rdfs:label;
• enhanced « section » generation in PDF documents : each section now generates a page break;

Finally, last but not least, you can install a local version of SKOS Play to work around the 5000 concepts limit on the online server. This is as easy as 1,2,3 (a simple war to deploy on Tomcat) and I wrote a simple procedure on how to deploy SKOS Play on Tomcat. Note that I do not garantee that the online version of SKOS Play be always available in the future; hosting and maintaining this free application has a cost; time will tell how the project evolves.

I hope to write more about the application, especially about data integration of the LOV taxonomy, _not_ expressed in SKOS, but that you can still feed to SKOS Play – with some tricks ! – or about how can Linked Data be leveraged to read thesaurus alignments (by the way, don’t forget you can always click a label on the HTML visualizations to navigate the concept URI). More on that in the future. If you like SKOS Play, use it, show it, share it !

Cet article New version of SKOS Play for taxonomy visualization est apparu en premier sur Sparna Blog.