Last modified 5 years ago Last modified on 07/24/12 11:18:38

Go back to the table of modules

Identity

The Identity module implements management of identities (metadata about persons or organizations). This includes importing, identity resolution (identifying any identity in the database that represents the same person, making sure it stays unique, and completing it as new details are known), and providing representations of the identity (such as VCards and HTML for the end users.)

List of critical functionality

  • vCard => vcard-rdf Translation
  • vcard-rdf => vCard Translation
    • To allow exporting back to LOM (when updating the identity, we must re-generate a VCard when exporting back to LOM. Be careful of too long caching. The LOM cache should be expired regularly so such changes are eventually picked up)
  • Lookup and unicity heuristics
  • Conversion to uniform displayable formats (HTML)
  • Implement the heuristics to determine if two identities harvested are actually the same person or organization, and avoid duplicating them.
    • Reason: Essential to implement functionality like "Show me more resources from the same author". Also allows showing more extensive information even in the case of metadata that only contain basic identity information.

List of desirable functionality

  • FOAF => VCard Translation
    • To allow importing from MLR
  • Incremental building of reference identity. Once an identity received is determined to be the same as an existing one, check if the received information is not more complete than the existing one, and save the added information.

Implementation choices/alternatives

The internal representation will use vcard-rdf, as most real-world collections use VCard (and VCard is unlikely to go away)

Several libraries allow abstractions of VCard and FOAF, so translation functionnality should be fairly easy to build.

FOAF support will be required in the future to support MLR.

Algorithms

Algorithmes utilisés par Eurêka pour déréférencer les identités

!empty ($email) || !empty ($org) || !empty ($fn) || (!empty ($family_name) && !empty ($first_name))) => vCard minimale, sinon on rejette

Critères d'identité:

  • deux VCard ont le même email
    • Exemple (problématique...), les deux VCARD suivantes sont considérées comme la même identité:
      BEGIN:VCARD
      VERSION:3.0
      FN:John Smith
      N:;;;;
      ORG:Megacorp inc.
      EMAIL;TYPE=INTERNET:info@megacorp.com
      END:VCARD
      
      BEGIN:VCARD
      VERSION:3.0
      FN:Joe Blow
      N:;;;;
      ORG:Megacorp inc.
      EMAIL;TYPE=INTERNET:info@megacorp.com
      END:VCARD
      
  • si org présent: org sont identiques
  • si fn présent: fn sont identiques
  • si family_name et first_name présent: family_name et first_name sont identiques
    • Exemple, les deux VCARD suivantes ne sont PAS considérées comme la même identité:
      BEGIN:VCARD
      VERSION:3.0
      FN:John Smith
      N:;;;;
      ORG:Megacorp inc.
      END:VCARD
      
      BEGIN:VCARD
      VERSION:3.0
      FN:Joe Blow
      N:;;;;
      ORG:Megacorp inc.
      END:VCARD
      

Notes:

  • Cet algorithme est imparfait:
    • L'organisation devrait être vérifiée même si vide. Sinon, on aura de faux positifs pour les homonymes.
      • Exemples: On veut que les deux identités suivantes soient considérées comme n'étant PAS identiques:
        BEGIN:VCARD
        VERSION:3.0
        FN:John Smith
        N:;;;;
        ORG:Megacorp inc.
        END:VCARD
        
        BEGIN:VCARD
        VERSION:3.0
        FN:John Smith
        N:;;;;
        END:VCARD
        
    • Le nom devrait être vérifié même si le courriel fonctionne, trop d'organisations utilisent une adresse générique (info@…)
      • Exemple: On veut que les deux identités suivantes soient considérées comme n'étant PAS identiques:
        BEGIN:VCARD
        VERSION:3.0
        FN:John Smith
        N:;;;;
        ORG:Megacorp inc.
        EMAIL;TYPE=INTERNET:info@megacorp.com
        END:VCARD
        
        BEGIN:VCARD
        VERSION:3.0
        FN:Joe Blow
        N:;;;;
        ORG:Megacorp inc.
        EMAIL;TYPE=INTERNET:info@megacorp.com
        END:VCARD
        
  • L'objectif principal est d'éviter la duplication des identités
    • Cet algorithme a été développé dans un contexte où le nombre d'homonymes (personnes différentes avec exactement le même nom) est statistiquement limité. Avoir deux homonymes sans informations n'est pas un gros problème, SI ET SEULEMENT SI on re-roule l'algorithme de correspondance lorsqu'une vCard est modifiée. Sinon, si on ajoute par exemple l'adresse courriel et l'organisation, tous les homonyme recevront également ces nouvelles informations.
      • Déréférencer les identités que lorsque l'on a suffisamment d'information est irréaliste, ne serait-ce que question de traitement homogène. Si on applique la règle plus haut, les homonymes resteront inoffensifs.
  • Garder en tête que les gens peuvent avoir plus d'une adresse courriel.
  • Garder en tête que les vCard mal formatées sont un fléau, pour de multiples raisons

Fusion et mise à jour des identités

Pour atteindre l'unicité des identités, il faut parfois fusionner deux identités manuellement. Un ordinateur ne peut pas toujours déterminer le comportement approprié.

Par exemple, admettons qu'on a une personne ayant partagé le meme email pour 2 emplois (genre fb@… pour org1=Licef et org2=Teluq). Dans ce cas ll s'agit de la même personne, mais de deux identités distinctes, que l'on veut probablement garder distinctes. Un exemple analogue est quelqu'un qui change d'emploi.

Nous voulons avoir la possibilité de fusionner ces deux identités (un peu comme dans la liste de contacts de Google), mais pour l'instant, il n'est pas intéressant d'établir une relation entre les deux identités.

À chaque exécution de l'algorithme de correspondance (Voir "Incremental building of reference identity" plus haut), une identité est potentiellement mise à jour. Le problème est un peu moins épineux pour les FOAF, mais les identités partagent avec les ressources le problème non-résolu dans les standards actuels de l'adresse d'un dépôt cannonique (cette suggestion a été refusée dans MLR).

Notons que nous ne sommes vraiment pas les seuls à attaquer ce genre de problème. Il serait particulièrement intéressant d'intégrer les services de:

0.9.8 © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.65135 sec.)