Catégories et Tags

S’il est un besoin inhérent à toute mise en place d’un projet GED / ECM, c’est bien la classification des différents contenus (documents, répertoires, discussions, etc …).
Alfresco propose différents outils de « classification » :
- Le plan de classement
- Les métadonnées
- Les catégories
- Les tags

Le plan de classement et les métadonnées sont des concepts plutôt bien connus.

Le premier désigne l’arborescence de dossiers et sous-dossiers dans laquelle on peut archiver les contenus, permettant une navigation que l’on pourrait qualifier de « hiérarchique » ou « verticale ». C’est la navigation intuitive à laquelle on est habitué lorsqu’on utilise un ordinateur personnel, recherchant et déplaçant les fichiers entre les différents répertoires.

Les métadonnées sont parfois décrites comme une « fiche d’informations » d’un contenu. Elles sont en effet un ensemble d’informations décrivant un contenu, comme « l’auteur », la « date de modification », ou encore le « statut ».

Cependant, les concepts de catégories et de tags sont parfois moins bien compris.
Certes, dans les deux cas, il s’agit de la possibilité d’accoler une ou plusieurs « étiquettes » (ou encore « mots-clés ») à un objet (document, espace, feuille wiki, réponse à une discussion, etc …). En outre, tags et catégories permettent aux utilisateurs de naviguer au sein de l’entrepôt de manière « sémantique ».

Les catégories

Les catégories forment un vocabulaire hiérarchique de mots-clés, et défini par un administrateur fonctionnel. Elles permettent de classifier les contenus selon une taxinomie. Elles sont très utilisées notamment dans les projets d’archivage ou de « gestion de documents référentiels ».
Dans Alfresco, un contenu peut « recevoir » une ou plusieurs catégories (s’il dispose de l’aspect « Catégorisable »). Enfin, un filtre de navigation « Catégories » permet d’afficher les contenus étiquetés avec la catégorie sélectionnée.















Les tags

A l’inverse des catégories, les tags sont des mots-clés non-organisés, qui sont librement créés par les utilisateurs finaux. Les tags permettent de classifier les contenus selon une folksonomie.
Les tags sont régulièrement mis en oeuvre dans les projets collaboratifs, et les projets de capitalisation de connaissance (KM).
En effet, les tags ont l’avantage de recueillir un investissement important des utilisateurs, ceux-ci ressentant parfois une certaine frustration face au système plus rigide des catégories figées.

Dans Alfresco, tout contenu peut « recevoir » un ou plusieurs tags, déjà existants dans l’application, ou nouvellement créés à la saisie. Enfin, un filtre de navigation « Tags » permet d’afficher les contenus étiquetés avec le tag sélectionné.

On remarque également qu’une sorte de « loi darwinienne » s’applique dans l’affichage des tags dans cette entrée de navigation. En effet, les tags sont triés par ordre d’utilisation (le nombre entre parenthèses indique d’ailleurs le nombre de contenus associés au tag).
Cet ordonnancement naturel permet de pallier naturellement à l’éventuel problème de profusion de tags obscurs, mal orthographiés, ou encore inutiles.














Si vous avez des retours sur cet article, n'hésitez pas à nous en faire part !

Espace racine des protocoles FTP, CIFS ...

Vous savez sans doute déjà que l’entrepôt Alfresco est accessible par différents protocoles, notamment FTP, CIFS, NFS …

Mais savez-vous qu’il est possible de n’exposer qu’une partie de votre entrepôt via ces interfaces d’accès ?

Pour cela, il vous faut surcharger la configuration par défaut du subsystem File Servers.

Qu’est ce qu’un subsystem ? Réponse ici.

Comment configurer un subsystem ? Réponse là.

Quelques infos supplémentaires sur le FileServer Subsystem ? Voici la page wiki dédiée.

En l’occurrence, dans le cas décrit ici, il faudra adopter la 3^ème méthode de configuration du subsystem, puisque l’on va devoir modifier la définition d’un bean Spring appelé « filesystemsContext ».

En effet, il suffit de modifier la valeur de la propriété "rootPath", comme suit :

<property name="rootPath">

<!-- <value>/${spaces.company_home.childname}</value> -->

<value>/app:company_home/st:sites</value>

</property>

Dans cet exemple, nous décidons de configurer la racine des accès des interfaces de type « File Server » comme « Accueil / Sites ». Ainsi, tout utilisateur se connectant en FTP, CIFS ou NFS à l’entrepôt ne pourra voir que la liste des sites collaboratifs.

Enfin, sachez qu’en observant de près les 2 fichiers de configuration du subsystem FileServers, vous découvrirez sans doute d’autre astuces de configuration (changer le nom de l’espace racine, modifier uniquement le répertoire racine pour FTP, …)

Configuration des aspects dans Share

Dans l’interface Share, il est possible d’appliquer (et d’ôter) des aspects à des dossiers et des contenus. Par défaut, Share expose un certain nombre des aspects existants dans Alfresco, dans cette fenêtre de dialogue.
Mais il est bien sûr possible d’ajouter des aspects spécifiques, ou d’exposer des aspects Alfresco cachés par défaut.
Je vais prendre l’exemple de l’aspect Alfresco « cm:attachable », qui permet, appliqué à un objet, de lui attacher des documents liés. Cet aspect n’apparaît pas, par défaut, dans le dialogue de gestion des aspects.

Pour cela, il faut créer un fichier share-config-custom.xml dans tomcat/shared/classes/alfresco/web-extension (vous pouvez vous aider du fichier share-config-custom.xml.sample qui y figure normalement).
Si vous placez dans ce fichier le « code » suivant, et que vous redémarrez Alfresco, vous verrez alors apparaître l’aspect « cm :attachable » dans l’action de gestion des aspects :

<!-- Document Library config section -->

<config evaluator="string-compare" condition="DocumentLibrary" >

<aspects>

<!-- Aspects that a user can see -->

<visible>

<aspect name="cm:attachable" />

</visible>

<!-- Aspects that a user can add. Same as "visible" if left empty -->

<addable>

</addable>

<!-- Aspects that a user can remove. Same as "visible" if left empty -->

<removeable>

</removeable>

</aspects>

Vous devinerez également, en notant la présence des sections « addable » et « removeable », qu’il est possible de configurer plus finement l’affichage des aspects sur les actions d’ajout ou de suppression.