Pages récentes

Modifier
la page

Nouvelle
page

Imprimer
la page
Page modifiée à 07:42, 2 Avr 2009 par MichelBuffa
0

Droits d'accès dans SweetWiki

De $1

Version de 03:08, 3 Mai 2024

cette version.

Revenir à liste des archives.

Voir la version actuelle

  1. 1. Introduction
  2. 2. Utilisateurs, groupes, rôles et actions
  3. 3. Spécification des droits pour une resource
  4. 4. Ontologies proposées et exemples d'annotation pour SweetWiki
    1. 4.1. Exemple de profil FOAF dans une home page de sweetwiki
    2. 4.2. Exemple de page annotée pour spécifier un accès restreint
    3. 4.3. Exemple d'annotation définissant le groupe des admins et leurs rôle/actions par défaut
    4. 4.4. Description des rôles
    5. 4.5. Descrition des types d'accès
    6. 4.6. Et enfin l'ontologie dans sa version de travail
  5. 5. Discussions et questions

Introduction

Ici on discute de la manière d'implémenter les droits d'accès dans SweetWiki.

Utilisateurs, groupes, rôles et actions

Inspiration première : la manière dont DekiWiki gère les droits. Dans la partie admin, il y a un control panel qui permet de gérer des "Roles", un rôle étant associé à une action (cf screenshot ci-dessous). Il y a aussi la gestion des utilisateurs et des groupes, un groupe pouvant se composer d'une liste d'utilisateurs et/ou d'autres groupes. Un utilisateur ou un groupe a un role par défaut.

 Snap1.jpg

Spécification des droits pour une resource

Dans DekiWiki, pour chaque page, on spécifie son accès "public, semi-public ou privé", et pour les deux derniers cas, on donne la liste des utilisateurs et/ou des groupes qui ont le droit de modifier ou de voir et modifier.

 Snap2 (2).jpg

Ontologies proposées et exemples d'annotation pour SweetWiki

Nous proposons d'étendre l'ontologie du wiki et d'utiliser conjointement une ontologie intitulée provisoirement amo_ont (Access Management Ontology).

Nous supposons que les home page de SweetWiki contiennent un profil FOAF dédié à SweetWiki (qui pourra être référencé par un profil FOAF "global", un peu à la manière d'Adil qui a des profils FOAF légers/dédiés sur lastfm, etc... et un gros profil FOAF sur un URL de l'inria).

Exemple de profil FOAF dans une home page de sweetwiki

/div[4]/div/pre, reference to undefined name 'syntax'

Exemple de page annotée pour spécifier un accès restreint

Ici, la page a un accès privé, accessible et modifiable par Ania et le groupe des admins.

/div[4]/div[2]/pre, reference to undefined name 'syntax'

Exemple d'annotation définissant le groupe des admins et leurs rôle/actions par défaut

/div[4]/div[3]/pre, reference to undefined name 'syntax'

Description des rôles

/div[4]/div[4]/pre, reference to undefined name 'syntax'

Descrition des types d'accès

/div[4]/div[5]/pre, reference to undefined name 'syntax'

Et enfin l'ontologie dans sa version de travail

/div[4]/div[6]/pre, reference to undefined name 'syntax'

Guillaume : je ne comprend pas la dernière déclaration dans l'ontology, on a dans l'ontologie 'givenAgent' qui a pour domain 'Document' et pour range 'Agent'

 

  1.     <rdf:Property rdf:ID="avialableAction">  
  2.         <rdfs:domain rdf:resource="#AccessType" />  
  3.         <rdfs:range rdf:resource="http://xmlns.com/foaf/0.1/#Action" />  
  4.         <rdfs:label xml:lang="en">  
  5.             rights witch givenAgents get in this accessType  
  6.         </rdfs:label>  
  7.     </rdf:Property>  

 

  1. avialableAction ==> availableAction

  2. je ne comprend pas à quoi ca sert en sachant hasAccessType défini déjà les actions disponible

pas de gestion de l'héritage des droits? Rien n'empêche de le modéliser même si on ne l'implèmente pas ca peut être intéressant si on publit l'ontologie

Discussions et questions

  • Au lieu de définir les groupes et les rôles par défaut : utiliser des règles OWL lite ?
  • Utilisation de SIOC:user ou sioc:user_groups_of au lieu de foaf:agent
  • Problème de sécurité, ne pas indiquer à quels groupes les personnes appartiennent dans le home page, mais dans des annotations non accessibles de l'extérieur,
  • Utiliser SIOC types qui définit déjà ce qu'est un contributeur, un guest, un admin ? Soucis : SIOC Types a l'air non fini et surtout ces rôles sont au niveau du "site" et mal définis...

 

 
Powered by MindTouch Deki Open Source Edition v.8.08