Thes’Envir, un nouveau thesaurus dans le domaine de l’environnement

Thes’envir est un nouveau thesaurus dans le domaine  de l’environnement, publié par le réseau LIEN (Lieux d’informations sur l’environnement et la nature) Languedoc-Roussillon, qui regroupe 14 structures documentaires.

Il est structuré en 18 champ sémantiques regroupant pas moins de 12000 termes (descripteurs et synonymes) :
Administration – Droit – Gestion,
Agriculture, 
Aménagement – Transport, 
Animaux, 
Atlas,
Culture – Loisirs – Patrimoines, 
Droit de l’environnement,
Ecologie,
Economie,
Education – Formation,
Energie,
Pollutions – Nuisances,
Sciences Humaines,
Sciences
Sciences de la Terre,
Sciences de la Vie,
TIC,
Végétaux.

Il est disponible en version informatique, au format XML (non normalisé) et en version « papier » avec une liste alphabétique structurée et une liste hiérarchique. La liste permutée sera éditée d’ici la fin de l’année 2009.

Pour en savoir plus : http://grainelr.org et http://www.grainelr.org/UserFiles/File/Extraits%20THES%20ENVIR%20alleges.pdf

BibNum

http://www.bibnum.education.fr
Un bel exemple de bibliothèque numérique, dédiée à l’histoire des sciences, a été initié par le CERIMES (Centre de ressources et d’information multimedia pour l’enseignement supérieur), et développé par Smile

Les textes proposés sont en langue française ou des traductions françaises de textes originaux publiés dans une autre langue, courts -25 à 30 pages-, et par conséquent le plus souvent des articles de revues scientifiques.

Le site, créé avec Drupal, s’appuie sur iPaper, visionneuse de Scribd, dont le principe consiste à uploader les fichiers doc, pdf ou autre pour les transformer dans un format Flash, et par un principe de widget, insérer sur son site web le code permettant d’y donner accès dans la visionneuse. (Le principe est en fait identique à celui de YouTube pour les videos)

Le public est invité à transmettre ses suggestions de texte à intégrer à la bbliothèque, en se portant ou non volontaire pour en fournir une analyse.

Fonctionnellement, le site est riche, car il propose

• les fonctions de lecture associées à iPaper : zoom, vue plein écran, vue mosaïque
• analyse du texte
• éléments bibliographiques : ouvrages critiques complémentaires
• récupération des analyses et des textes au format pdf
• les codes à utiliser pour « embarquer » le texte BibNum dans votre site web

Toutefois manquent dans la visionneuse les fonctions pourtant prévues par iPaper de sélection de texte et de recherche, que j’ai testées sur quelques textes et qui semblent ne pas êtres actives…. Bien dommage ! Tout en précisant que le site propose lui même ses propres outils de recherche à l’intérieur des textes.

Pour aller plus loin sur CMIS

A la suite des deux billets de présentation de CMIS 0.5, je me dois d’orienter les lectures d’approfondissement non seulement vers le standard lui-même mais également vers les pages du comité technique OASIS  (Organization for the Advancement of Structured Information Standards)- CMIS :

http://xml.coverpages.org/cmis.html : extrêmement riche en liens vers de nombreuses ressources

Bonne lecture !

Page officielle du comité technique OASIS en charge de la validaiton de la version0.5 : http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis

http://wiki.oasis-open.org/cmis : wiki mis en place par le comité technique OASIS

Motbis 2009

Une nouvelle version de Mot bis est en ligne sur http://www.motbis.fr

D’après le communiqué : « A noter pour cette nouvelle version : la prise en compte de la polyhiérarchie, le développement des thématiques comme l¹enseignement à distance, le handicap. »

A voir …

CMIS, ou l’interopérabilité dans la sphère de l’ECM

EMC (Documentum), Microsoft (Sharepoint) et IBM (Filenet) ont publié conjointement en septembre 2008 un standard pour assurer l’intéropérabilité de systèmes de gestion de contenu d’entreprise : CMIS ou Content Management Interoperability Services.
La mise en place de CMIS au niveau des progiciels nécessite l’ajout d’un connecteur basé sur des Web Services SOAP ou bein sur le protocole REST/ATOM. Aucune réécriture du code, donc.

Le langage exploité par CMIS, CMIS Query Language, s’inspire de SQL-92 grammar (ISO/IEC 9075: 1992 – Database Language SQL) et de sa syntaxe. Il permet de réaliser des jointures entre tables, des sélections de données de type « select» et des recherches plein-texte

Le standard complet dans sa version 0.5 est disponible en téléchargement :

• EMC : https://community.emc.com/docs/DOC-1605
• Microsoft : http://www.microsoft.com/sharepoint/capabilities/ecm/cmis.mspx
• IBM : http://www-01.ibm.com/software/data/content-management/cm-interoperablity-services.html
• Alfresco : http://www.alfresco.com/about/cmis/cmis-draft-v0.5.zip

Voici ce que contient le dossier du standard :

CMIS (1)

CMIS (2)

CMIS est composé de plusieurs parties :

• Partie 1 [Domain model V0.5] : Introduction, General Concepts, Data Model, and Services
• Partie 2 [REST-ATOM binding] : REST protocol binding
• Partie 2 (suite) [Web services binding]: SOAP protocol binding

Généralités

• CMIS définit 4 principales natures d’objets existant dans un entrepôt (référentiel) de contenu (le repository) : Document, Folder , Relationship et Policy.
• Pour chaque nature d’objet on peut déclarer et définir des types supplémentaires ou « Object Type ».
• Chaque nature d’objet accepte un ensemble de propriétés, dont les valeurs sont fixées pour chaque objet du repository ex. Identifiant, URI, Nom etc

Les « CMIS services » fournis en plus du modèles de données permettent notamment de

• naviguer et parcourir l’arborescence des dossiers de l’entrepôt
• créer, lire, mettre à jour et supprimer des objets
• créer une nouvelle version d’un document et retracer l’historiques des versions successives

CMIS spécifie également des correspondances avec SOAP et REST/ATOM pour la mise en place de connecteurs

Repository

Un repository peut gérer un certain nombre de fonctions. Le service getRepositoryInfo renvoie la liste des fonctions prises en charge. Les fonctions concernées sont

• Multi-filing : rattachement d’un document à plusieurs dossiers
• Unfiling : autoriser le non-rattachement d’un document
• Version-specific filing : gérer le rattachement de chaque version d’un document à un dossier éventuellement différent
• PWC updatable : autoriser la mise à jour des copies de travail privées
• All versions searchable : gérer la recherche soit sur la dernière version des documents uniquement soit sur toutes
• PWC searchable : possibilité d’inclure les copies privées dans le champ balayé par les requêtes
• enumCapabilityQuery : gestion des requêtes soit en texte intégral uniquement, soit sur les métadonnées uniquement, soit sur les deux, soit pas de gestion de requêtes
• Join support level in query : niveau de prise en charge des jointures (inner join, outer join…)
• Full-text search support level in query : degré de prise en charge du texte intégral dans les requêtes (WHERE)

Objets

Documents

Les documents représentent des unités de contenu à l’intérieur de l’entrepôt.

Un document peut inclure ou non un flux de contenu, ou » content stream », et cela doit être précisé dans les définitions des objets de type Document (voir « types d’objets » ci dessous).

Les documents peuvent être versionnés.

Folder objects (répertoires ou dossiers)

Les répertoires ou dossiers sont les contenants dans lesquels des documents (ou d’autres répertoires) peuvent être déposés. Un document peut être déposé dans un ou plusieurs répertoires. A l’instar des documents les Folder objects sont interrogeables.

Il y a une relation hiérarchique implicite entre un dossier et les objets qu’il contient, avec comme contraintes d’intégrité de cette relation sa réciprocité, et l’interdiction de créer des boucles (un objet de type répertoire ne peut pas être à lui même son propre père). La suppression d’un élément de la collection associée au répertoire doit également détruire le lien hiérarchique implicite qui le rattachait à un dossier parent.

Une propriété AllowedChildObjectTypeIDs permet de définir quels sont les types d’objets autorisés comme « enfants » de chaque Folder object.
Le service removeObjectFromFolder permet de supprimer le lien père-fils entre un « Folder object » et un objet d’un autre type déclaré être son fils.

Tout répertoire a un et un seul élément père, sauf les repertoires situés à la racine du système, qui n’ont pas d’élément père.

Un répertoire racine ne peut être créé, supprimé ou déplacé via des CMIS services.

Tout nouveau répertoire créé doit se voir déclarer un « Folder object » parent, par le service addObjectToFolder.
Il est impossible de supprimer un « Folder object » dès lors qu’un objet au moins lui est associé.
Il n’est pas obligatoire en revanche d’attribuer aux autres types d’objets un « Folder object » parent.

Deux modes de fonctionnement distincts peuvent être choisis pour un entrepôt :

ou bien l’attribution d’un répertoire à un document est unique pour toutes les versions du document (version-independent : elles sont toutes stockées dans un même repertoire), ou bien elle est décidé pour chacune des versions du document (version-specific : chaque version d’un document peut être placée dans un répertoire indépendamment de ce qui a été décidée pour les versions antérieures de ce document .)

Relationships (relations)

Les relations désignent des relations très lâches entre deux 2 objets (documents ou répertoires) dans l’entrepôt. Elles peuvent avoir comme objet source ou comme objet cible des Documents, des Folders, et, selon les repositories, éventuellement des Policies.

Etablir une relation entre deux objets n’a aucune incidence sur eux. Par exemple cela n’entraîne pas un changement de version, ni de date de dernière modification. L’objet cible de la relation n’hérite pas des contraintes ni des comportements de l’objet source.

Il est autorisé de créer une relation avec le même objet comme cible et comm source de la relation.

Policy objects (Règles)

Ils gèrent les règles d’administration qui sont appliquées aux objets.

L’entrepôt CMIS peut supporter des objets de type Policy object mais cela n’est pas obligatoire. Un objet peut être soumis à une ou plusieurs règles.

Types d’objets

Les 4 objets principaux décrit ci-dessous acceptent d’être déclinés en types : types de documents, types de relations etc.

La définition de chaque type d’objet est constituée des informations suivantes

• ObjectTypeId : ID du type d’objet
• ObjectTypeQueryName
• ObjectTypeDisplay : libellé du type d’objet pour l’affichage
• NameParentTypeId :
• RootTypeQueryName
• Description
• Creatable
• Queryable
• Controllable
• includeInSuperTypeQuery

Pour définir des types d’objets Document on inclut également

• Boolean
• Fileable
• ContentStreamAllowed

Pour définir des types d’objets Relationship on inclut également

• AllowedSourceTypes
• AllowedTargetTypes

Propriétés des objets

Les propriétés peuvent être mono- ou multi-valuées. Les types de données sont basés sur XML Schema Part 2: Datatypes Second Edition (28/10/2004) :

• String (xsd:string)
• Decimal (xsd:decimal)
• Integer (xsd:integer)
• Boolean (xsd:boolean)
• DateTime (xsd:dateTime)
• URI (xsd:anyURI)

Les quatres objets définis ci-dessus (Document, Folder, Relation et Policy) ont en commun les propriétés suivantes

• ObjectId (ID)
• Uri (URI)
• ObjectTypeId (ID)
• CreatedBy (string)
• CreationDate (DateTime)
• LastModifiedBy (string)
• LastModificationDate (DateTime)
• ChangeToken (string)

Les propriétés d’un document sont

• Name (string)
• IsImmutable (boolean)
• IsLatestVersion (boolean)
• IsLatestVersion (boolean)
• IsLatestMajorVersion (boolean)
• VersionLabel (string)
• VersionSeriesId (ID)
• IsVersionSeriesCheckedOut (boolean)
• VersionSeriesCheckedOutBy (string)
• VersionSeriesCheckedOutId (id)
• CheckinComment (string)
• ContentStreamAllowed (string)
• ContentStreamLength (integer)
• ContentStreamMimeType (string)
• ContentStreamFile name (string)
• ContentStreamUri (URI)

Les propriétés d’un dossier sont :

• Name (string)
• ParentID (ID)
• AllowedChildObject TypeIds (ID)

Les propriétés d’une relation sont exclusivement :

• sourceId (ID)
• targetId (ID)

Les propriétés pour les règles sont :

• Policy name (string
• Policy text (string)

Il est possible, pour n’importe lesquels des 4 types d’objets prévus, de créer des types d’objets supplémentaires qui spécifient le schéma des propriétés autorisées ou requises pour les objets.

Les CMIS services

CMIS fournit des services CRUD (Create, Retrieve, Update, Delete) applicables aux objets.

Repository services

• getRepositories : retourne URI, noms et IDs des repositories disponibles
• getRepositoryInfo : retourne des informations détaillées sur un repository : ID, nom, URI, description, ID du dossier racine, nom et version du produit, versions supportées de CMIS, propriétés spéicfiques du repositoriy ex: gestion du multifiling, repositories liés
• getTypes retourne tous les types d’objets du repository et leurs attributs
• getTypeDefinition : retourne des propriétés détaillées d’un type d’objet déterminé
• getAllowableActions : retourne les actions autorisées à l’utilisateur sur un objet ex. le supprimer, modifier ses propriétés, le changer de dossier etc.
• getProperties : retourne les propriétés de l’objet et éventuellement les actions autorisées à l’utilisateur sur cet objet
• getContentStream : retourne le flux de conteu du document

Navigation service

• getDescendants : retourne la liste des objets de l’arborescence à partir d’un dossier déterminé, sur un ou plusieurs niveaux. Il est possible de ne demander que les objets d’un type particulier
• getChildren : retourne les éléments situés au premier niveau sous le dossier spécifié. Si toutes les versions d’un même document sont sous un même dossier, seule la version la plus récente est renvoyée
• getFolderParent : retourne l’ID et les propriétés du ou des dossier(s) parent(s) de l’objet de type Folder spécifié
• getObjectParents : retourne l’ID et les propriétés du ou des dossier(s) parent(s) de l’objet non- Folder spécifié
• getCheckedoutDocuments : retourne les objets de type Documents validés auxquels l’utilisateur à accès (en général ceux qu’il a lui-même validés)

Object service

• createDocument : crée un objet Document du type spécifié, et éventuellement lui attribue un dossier parent
• createFolder : crée un objet de type Folder du type spécifié
• createRelationship : crée une relation d’un type déterminé entre deux objets
• createPolicy : crée un objet Policy du type spécifié, et éventuellement lui attribue un dossier parent
• updateProperties : permet de mettre à jour les propriétés de l’objet spécifié (dans CMIS 1.0 pour une propriété multivaluée il faut mettre à jour toute la liste de valeurs)
• moveObject : permet de déplacer l’objet spécifié d’un dossier à un autre
• deleteObject : permet de supprimer l’objet spécifié
• deleteTree : permet de supprimer une arborescnce à partir du point (dossier) spécifié inclu.
• setContentStream : crée ou remplace le flux de contenu associé à l’objet Document spécifié
• deleteContentStream : supprime le flux de contenu associé à l’objet Document spécifié

Multifiling service

(valable uniquement pour les repositories qui acceptent le multifiling)

• addObjectToFolder : placer l’objet spécifié sous un dossier
• removeObjectFromFolder : enlver l’objet spécifié d’un ou de tous les dossiers dans lesquels il est placé

Policy service

• applyPolicy : applique une règle à l’objet spécifié
• removePolicy : annule l’application d’une règle à l’objet spécifié
• getAppliedPolicies : Retourne la liste des objets Policy appliqués à l’objet spécifié

Relationship service

• getRelationships : retourne la liste des relations de l’objet spécifié, eventuellement restreintes à celles d’un type particulier ou établie dans une direction précise (source/cible)

Versioning service

• checkOut :
• checkIn : fait de la copie privée la version courante du document
• getPropertiesOfLatestVersion : retourne les propriétés de la dernière version dans la série spécifiée
• getAllVersions : retourne la liste de toutes les versions de la série sépcifiée, triée par ordre décroissant de date de création
• deleteAllVersions : supprime toutes les versions de la série spécifiée

Quelques videocasts sur CMIS

Voici quelques videocasts trouvés sur internet autour de CMIS (Content Management Interoperability Standard)

NF Z42-013 révisée

La norme NF Z42-013 « Archivage électronique – Spécifications relatives à la conception et à l’exploitation de systèmes informatiques en vue d’assurer la conservation et l’intégrité des documents stockés dans ces systèmes » révisée a été homologuée par le Ministère de l’Industrie le 3 février 2009 . Elle est désormais publiée par l’AFNOR (datée de mars 2009) et disponible au prix de… 72,25 €.

Notice détaillée sur la boutique AFNOR

l’Aproged organisera de sessions de formation à l’occasion de cette révision. Le tarif est de 950,00 Euros H.T. (soit 1136,20 Euros T.T.C.) par personne incluant un exemplaire de la norme révisée  (prochaines sessions les 12/03, 09/04 et 14/05/2009)

A lire également sur le site de l’APROGED :  » Economie numérique : l’authenticité des documents numériques a enfin sa norme »

A suivre : le projet de norme ISO s’appuyant les recommandations de la norme française…

Petite bibliographie francophone des ontologies

La littérature francophone autour des ontologies n’est pas abondante, et les articles cités ci-dessous commencent même pour beaucoup d’entre eux à être relativement anciens…

ce billet pourra être enrichi régulièrement, les références sont loin d’être exhaustives…

Les ontologies : Antécédents, aspects techniques et limites. In : Documentaliste Sciences de l’information, vol.44-1, p. 82-85, février 2007 : Langages documentaires et outils linguistiques. 2e partie. Normes, standards et interopérabilité

Actes de l’atelier « Ontologies et Textes » - OntoTexte 2007 Sophia Antipolis, 10 octobre 2007

Qu’est ce qu’une ontologie ? Eliane Consola, journaldunet.com, 03/04/2007

Qu’est-ce qu’une ontologie ? Entretien avec Bruno Bachimont publié par technolangue.net., 3 juillet 2006

La Création d’Ontologies Web Sémantique avec Protégé-2000. http://www.cetic.be [s.d.]

Développement d’une ontologie 101 : Guide pour la création de votre première ontologie. Natalya F. Noy et Deborah L. McGuinness. Traduit de l’anglais par Anila Angjeli, BnF, Bureau de normalisation documentaire.

De l’index nominum à l’ontologie : Comment mettre en lumière les réseaux sociaux dans les corpus historiques numériques ? Gautier Poupeau , 2006

Engagement sémantique et engagement ontologique : conception et réalisation d’ontologies en Ingénierie des connaissances. Bruno Bachimont

Ontologies pour le Web sémantique. Jean Charlet, Bruno Bachimont, Raphaël Troncy. In : Information – Interaction – Intelligence Hors Série 2004.

Web Sémantique et Informatique Linguistique : propositions méthodologiques et réalisation d’une plateforme logicielle. Florence Amardeilh, mai 2007

Ontologies informatiques : Interstices (http://interstices.info). Fabien Gandon

Introduction à OWL, un langage XML d’ontologies Web. Xavier Lacot, juin 2005

Génération d’ontologie à partir d’un modèle métier UML annoté. Cyril Faucher, Frédéric Bertrand et Jean-Yves Lafaye

SKOS (2008) dans les grandes lignes

SKOS, une ontologie des systèmes de représentation des connaissances

Skos est un modèle de données défini en OWL-Full et permettant de gérer différents types de vocabulaires contrôlés, tels que thesaurus bien sûr mais également listes d’autorités, schémas classificatoires, ou encore taxonomies.

Le modèle de données SKOS a été conçu comme une ontologie OWL-Full en soi. Il est donc constitué de classes et de propriétés. Il convient donc de souligner que SKOS n’est en aucun cas en lui même un langage formel de représentation des connaissances, mais l’expression dans un tel langage, du modèle de données adapté au traitement des vocabulaires contrôlés.

SKOS n’a pas pour vocation l’expression d’axiomes et de faits, mais de concepts et de réseaux de liens conceptuels et sémantiques.

Il sera toujours possible en revanche de partir d’un thesaurus et de s ‘appuyer sur les concepts qu’il contient pour déterminer les classes, propriétés et individus d’une ontologie, et d’utiliser comme point de départ les relations hiérarchiques et associatives pour créer des axiomes et des faits

Les documents du standard

Version courante

La nouvelle version en date de 2008 se compose des documents suivants

• SKOS Primer, W3C Working Draft 21 February 2008. Antoine Isaac and Ed Summers : document orienté « utilisateur », prévue pour une première approche
• SKOS Reference, W3C Working Draft 29 August 2008. Alistair Miles and Sean Bechhofer : document contenant la version complète et normative de SKOS
• SKOS use cases and requirements, W3C Working Draft 21 February 2008. Antoine Isaac and Ed Summers : document de travail préparatoire pour la mise à jour de 2008
• SKOS eXtension for Labels (XL). « Last call » edition 22 August 2008. Alistair Miles and Sean Bechhofer : Extension XL de SKOS

Versions antérieures

• SKOS Core guide, 2nd W3C Public Working Draft 2 November 2005. Alistair Miles and Dan Brickley
• SKOS Core Vocabulary Specification, 2nd W3C Public Working Draft 2 November 2005. Alistair Miles and Dan Brickley
• Quick Guide to Publishing a Thesaurus on the Semantic Web, W3C Working Draft 17 May 2005. Alistair Miles

Triplets

Qui dit RDF dit triplets.

Les définitions des classes et des propriétés des classes, ainsi que les conditions d’intégrité décrites dans SKOS Reference sont des triplets RDF, même si le document les explicite dans la prose du langage naturel.

Un Uniform Resource Identifier (URI) est attribué à chaque et à chaque propriété SKOS.

Classes

• skos:Concept
• skos:ConceptScheme
• skos:Collection
• skos:OrderedCollection

Le modèle de données SKOS considère les systèmes d’organisation des connaissances (KOS) comme des schémas conceptuels (skos:ConceptScheme) incluant des grappes de concepts (skos:Concept). Chaque concept est identifié par une URI.

Chaque concept est donc associé à un voire plusieurs schémas conceptuels.

A l’intérieur d’un schéma conceptuel, des groupes de concepts peuvent être assemblés en collections (skos:Collection). Ainsi l’on peut désigner, c’est-à-dire nommer, une collection de concepts partageant des caractéristiques communes par la propriété skos:member.

On retrouve ainsi l’équivalent des relais virtuels.

Une collection de concepts peut éventuellement être imbriquée à l’intérieur d’une autre : une collection peut inclure parmi ses membres des concepts et/ou des collections.

Aucune relation sémantique ne peut être établie entre un concept et une collection. En d’autres termes il est interdit d’attribuer des relations TG-TS ou encore TA à une collection. Autrement dit le fait d’assembler des concepts en collection ne donne aucune indication en soi quant à leur emplacement dans le schéma conceptuel, et il faut attacher explicitement chaque concept de la collection à son concept générique par la relation skos:broader.

En revanche les concepts inclus dans une collection peuvent avoir une relation hiérarchique de type skos:broader vers un autre concept.

Ces collections peuvent être ordonnées (skos:orderedCollection), ce qui signifie que l’ordre des membres de la collection est significatif. Dans ce cas les membres sont associés à la collection par la propriété skos:memberList.

Il n’est pas obligatoire d’attribuer une URI à une collection.
Une forme lexicale peut être attribuée à une collection en utilisant la propriété skos:prefLabel, qui peut s’appliquer à des concepts mais également à des ressources non conceptuelles.

Propriétés

Organisation du schéma conceptuel

• skos:inScheme
  
• skos:member
• skos:memberList
• skos:hasTopConcept
• skos:topConceptOf

Nous avons vu dans la section précédente qu’un concept est rattaché à un schéma conceptuel par la propriété skos:inScheme.

La propriété skos:member permet d’intégrer un concept à une collection, et skos:memberList permet d’intégrer un concept à une collection ordonnée.

La propriété skos:hasTopConceptpermet de lister l’ensemble des concepts situés au niveau le plus haut du schéma. La propriété inverse skos:topConceptOf définit que le concept est situé au premier niveau du schéma et ne se verra attribuer aucune relation de type skos:broader.

Attention : le fait qu’une relation sémantique soit établie entre deux concepts n’implique pas pour autant que ces deux concepts appartiennent obligatoirement au même schéma. par exemple « <A> skos:narrower <B> » + « <A> inScheme <MyThesaurus> » n’autorise pas d’inférer que « <B> inScheme <MyThesaurus> »

Termes

• skos:altLabel
• skos:hiddenLabel
• skos:prefLabel
• skos:notation

Chaque concept peut être désigné par un nombre indéterminé de termes (chaînes lexicales UNICODE) dans n’importe quel langage naturel.

Pour chaque langue on retient un et un seul « label » (forme lexicale ou libellé) préférentiel (skos:prefLabel), les équivalents intralinguistiques étant traités comme libellés « alternatifs » (skos:altLabel).

Il n’est pas possible avec SKOS de créer des relations entre les différentes formes lexicales. Il existe uniquement des relations implicites entre les formes lexicales pointant vers un même concept.
L’extension SKOS XL a été conçue pour permettre de gérer des relations entre les formes lexicales. Elle recommande même d’être précis dans ces relations et de les typer. Par exemple on peut déclarer : ex:isAcronymOf rdfs:subPropertyOf skos-xl:labelRelation

Les libellés « cachés » servent à gérer les variantes ou erreurs d’orthographe, que les moteurs de recherche pourront ainsi traiter, sans qu’elles soient montrées à l’utilisateur final.

On peut attribuer à un concept SKOS un ou plusieurs indices (skos:notation) -l’usage est plutôt de se restreindre à un !-. Un indice ne peut être attribué qu’à un seul concept.

Relations sémantiques

• skos:semanticRelation
• skos:broader
• skos:narrower
• skos:narrowerTransitive
• skos:broaderTransitive
• skos:related

Les concepts sont liés par des relations sémantiques (skos:semanticRelation) de nature hiérarchique (skos:narrower vs skos:broader) ou associative (skos:related).

La propriété skos:semanticRelation s’applique à la classe skos:Concept

skos:narrower et skos:broader sont des sous-propriétés de skos:semanticRelation

skos:broader et skos:narrower sont des relations inverses : "A skos:narrower B" équivaut à : "B skos:broaderA"

Les normes de thesaurus prévoient 3 cas principaux de relations hiérarchiques : la relation genre-espèce, la relation tout-partie et la raltion d’instance. Le modèle SKOS ne gère pas ce niveau de détail mais autorise à déclarer des sous-propriétés de skos:broader comme dans l’exemple ci-dessous :
ex:broaderGeneric rdfs:subPropertyOf skos:broader.
ex:broaderPartitive rdfs:subPropertyOf skos:broader.
ex:broaderInstantive rdfs:subPropertyOf skos:broader.

skos:broader et skos:narrower permettent de déclarer uniquement une relation sémantique DIRECTE entre un concept A et un concept B. Si l’on veut pouvoir gérer dans une application des fonctions d’expansion automatique par l’inférence de liens hiérarchiques non directs (autopostage) il faut utiliser les propriétés skos:narrowerTransitive et skos:broaderTransitive :

Figure 4.5.2: inferring a transitive hierarchy from asserted skos:broader statements

skos:related est une relation symétrique : "A skos:related B " équivaut à "B skos:related A".

Cette propriété n’étant pas transitive, il n’est pas possible d’induire une relation associative par extension d’une autre. Par exemple « A skos:related B » + « B skos:related C » n’implique pas que « A skos:related C »

SKOS permet de créer des extensions pour typer de manière plus précise la relation associative entre deux concepts. Par exemple, indiquer qu’il s’agit d’une relation de cause à effet. Il est donc possible de créer des sous-propriétés de la propriété skos:related. Ainsi on peut déclarer :

<cause> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf skos:related .

<effect> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf skos:related ;
owl:inverseOf <cause>

Notes

• skos:note
• skos:changeNote
• skos:definition
• skos:editorialNote
• skos:scopeNote
• skos:example
• skos:historyNote

Les notes fournissent toute information utile autour d’un concept. Cette information peut être textuelle, mais il peut s’agir également de données telles que des images, ou encore des liens vers des ressources externes.

skos:changeNote, skos:definition, skos:editorialNote, skos:example, skos:historyNote et skos:scopeNote sont chacune des sous propriétés de skos:note.

skos:scopeNote fournit des informatIons même partielles sur la significatIon accordée à un concept dans le schéma, en particulier des indications sur les cas prévus d’utilisation à l’indexation.

skos:definition fournit une explication concernant la couverture sémantique du concept et de sa signification

skos:example introduit un exemple d’utilisation du concept

skos:historyNote permet de décrire les glissements de sens ou des changements de forme apportés au concept

skos:editorialNote permet d’enregistrer des données de gestion et d’administration à l’intention des personnes en charge de la maintenance du vocabulaire

skos:changeNote permet de lister des changements apportés au concept à des fins d’administration ou de maintenance, notamment des changements dans les relations sémantiques qui lui sont attribuées (ex. changement de place dans l’organisation hiérarchique)

SKOS Primer précise enfin que d’autres propriétés hors de celles proposées par le modèle SKOS peuvent être employer pour décrire des concepts, notamment les métadonnées du Dublin Core.

Relations de mapping

SKOS permet également de gérer des informations de mapping en indiquant le degré de recouvrement sémantique entre deux concepts issus de thesaurus différents.

• skos:narrowMatch
• skos:mappingRelation
• skos:closeMatch
• skos:broadMatch
• skos:exactMatch
• skos:relatedMatch

skos:broadMatch est une sous-propriété de skos:broader, skos:narrowMatch est une sous-propriété de skos:narrower, et skos:relatedMatch est une sous-propriété de skos:related.

Toutes ces propriétés sont également des sous-propriétés de skos:mappingRelation

skos:exactMatch est une sous propriété de skos:closeMatch Elles renvoient respectivement aux notions d’équivalence exacte et d’équivalence partielle de la norme ISO 5964.
skos:exactMatch n’est pas conçu comme l’équivalent de owl:sameAs qui signifie quant à elle que les deux ressources liées sont en fait la même ressource.

Aucune des relations de mapping n’est transitive et par conséquent ne permet d’élargir de proche en proche les relations.

Les relations de mapping ont été conçues pour lier des concepts appartenant à des schémas conceptuels distincts.

Toutefois les relations sémantiques (skos:broader, skos:narrower, skos:related) peuvent également être établies entre des concepts associés à des schémas conceptuels distincts.

SKOS juge qu’il est utile, dès lors que cela est possible, de distinguer les relations sémantiques internes à un schéma conceptuel d’une part, des relations de mapping entre schémas conceptuels d’autre part.

Enfin, il faut préciser également que SKOS n’exclut pas la possibilité de créer des relations de mapping à l’intérieur d’un schéma conceptuel. Toutefois SKOS Reference préconise de réserver ce cas de figure à un schéma issu de la fusion de plusieurs schémas initialement distincts, par exemple lors de l’enrichissement d’un schéma conceptuel par un autre.

Les évolutions de SKOS version 2008

Ce billet n’est pas le résultat d’une analyse personnelle qui aurait été effectuée par une lecture croisée des versions successives. Il s’appuie sur les indications fournies au début de chaque nouvelle version. Il pourra être mis à jour à mesure des évolutions du modèle.

Différences entre le Draft du 25 janvier 2008 et celui du 29 août 2008

Identiques aux différences entre le Draft du 25 janvier 2008 et celui du 9 juin 2008

Différences entre le Draft du 9 juin 2008 et celui du 29 août 2008

• Ajout de la propriété skos:topConceptof, comme propriété inverse de skos:hasTopConcept
• Ajout d’une mention selon laquelle rdfs:label est une super-property des propriétés SKOS skos:altLabel, skos:hiddenLabel and skos:prefLabel
• Modification de l’introduction de la section concernant les propriétés sémantiques
• Ajout d’une propriété skos:closeMatch pour relier deux concepts qui sont suffisamment proches pour pouvoir être considérés comme interchangeables par les systèmes de recherche d’information
• Modification de la définition de skos:exactMatch qui indique un degré de recouvrement suffisamment élevé entre deux concepts pour pouvoir être pris en compte dans la majorité des systèmes de recherche d’information. Du point de vue formel, la propriété skos:exactMatch devient transitive. Elle est une sous propriété de skos:closeMatch, transitive et non compatible ( ne pouvant être utilisé conjointement pour relier les même concepts) avec les propriétés skos:broadMatch and skos:relatedMatch.

Différences entre le Draft du 25 janvier 2008 et celui du 9 juin 2008

• Le nom de domaine pour le vocabulaire SKOS est modifié et devient <http://www.w3.org/2008/05/skos#>.
• Ajout d’une nouvelle section sur les notations
• Ajout de l’extension SKOS XL
• Suppression de la section concernant les liens entre les libellés, ceux ci étant traités par la propriété xl:labelRelation property de l’extension XL
• Refonte de la section concernant les relations de mapping pour prendre en compte que skos:broadMatch, skos:narrowMatch et skos:relatedMatch deviennent respectivement des sous-propriétés de vskos:broader, skos:narrower et skos:related